Thanks Jarkman. 2 questions:
1) Does: int sdkVersion = Integer.parseInt(Build.VERSION.SDK); if (sdkVersion < Build.VERSION_CODES.ECLAIR) Return the OS/SDK version currently run by the underlying platform or does it return the target SDK level the APP was compiled for ? 2) Is there a way for an App to learn what is the current language (input/display) being used ? Thanks, On Mon, Nov 2, 2009 at 9:23 AM, jarkman <[email protected]> wrote: > > > On Nov 2, 5:02 pm, frantz lohier <[email protected]> wrote: > > > > + in the Market, should we upload different app versions compiled for > > different SDK/OS configuration ? Can the market app offer a specific > version > > of an app to an end-user depending on what OS version is used ? > > It would certainly make our lives easier if the Market supported > alternative binaries for different OS versions. > > > + how does an app know what OS version is currently used ? > > + how can an app dynamically make use of new SDK feature with the same > > executable ? (for example, how can I activate TTS if it is supported). > > Backward compatibility is discussed here: > http://android-developers.blogspot.com/2009/04/backward-compatibility.... > > Unfortunatly, this link does not tell me how to selectively do an "import > > android.speech.tts.TextToSpeech" for my code to compile. > > What you can do is build against the 2.0 SDK, but wrap up all your 2.0 > stuff in a class which you only instantiate if you are on a 2.0 > device. > Build a base class which is mostly abstract, and a 1.6 version of the > same class which implements the same functionality but with 1.6 APIs. > Then use this trick to instantiate the right subclass: > > int sdkVersion = Integer.parseInt(Build.VERSION.SDK); > if (sdkVersion < Build.VERSION_CODES.ECLAIR) > { > className = "com.foo.ContactAccessorSdk3_4"; // one subclass of > ContactAccessorBase > } > else > { > className = "com.foo.ContactAccessorSdk5"; // another subclass of > ContactAccessorBase > } > > /* > * Find the required class by name and instantiate it. > */ > try { > Class<? extends ContactAccessor> clazz = > Class.forName(className).asSubclass > (ContactAccessor.class); > ContactAccessorBase sInstance = clazz.newInstance(); > } catch (Exception e) { > throw new IllegalStateException(e); > } > > (thanks, Dmitri!) > > > > > > On Mon, Nov 2, 2009 at 8:54 AM, frantz lohier <[email protected]> wrote: > > > Thanks Jarkman for your perspectives on this. > > > > > 2 additional questions; > > > > > - can the emulator simulate accessing a gmail account ? (as ways to > avoid > > > dealing with the Accountmanager APIs) > > > > > - A more general and critical question; if apps start to have to behave > > > differently based on the Android OS version they run on, there are a > lot of > > > implications; > > > > > On Mon, Nov 2, 2009 at 2:33 AM, jarkman <[email protected]> wrote: > > > > >> On Nov 2, 1:57 am, frantz lohier <[email protected]> wrote: > > > > >> > When running the same code (compiled with SDK 1.6) and a target > emulator > > >> at > > >> > 2.0 level, the above code never return the entries I have populated > in > > >> my > > >> > the phone book. It's as if the phonebook was always empty. > > > > >> My (hazy) understanding is that the 1.6 APIs will only show you the > > >> contacts in the primary gmail-syncing account on the device. As the > > >> emulator doesn't have one of those accounts, your newly-entered > > >> contacts are in a different account (or in some kind of no-account > > >> limbo), so they are invisible to the 1.6 APIs. > > > > >> I think that on a real device with a real account the situation will > > >> be better, though you still need to move to the 2.0 APIs to support > > >> users who have multiple accounts. > > > > >> It may be possible to use the AccountManager APIs to manufacture an > > >> account of the right sort in the emulator, which would make it > > >> possible to enter new contacts who would show up in the 1.6 APIs, but > > >> I don't think there are enough clues in the published docs to tell us > > >> how to do that. > > > > >> > - When running the emulator in 2.0 mode, the default local input > type is > > >> > Japaneese. Any way to change this ? > > > > >> Yes, you can fiddle with the IME settings in the Settings app, in > > >> 'Language & Keyboard'. > > > > >> Richard > > > > >> -- > > >> You received this message because you are subscribed to the Google > > >> Groups "Android Developers" group. > > >> To post to this group, send email to > [email protected] > > >> To unsubscribe from this group, send email to > > >> [email protected]<android-developers%[email protected]> > <android-developers%[email protected]<android-developers%[email protected]> > > > > >> For more options, visit this group at > > >>http://groups.google.com/group/android-developers?hl=en > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" 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-developers?hl=en
