On Mon, Jan 18, 2010 at 7:22 AM, JP <[email protected]> wrote:
> Hmm, I've toyed with that a while back, and as far as I remember, the > app won't even launch, and crash with a class-not-found exception > (makes somewhat sense). > If you just do things correctly, it is fine. And correctly means: make sure that the code that runs when on an older version of the will never reference code that uses newer APIs. An article on doing this is here; note in particular the last part, about how you can have classes that use new APIs and detect whether to use those classes. (You could also just check the platform version to decide whether to use it.) http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html Also note that simple constants like integers get compiled in to your app instead of referencing the original symbol, so you don't need to do anything when using new constants like flags. There are a lot of other things that conveniently work out as well -- for example, here is sample code for a Service that uses the new 2.0 APIs if available but still works on older versions of the platform: // This is the old onStart method that will be called on the pre-2.0 // platform. On 2.0 or later we override onStartCommand() so this // method will not be called. @Override public void onStart(Intent intent, int startId) { handleStart(intent, startId); } @Override public int onStartCommand(Intent intent, int flags, int startId) { handleStart(intent, startId); return START_NOT_STICKY; } void handleStart(Intent intent, int startId) { // do work } If there are specific issues people are having with using newer APIs in an a compatible way, it would be really useful to post a question about them (please in a separate thread) so that they can be addressed. Hopefully in most cases it is just a matter of knowing the tricks to do, though there may be ways we have done some new APIs that make them needlessly more difficult to use that we should avoid in the future. Finally, as far as dealing with multiple versions of the platform -- how different is this, really, than Windows and MacOS where there are three or more different major versions of those platforms in active use? (And on MacOS, for quite a while now different CPU architectures!) You just do on Android exactly the same thing you do on those platforms: look at the distribution of versions to decide the minimum one you want to target, and do the appropriate thing for using newer APIs when you want to do that. Honestly I get really frustrated when people talk about different versions of the platform as "fragmentation." Where does that come from?? Is Windows fragmented? Is MacOS fragmented? People talk about Android fragmentation in these terms as if it is this unique, novel, killer issue in Android, and yet it is little different than other platforms. The main difference is, yes, a user of a particular phone can't go out and buy a newer version of the platform in order to run your app. Unfortunately there isn't really a solution to this -- nobody but the hardware manufacturer can supply newer versions of the platform to their device, since they need to include the drivers and customization that are needed for that device. On the other hand, if you are doing your app on Windows, what is the chance that they would upgrade from XP to Windows 7 just to buy and run it? (Then we can go off on web-based apps and the various browser versions that need to be supported.) But let's look at the current situation: the oldest version of the platform that developers need to worry about is 1.5, which was finished less than a year ago. It appears to me that most of the manufacturers that have such devices on the market have pledged to update them to 2.x. If things proceed how it sounds, I think the bulk of the devices will be running a platform version released in the last year. So that gives you an upper bound of maybe 4 platform versions to support. (And keep in mind -- doing 4 significant platform releases in a year is pretty extreme, and maybe not something that will continue. If you think it is hard on you, imagine the poor platform developers. :p) Now I wouldn't be surprised to see the active versions spread out over time, as older devices are no longer supported so stay on an older version of the platform. But if we assume the active lifetime of a smartphone is around 2 years, there are going to be strong bounds on how old a version of the platform you need to go down to, to support most active phones. And even if 1.5 continues to ship on new phones for years and you need to support it to get 80% of the market -- that platform release is a very rich and functional base. There are a few things that you'd need to do to work well on newer platforms (supporting the new Contacts API probably being the biggest), but for the most part you can just focus on that platform version and write a perfectly fine app. -- 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, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
-- 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
