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