Android devices come in all colors, shapes, and sizes. Sometimes you want to try to support all devices with a single application, and other times you want to limit the types of device configurations that your application can support. Really, it all comes down to knowing your user audience, so that they have positive experience (without excluding anyone unnecessarily).
Developers can target different device configurations using a number of Android Manifest tags, including <supports-screen>, <uses-configuration>, <uses-feature>, and <uses-sdk>.Developers can also use certain programming techniques to help ensure that applications are both forward and backward compatible.
Supporting Hardware Configurations
Let’s take a closer look at some of the Android manifest file tags that you can use in your application to help identify target device configurations and how they work:
Targeting Different Android SDK Versions
When a new version of the Android version is released, developers must take note of the new SDK components added as well as those that were deprecated. First and foremost, you want to make sure you use the <uses-sdk> tag correctly in your application’s Android manifest file.
You can also use some other techniques to help ensure compatibility with different Android SDKs, including
Determining When SDK Features Were Introduced
When developing an application that targets multiple platform versions, developers need to pay special attention to the API Level associated with a given package, class, method, or constant in the SDK. The API Level in which a given class, interface, or method was introduced is usually listed in the Android SDK documentation, as shown in Figure.
The API Level for a given SDK component might be shown in different places in the documentation:
For packages, classes, and interfaces, the API level is displayed in the top-right corner of the Java documentation (at the top).
How to determine the API Level for a specific package, class, or method.
Using Java Reflection to Ensure Backward Compatibility
Luckily, Android applications are written in Java, and the Java programming language supports reflection. What this means is that developers can programmatically retrieve methods and classes by name at runtime, if necessary.
This is especially helpful when you want your application to take advantage of new parts of the Android SDK while still supporting older versions. When using this technique, you must build your project against the older SDK version while running on the new SDK version. The reason this technique works is because you never reference new methods or classes that don’t exist directly in code. Instead, they’re conditionally loaded by passing in strings to the Java reflection methods.
Let’s look at a quick example. To get a method by name, use the getMethod() method (say that ten times, fast) of the static class object of the specific class you are interested in. The following code retrieves a reference to the getExternalStoragePublicDirectory() method of the Environment class using Java reflection. This particular method was introduced in API Level 8 (Android 2.2) and therefore not available in previous versions of the platform:Method methodExternalStoragePublicDirectory;
If the method is available, calls can then be made using the method External Storage Public Directory object, via its invoke() method. You could invoke the method as follows:methodExternalStoragePublicDirectory.invoke(null, picture_directory);
Using these techniques enables the developer to maintain backward compatibility in her applications while taking advantage of the great new features crammed into newer versions of the Android SDK. Used judiciously, this technique can save time and effort and avoid the need to provide different versions of the application for different platform versions (often confusing to users).
It’s best not to over-use this technique—at some point, the application might be using so many of these features that the effort to implement and use Java reflection to support special cases becomes too great. Java reflection also introduces a performance penalty. Making a method call through the invoke() method is slower than a regular method call and common patterns involve placing all the reflection logic in a new class to abstract and simplify the use of it. This adds yet another layer to the call stack, though. This technique also makes your code harder to read and maintain.
Setting Up Your Android Development Environment
Writing Your First Android Application
Understanding The Anatomy Of An Android Application
Defining Your Application Using The Android Manifest File
Managing Application Resources
Exploring User Interface Screen Elements
Designing User Interfaces With Layouts
Drawing And Working With Animation
Using Android Data And Storage Apis
Sharing Data Between Applications With Content Providers
Using Android Networking Apis
Using Android Web Apis
Using Location-based Services (lbs) Apis
Using Android Multimedia Apis
Using Android Telephony Apis
Using Android 3d Graphics With Opengl Es
Using The Android Ndk
Using Android’s Optional Hardware Apis
Working With Notifications
Working With Services
Extending Android Application Reach
Managing User Accounts And Synchronizing User Data
Handling Advanced User Input
Targeting Different Device Configurations And Languages
The Mobile Software Development Process
Designing And Developing Bulletproof Android Applications
Testing Android Applications
Selling Your Android Application
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.