Friday, March 15, 2013

Before Launch Android Application - CheckList




Shipping your Android application: A Complete checklist





I recently completed my 20th Android application. I learned a lot from the project, which was a really a good to understand what to do what don't.

Herewith I'm listing out some point to be follow before the launch of application -

1. You need to sure apps must be in industry standart

Manifest

  • Decide/test what SDK versions you are compatible with, and explicitly set the <uses-sdk> element. Example:
    <uses-sdk android:minSdkVersion="4" android:targetSdkVersion="8"/>
    • You can set the android:targetSdkVersion attribute to indicate which SDK you built against, and for which the app is intended to run on
    • You can set android:minSdkVersion to indicate the lowest revision of the SDK that the app will run against. Apps built against newer versions of the SDK will generally run on older devices, as long as you are careful not to invoke API calls that do not exist in the older SDK.
    • Here is a reference to the various SDK levels and what releases of Android correspond to them.
    • Here are some references for best practices in targeting your app to run on various versions of Android while still taking advantage of the latest OS features:
  • Decide what screen resolutions you are compatible against. Our app is intended to run on medium and large displays, but does not run well on devices such as the Motorola Charm and Flipout, which have Blackberry-style form factors with small screens. So we included the <supports-screens> element in our manifest, with android:SmallScreens="false".
    <supports-screens android:smallScreens="false"/>
  • Is your application intended to run only on a touchscreen, and not on a traditional style (keypad + d-pad) interface?  If so, set the <uses-configuration> elements appropriately. You can specify more than one for an “or”-style grouping of supported configurations. This example says the application is compatible with both stylus-driven (resistive) and finger-driven (capacitance) touchscreens, but one or the other is required:
    <uses-configuration android:reqTouchScreen="stylus"/>
    <uses-configuration android:reqTouchScreen="finger"/>
  • Explicitly set a top-level theme for your application, using the android:theme attribute of the <application> element. Here’s an example manifest entry:
    <application android:icon="@drawable/icon"
                  android:label="@string/app_name"
                  android:theme="@android:style/Theme.Light"
                  android:debuggable="false"
                  android:name="com.myorg.myapp.MyAppSubclass">
         <!-- blah blah blah -->
    </application>

Packaging

  • Clean up unnecessary permissions qualifiers in your manifest. You don’t want to ask for more system permissions than your app really needs. People are sensitive to this stuff.
  • Clean up unused assets (image, audio, layouts, etc) in your res folder hierarchy. It’s amazing how assets can get orphaned as your application’s interface moves through iterations of design. Leaving them in the app only increases the size of the APK and takes up more space on your user’s devices.
  • Turn off debug logging:
    • The Android Log API will antagonize the garbage collector if you do string concatenation in your log messages (and we all do that).
  • Shut off debug menus (unless you want your customers to access them).
  • Change the debuggable=true item in your application element to false (as in the above example).

Resources

  • Externalize view layouts from Java code into XML layout files.
  • When defining styles, it helps to explicitly specify all the attributes that you want to be sure are presented a particular way.
    • Different device manufacturers tinker with the built-in themes, and your application can inherit font, size and color attributes different from what you expected when your application is run on a device different from those you used during development.
  • Externalize resources, such as drawables and color definitions, into XML.
  • Externalize strings into XML.
  • Remove hardcoded pixel constants in your code, layouts, and resources. Use device-independent pixels (dp units in your layout files) wherever possible, and more likely than not things will “just work” when your app runs on different screen resolutions.
  • Include assets as needed for high-density, medium-density and low-density displays.

Application

  • Save application state, terminate threads, and clean up state on onPause/onStop/onDestroy handler methods within your activities.
  • Subclass the Android Application object:
    • Register your subclass by setting the android:name attribute of the <application> element in your manifest.
    • Implement application onLowMemory handler, and be a nice citizen.
    • Implement application lifecycle methods onCreate, onTerminate. Create global items to share between activities in onCreate, and clean up resources as best you can in onTerminate.
  • Implement configChanges in your Manifest and onConfigurationChanged in your Activity classes, to intercept default behavior for system configuration changes. If you don’t do this, Android will kill and restart your activities to handle them:
    • When the user rotates the device between portrait and landscape. The following Manifest example will cause Android to invoke onConfigurationChanged in your activity class when the user rotates the device, rather than Android stopping and restarting your activity:
      <activity android:name=".activity.MyAwesomeActivity"
                android:label="@string/app_name"
                android:configChanges="orientation"
                >
                <!-- remainder of activity declaration goes here -->
      </activity>
      And here is how you would respond to it within your Activity:
      @Override
      public void onConfigurationChanged(Configuration newConfig) {
          // TODO do something here
          super.onConfigurationChanged(newConfig);
      }
    • When the user slides in/out the hardware keyboard on some devices, such as the original Droid/Milestone from Motorola. The following Manifest example will cause Android to invoke onConfigurationChanged when the user changes the keyboard configuration, again without killing your activity:
      <activity android:name=".activity.MyAwesomeActivity"
                android:label="@string/app_name"
                android:configChanges="keyboard|keyboardHidden"
                >
                <!-- remainder of activity declaration goes here -->
      </activity>
    • In both cases, it’s worth noting that you’re intended to respond to the change within the body of onConfigurationChanged. But you can also not bother to override onConfigurationChanged, which effectively disables Android’s activity kill/restart mechanism. You should do this only if you are certain your activity will not be affected by the change in question.
    • More information about configuration changes is available at the official Android developer site.
  • Implement Activity onLowMemory handlers.
  • Make sure background threads are terminated properly on switch between Activities.

External Storage

  • Support application installation to SD card if at all possible. Owners of devices such as the Nexus One, with limited internal storage, will thank you.
  • Properly determine location if you plan to use the SD card for temporary storage.
    • In Froyo (Android 2.2) and later, use the Context#getExternalFilesDir method to get a directory for your temp files, which will automatically be cleaned up by the Android OS if the user uninstalls your application.
    • On earlier releases of Android, you can create a folder in the same place that getExternalFilesDir would provide. When the user updates to Froyo, Android will still auto-remove the contents on app uninstall.
private static final String EXT_STORAGE_ROOT = "/Android/data/com.mycompany.myapp/files/";
cacheDir = new File(android.os.Environment.getExternalStorageDirectory(), EXT_STORAGE_ROOT + dirName);

Networking

  • Ensure your application behaves properly (posts error message, etc) when Airplane mode is enabled.

Battery Life

Most of these suggestions came from the Google I/O presentation Coding for Life — Battery Life, That Is:
  • Try to avoid EDGE/2G for large data transfers – use 3G or WiFi if you can.
  • Use GZIP compression for HTTP access whenever possible:
    • The less time you keep the radio active, the bigger you win with battery life.
    • The CPU used for decompression is fast, native, and negligible compared to keeping the radio running.
  • Reduce garbage collection:
    • Retain a single instance to an object, perhaps as a class member, rather than reallocating it.
    • Set references to null when you are done with them, to release them to the garbage collector earlier rather than later.
  • Recycle Regex Matcher objects:
    • Matcher#reset(newString) to reuse the matcher object.
  • Recycle StringBuilder object instances:
    • use StringBuilder#setLength(0) – good as new!
  • Share static objects (such as StringBuilders) in classes such as ListAdapter, where they get called often.
  • Use stream-based parsers for JSON and XML, not tree-based ones.
  • Keep background services alive only as long as necessary, and run them only as frequently as necessary.
  • Periodic background services should wake up on an alarm, try to run only when the system is already running, and schedule themselves to be invoked “inexactly”, as a group along with other alarms.
  • Fixed-point arithmetic is better than floating-point. ARM processors don’t have native floating-point instructions and must do all floating point as multi-instruction algorithms, which is really expensive.
  • Be careful with wake-locks. They can kill the battery like a vampire.
    • Use a window-managed wake-lock if you can, which Android will automatically handle for you:
    • getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON);
    • Or set the android:keepScreenOn="true" attribute in your XML layouts for controls that must keep the screen alive.
    • Finally, if you must create and manage your own wake-lock, specify a timeout so it will expire if you forget to release it.



Resouces - google, Android and tagged in Android