Jeff Hines, Kindle Fire test team, and Chirag Mehta, Michael Siwapinyoyos, and Steve Johnson, a2z Developer Center Inc., an Amazon.com company, are our bloggers for this post.
The second post in our optimization series discusses optimizing your app’s layout for Kindle Fire and accounting for the soft key bar.
In addition to the Settings bar that we mentioned in our previous post, Kindle Fire also has a soft key bar that is present at all times. Rather than physical buttons, Kindle Fire uses soft keys to display the standard Android buttons (i.e., Home, Back, Menu, and Search).
Optimizing your app for the soft-key bar provides a more positive customer experience. In this post, we present optimizations and sample code to address frequently asked questions and common issues you may encounter when developing your app for Kindle Fire.
How do I optimize my app’s layout for Kindle Fire?
When developing exclusively for Kindle Fire, please ensure that your app is optimized for the following specifications:
- A “Large” 7” screen size
- A Medium Density (mdpi) screen with an abstracted LCD density of 160
- 600 pixel width by 1024 pixel height in portrait mode
Note that the Kindle Fire will reserve 20 pixels to display the soft key bar, as stated previously; therefore, the true pixel height, including the soft key bar, is 1004 pixels in portrait mode.
Apps optimized for Kindle Fire should take advantage of the large screen size. Your app should scale its interactive elements accordingly. This provides the best possible customer experience.
Use these screen specifications even if your app is not optimized exclusively for Kindle Fire. A best practice is to create resources specifically for large screen devices with medium density displays (mdpi).
To scale a background image, specify taking as much space as available within the layout element, using the following code snippet:
<ImageView
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:scaleType="fitXY"
android:src="@drawable/yourbackground"
/>
Use the Bitmap.createBitmap() method with caution. While it can scale resources to fit the screen, it can also take additional computing cycles and require a lot of additional memory.
Please note that Android does have a built-in resource selection algorithm that will attempt to match declared resources with the characteristics of the device that your app is being displayed on. More detail regarding multiple Android screen support can be found here: http://developer.android.com/guide/practices/screens_support.html.
How should my app handle rotation on the Kindle Fire?
While not specifically about your app’s layout, errors with orientation changes are frequently encountered. Rotating a device from landscape to portrait (or vice versa) without the appropriate optimizations can result in the following issues:
- Your app force closing
- Crashing or returning users back to the carousel on Kindle Fire
- App state or user save becoming lost or reset
A screen orientation change will always fire the onCreate() event, destroying and recreating the activity. If you do not take this into account, you could run the risk of a negative user experience.
To properly handle a screen rotation and avoid the issues outlined above, you can follow these best practices:
- Name the views in your activity using the android:id attribute. When there is an orientation change in your activity, Android will persist the state of a named view and restore it once the activity is recreated. When an activity is destroyed, the state is saved only for named views.
- The onSaveInstanceState() method is fired when an activity is destroyed. You can override this method to save your app state. Once the orientation change is complete, and your activity’s onCreate() method is called, onRestoreInstanceState() is automatically called. This method can be overridden to restore you app state. This mechanism relies on simple data structures to be used; i.e., state information needs to be structured in a Bundle object.
- If your app needs to save a complex data structure, then you can use the onRetainNonConfigurationInstance() event. This event returns an arbitrary Object event, so you can persist as complex a data structure as is necessary for your app. Call getLastNonConfigurationInstance() inside your onCreate() method to retrieve your activity state, but remember to cast the class properly.
Although not the best solution for all apps, preventing orientation change will allow you to avoid these issues entirely. To lock your app to a specific orientation, include the following entry in your manifest file.
android:screenOrientation="portrait|landscape"
How can I effectively use the soft key bar?
The soft key bar enables simple, quick, and efficient navigation from within your app and all other aspects of the device.
The soft key bar has two positions: maximized and minimized. When minimized, the soft key bar takes up 20 pixels and displaces your content. When maximized it takes up 60 pixels; 20 pixels displace your content and 40 pixels sit on top of your content.
How should my app interact with Kindle Fire’s soft key bar?
To be compatible with Kindle Fire, apps must account for and interact with the soft key bar. The soft key bar contains four different soft keys:
- Home
- Back
- Menu
- Search
Using the Home Soft Key
Kindle Fire uses these keys to display the standard Android device buttons. Apps must appropriately use the Home soft key to allow quick navigation to and from the Kindle Fire carousel.
By default the Home soft key returns users to the Kindle Fire carousel. When the home key is pressed, the current activity’s onPause() method will be called before the user is presented with the carousel. When your app is re-launched, the onResume() method will be called. In order to ensure that the app returns to its previous state, your app should save state in the onPause() method and reload the state in the onResume() method.
For more information about the onPause() and onResume() methods, please see our previous blog post in the Top 10 Optimizations for Kindle Fire series.
Using the Back Soft Key
The Back soft key's default action is to call finish() on the current activity and then resume the previous activity on the stack (as managed by the OS).
If your app has launched several activities and you want the Back soft key to return the user to the previous activity, then you don't need to do anything—this is the default behavior. If the user is already at the main activity of your app, the Back soft key will call finish() on the activity and exit your app.
A typical solution to prevent premature exiting of the app is to override the Back soft key functionality on your app's main activity to trigger a confirmation dialog. Override the function of the Back soft key in an Activity by including the following code in the Activity class:
@Override
public void onBackPressed() {
// do something when the back button is pressed
return;
}
Stay tuned for our next series post, as we tackle device hibernation!
