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