I thought that one of the goals I was aiming for was specifically to not store everything as a string (because if we do we might as well make SystemProperties public), given that the we assume that many values will be booleans.
In fact there's an interesting optimization for booleans: if we decide by convention that a boolean that's not set is not distinguishable from false, the set of booleans that are set to true can be stored in a hashset instead of having a hashmap. Same thing for integers defaulting to zero. I'm afraid that at this point this is turning into a larger project that I have time for, though, as I was supposed to start working on something else yesterday already, and I think that I'll just revert the original change (and we'll manage with SdkSetup until someone has time to revisit). Anyway, do we prefer it as individual members, like in http://review.source.android.com/8415 or with functions like in http://review.source.android.com/8451 ? JBQ On Wed, Jan 21, 2009 at 1:39 PM, Dianne Hackborn <[email protected]> wrote: > I'd really like to see a change that is a more "real" implementation of the > API. All we are doing right now is rewriting an existing system property, > so we are missing half of the view of what this will look like -- where > these Config values are stored and how they are retrieved. > > Personally I would lean towards putting the values in an XML file, which > Config parses in its static initializer (which will happen one time in > Zygote). Then a single method on Config to retrieve a value. This would > unfortunately mean that the only thing you can get back is a String, not a > typed value, but if the intention is for this to hold a fairly arbitrary set > of configuration params (including ones for specific apps??) then it seems > to me we would be going down this path anyway. > > 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. > > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > -- 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 -~----------~----~----~----~------~----~------~--~---
