Other variant (function-based): http://review.source.android.com/8451 (framework change - DO NOT PAY ATTENTION TO THE IMPLEMENTATION ITSELF!)
http://review.source.android.com/8285 http://review.source.android.com/8454 http://review.source.android.com/8455 (call sites). Comments welcome. JBQ On Tue, Jan 20, 2009 at 7:48 PM, Jean-Baptiste Queru <[email protected]> wrote: > There are definitely tradeoffs in both variants. I wanted to put quick > implementations of both options together, so that we'd have something > concrete to discuss. I'll prepare the other variant (function-based) > tomorrow morning, as it'll take a tiny bit more time if I want the > implementation to look like something that'd end up in production. > > JBQ > > On Tue, Jan 20, 2009 at 7:15 PM, Joe Onorato <[email protected]> wrote: >> I missed Dave's message in this thread. The problem with putting constants >> into Config.java is that it forces us to have one file with all possible >> configuration values in it, which I think is a huge mistake. >> >> This mechanism needs to work for built-in apps, many of which won't be open >> sourced, as well as the system. I really don't want to pollute the platform >> with all constants for all possible apps. >> >> -joe >> >> >> >> >> On Tue, Jan 20, 2009 at 4:49 PM, Jean-Baptiste Queru <[email protected]> wrote: >>> >>> I've uploaded a proposed implementation with the following changes: >>> http://review.source.android.com/8415 >>> http://review.source.android.com/8256 >>> http://review.source.android.com/8416 >>> http://review.source.android.com/8257 >>> >>> Please don't pay too much attention to the fact that the parameter is >>> backed by a system property, that's an implementation detail at this >>> point. I'm mostly interested in knowing whether this approach is >>> sustainable in the future. >>> >>> Thanks, >>> JBQ >>> >>> On Fri, Jan 16, 2009 at 4:30 PM, Jean-Baptiste Queru <[email protected]> >>> wrote: >>> > Agreed. The explicitly goal here is to avoid the use of an additional >>> > system property (well, undo it, or at least hide it behind an API that >>> > we'll be able to re-implement some other way). >>> > >>> > JBQ >>> > >>> > On Fri, Jan 16, 2009 at 4:18 PM, Brian Swetland <[email protected]> >>> > wrote: >>> >> >>> >> As a side-note I'd like to try to reduce usage of the underlying system >>> >> properties -- they're becoming a dumping ground for all kinds of random >>> >> stuff, and they were not really intended as an open-ended registry of >>> >> every possible thing we might think to dump in there.... >>> >> >>> >> [Dave Bort <[email protected]>] >>> >>> The major benefit of using static final fields that I see is that it >>> >>> becomes very obvious who is using a given flag (e.g., "provisioned"), >>> >>> we can track the existence of that flag using our existing API >>> >>> checking tools, and the build breaks if a flag is removed but there >>> >>> are users of it. >>> >>> >>> >>> A dictionary-style interface, on the other hand, provides no >>> >>> possibility for static checking; there's no way to tell whether or not >>> >>> anyone is using a particular flag. This is the main reason we're >>> >>> trying to kill the uses of the SystemProperties API. >>> >>> >>> >>> --dbort >>> >>> >>> >>> On Fri, Jan 16, 2009 at 3:58 PM, Jean-Baptiste Queru <[email protected]> >>> >>> wrote: >>> >>> > As a follow-up to the thread about the "provisioned" bit, I'd like >>> >>> > to >>> >>> > look at the way some build-time-configurable aspects are exposed to >>> >>> > applications. >>> >>> > >>> >>> > Right now, we're exposing android.os.Build ("Information about the >>> >>> > current build, extracted from system properties."). It contains a >>> >>> > dozen of fields (mostly strings) that contain information about the >>> >>> > source code that was used, the build combo, and who built it, where, >>> >>> > and when, i.e. what we often refer to as "the build". >>> >>> > >>> >>> > Next to that, we also have android.util.Config ("Build >>> >>> > configuration. >>> >>> > The constants in this class vary depending on [the] build."). It >>> >>> > contains a handful of booleans, which were meant to be set according >>> >>> > to the build configuration (e.g. DEBUG, PROFILE, LOGV). Given the >>> >>> > way >>> >>> > we now check API differences for compatibility breaks, we can't >>> >>> > actually change those values without introducing what our >>> >>> > api-checking >>> >>> > tool considers an API breakage. >>> >>> > >>> >>> > I'd like to introduce a mechanism to allow the build-time side to >>> >>> > pass >>> >>> > parameters that can be checked at run-time at the SDK API level, for >>> >>> > parameters like the "requires_provisioning" bit. >>> >>> > >>> >>> > Requirements: >>> >>> > -Values must be read-only when seen from applications. >>> >>> > -Must not involve any API change when the parameters change. >>> >>> > -Must allow to document each possible value using the usual >>> >>> > mechanism. >>> >>> > -Must not involve build-time-generated (or build-dependent) source >>> >>> > files written in the java programming language. >>> >>> > -Performance and footprint are both important. >>> >>> > -Must support at least booleans, integers (int and/or long?) and >>> >>> > strings. >>> >>> > >>> >>> > I'm thinking that Config is a more appropriate location than Build >>> >>> > for >>> >>> > those parameters. >>> >>> > >>> >>> > One approach is to do something similar to Build: grab each >>> >>> > parameter >>> >>> > at init time (i.e. in a static final) from whichever location is >>> >>> > appropriate (SystemProperties or any other place). >>> >>> > >>> >>> > Another approach is to not directly expose individual fields, but >>> >>> > instead to expose functions that take string keys and return the >>> >>> > values: e.g. boolean getBoolean(String key), int getInt(String key), >>> >>> > and expose static final constant strings for the keys. >>> >>> > >>> >>> > The former feels like it'd be lighter-weight in terms of memory and >>> >>> > CPU. The latter feels a lot more automated (so that we could just >>> >>> > stick the values in a data file and parse that). >>> >>> > >>> >>> > What's the preferred option? >>> >>> > >>> >>> > Thanks, >>> >>> > JBQ >>> >>> > >>> >>> > -- >>> >>> > Jean-Baptiste M. "JBQ" Queru >>> >>> > Android Engineer, Google. >>> >>> > >>> >> >>> > >>> > >>> > >>> > -- >>> > Jean-Baptiste M. "JBQ" Queru >>> > Android Engineer, Google. >>> > >>> >>> >>> >>> -- >>> Jean-Baptiste M. "JBQ" Queru >>> Android Engineer, Google. >> >> > > > > -- > Jean-Baptiste M. "JBQ" Queru > Android Engineer, Google. > -- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
