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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
