Consequences of Targeting Android SDKs , Page 2
Effects of Target Android SDK on Code Complexity and Maintenance
Let's say you go down the route of trying to support all devices. Well, this prompts other development decisions. Will you simply restrict yourself to only APIs (and methods) that are available across all API Levels you plan to target, or will you use techniques like Java reflection to test for, and call, methods when they are available?
If you choose the first option and simply provide one generic solution for all devices (i.e. use the lowest API Level classes and methods only), your application is not taking advantage of the latest and greatest features that newer devices have to offer, but at least your code is straightforward and easier to maintain. If you can deliver all the features your users demand and expect, then by all means, this is your best bet.
If you choose the second option and provide alternative functionality depending on the API Level, then your code will be awash in conditional statements that can be incredibly difficult to read and maintain. The more device-specific characteristics you try to accommodate, whether we're talking API levels, screen resolutions, or what have you, the more code paths you create and the more complex your application becomes. On the bright side, you are providing users with the "best" version of your application for their specific device.
There is a third choice: make different app packages for different platform versions. This is certainly feasible, but it involves substantial source control management trickery that small teams may find difficult to manage. It also adds publishing complexity.
Effects of Target Android SDK on Project Schedules
Perhaps it has already dawned on you that these choices can have significant impact on your project schedule. Still, we call this out specifically because it's often not communicated well between clients/project management ("I want to support everyone!") and the developer ("Uh, do you know what that means?" or "Sure! The schedule isn't my problem!"). The short answer is: providing alternative functionality for different device API levels is likely to impact your development schedule as well as your quality assurance team's hardware budget and testing schedule, not to mention your configuration management situation and published app management.
Effects of Target Android SDK on Application Package Size
Much like code complexity, your application package will grow in size substantially as you provide alternative resources and code for different API Levels and device characteristics. The larger codebase alone might be acceptable, but if you are also including significant quantities of alternative resources and assets in your package, you may find your application package rapidly approaching or even exceeding the app size limitations imposed by publication channels like the Android Market. Also, you may be doing your users a disservice by forcing them to install an enormous application package, most of which doesn't even apply to them. When you see this happening, it's likely time to consider breaking your application up into logical "versions" and publishing them separately. You'll need to familiarize yourself with various Android Market filters to pull this off properly, adding further complexity but creating a better experience for your users.
Although the current 50MB limitation on the Android Market may seem huge for mobile, keep in mind that on competitive systems there are plenty of applications and games that exceed this size without carrying the extra graphics around for alternate versions.
Effects of Target Android SDK on Project Management
If you've broken your application package up into logical "version" packages, then you need to consider and plan how you will keep track of them. Often product management doesn't really care about the "versions", but wants to treat it as one application for reporting and revenue purposes. This makes a lot of sense, but unfortunately, it's not how most publication channels, like the Android Market, function. In terms of reporting, ratings, etc. your app "versions" are separate apps and are managed separately.
For example, when you want to change your app's price, you'd need to changing it numerous times -- once per package. Want to know how much money you've made on your application? Well, you'll have to do the math yourself by summing the individual "version" totals. To make matters worse, you as the developer may inevitably receive a frantic email from a well-meaning higher-up saying that there's some horrible bug that needs fixing right this very minute -- but you won't necessarily know which "version" has the issue without some extra legwork.
Each decision you make regarding SDK versions has its own set of issues, with its own set of pros and cons. We have discussed many of these pros and cons in theory, but each product is unique. If you were hoping that we were going to propose the perfect solution to this problem, we'll apologize now: there isn't one. Our personal approach is one of moderation -- support as many appropriate devices as possible, trend towards the generic solution when you can, diverge when necessary or highly beneficial, and always consider the impact of your design decisions and educate your team and clients. Do your very best to keep your packages lean; your app versions minimized, clear and well labeled; and your users happy.
About the Authors
|Shane Conder and Lauren Darcey -- Contributing Editors, Mobile Development -- have coauthored two books on Android development: an in-depth programming book entitled Android Wireless Application Development (ISBN-13: 978-0-321-62709-4) and Sams Teach Yourself Android Application Development in 24 Hours (ISBN-13: 978-0-321-67335-0). When not writing, they spend their time developing mobile software at their company and providing consulting services.|