Designing Apps for Motorla Xoom Tablet

Editor's Notes

• #2: My name is Anna Schaller and I’m part of the Developer Community Tech Services Team at Motorola Mobility. Our job is to support 3 rd party developers writing android apps, especially targeted for Motorola devices.
• #4: Walkthrough of device from users perspective -- home screen; 5 panels -- upper left is the text and voice search -- upper right is the application tray and add to home screen -- Partial list apps preloaded and optimized for the tablet include -- gmail -- contact -- maps -- browser -- android market -- eBook reader -- google talk -- camera Walkthrough of specs
• #5: This is a typical Android smartphone. Across the top is your status bar where your status icons appear (battery, wifi, etc). This is also where your notifications can be found. Touching the status bar opens the notification panel. Moving to the bottom of the device, is where you’ll find buttons. Prehoneycomb devices were required to have 3 buttons – menu, home, and back. There’s usually a fourth button (in this case search). So that’s a typical smartphone.
• #6: When you’re talking about tablets things change. On the hardware side there are only three buttons on the device – volume up, volume down, and power.
• #7: Then when you talking about the platfom the whole user interface has changed.. From an apps perspective there are a couple things you should be aware of. For instance… You have the system bar along the bottom. The back and home button on the lower left. There is NO menu button. Menus are now all in software and only available from within an application. On the lower right is where your status bar icons now appear as well as you notification panel. From a user perspective there’s much more to it but from a developer’s standpoint, those are the things you should be aware of. They won’t necessarily impact your application but it may change the way you think about things.
• #10: Select a view that you want to associate the dimmer with (I have an id assigned to my root linearLayout) and set the visibility. You can attach the call to any view (including buttons) so may want to toggle it off and on with a button or putting inside any listener. If you touch the system bar the icons reappear. Touching the view dims the system bar. Book reader is a good example of dimming.
• #11: Replaces the title bar. This is the simplest form of an action bar. The Action Bar is included by default in all activities that target Android 3.0 or greater (setting minSdk or targetSdk = 11) Basic action bar with an overflow menu. The menu in the action bar replaces the hard menu button on the front of the device. The default behavior for the application icon is to do nothing. The title can be displayed or hidden.
• #12: Action bars get more feature rich from there. There are many extensions you can make to the action bar including -- actionable application icon with R.id.home in onOptionsMenuSelected -- adding tabs -- creating individual actionable items with or without text and titles -- Provide a drop-down list for navigation -- Provide a contextual action bar (CAB) -- Provide interactive "action views" in place of action items (such as a search box).
• #14: One final note on menus. To support forward compatibility a soft menu button is provided along the system bar for pre-honeycomb apps. If you open the menu you can see where and what the menu items looks like.
• #15: Starting from Android 1.6 and up developers can divide the Activities of their applications into subcomponents called Fragments. Fragments -- can be added, removed, replaced, and animated inside an Activity dynamically -- are modular and reusable across multiple Activities. Here we’ve got the updated version of the contacts app showing the list of contacts in a fragment on the left and the details of the selected contact in a fragment on the right.
• #16: Fragments can not stand on their own. They must be included in an activity. However fragments are self contained in that they have their own life cycle and every visible fragment has their own UI layout. One of the most common ways to use fragments is to associate a content fragment with an item in a list. There’s a separate type of fragment, called a ListFragment, that lets you do this. The content fragment can contain anything you would normally use in an activity – images, text, ui elements, etc.
• #17: To add a fragment without a UI, add the fragment from the activity using add(Fragment, String) (supplying a unique string "tag" for the fragment, rather than a view ID)
• #18: (Nothing changes in the AndroidManifest file) Adding a fragment to an activity requires updates to the activity’s layout file. You must add the fragment to your Activity’s layout file with a <fragment> tag. In the fragment tag you declare the class name of the fragment that’s defined usually in a separate .java file. Pay attention to the root layout or container you use. In this case I used LinearLayout which, by default has a top to bottom placement. So when I first did this app my fragments did not appear side-by-side, they appeared top-to-bottom. I needed to add orientation=horizontal in order to get the side-by-side. The device’s orientation is landscape by default so if you want a portrait version of the app to be top-to-bottom you’ll need to create another layout-port file specifying orientation=portrait.
• #22: In Android you can get hardware acceleration for 3d graphics through OpenGL ES 2.0 if you are using NDK. There is also software-enabled acceleration for 3d graphics using OpenGL ES 1.x. Until now there has been no support for 2D graphics..
• #23: Textures improve a 3d model with a visual realism that goes beyond just adding color. However the more detailed the textures become the larger the data size becomes which means that quite often you need to compress the texture data. The challenge for Android-powered devices is that the chipsets used in the devices support different compression types. So what do you do? PVRTC == Motorola Droid series ATITC == HTC S3TC == XOOM, Atrix, Bionic Android Market filters applications according to the texture compression formats that they support, to ensure that they can be installed only on devices that can handle their textures properly. Developers can use texture compression filtering as a way of targeting specific device types, based on GPU platform
• #24: Android Market filters applications according to the texture compression formats that they support, to ensure that they can be installed only on devices that can handle their textures properly. Developers can use texture compression filtering as a way of targeting specific device types, based on GPU platform
• #26: Follow instructions for using Data Storage to external media http://developer.android.com/guide/topics/data/data-storage.html Every Android-compatible device supports a shared storage. Shared files: Music/ - Media scanner classifies all media found here as user music. Podcasts/ - Media scanner classifies all media found here as a podcast. Ringtones/ - Media scanner classifies all media found here as a ringtone. Alarms/ - Media scanner classifies all media found here as an alarm sound. Notifications/ - Media scanner classifies all media found here as a notification sound. Pictures/ - All photos (excluding those taken with the camera). Movies/ - All movies (excluding those taken with the camcorder). Download/ - Miscellaneous downloads. Private files can be placed in /android/data/<appname> folder.
• #28: In 2.3 (Gingerbread) support for new sensor-based orientation settings were added that better supports 4-way rotation In your manifest at the <activity> node you can specify <activity …. android:orientation=“sensorPortrait” : supports portrait and reverse-portrait android:orientation=“sensorLandscape” : supports landscape and reverse-landscape android:orientation=“fullSensor” : supports 2 and 4-way rotation depending on device X and Y on portrait native device are on different long and short sides than landscape native.
• #31: Still need to define camera permission to use either camera If you want to filter the app from devices that don’t support front-facing camera add <uses-feature xxx…android.hardware.camera.front/>
• #32: There is a new package android.hardware.Camera.CameraInfo that stores properties of each camera. So you import this package, along with the Camera package. The Camera package now lets you get the number of cameras on the device so you can use this as an index to the camera. Once you have that index you can get to the front or rear camera.
• #33: XOOM screen supports 10-point multitouch – Android supports 5 or more simultaneous independent pointers.
• #35: Device perspective versus app perspective Think about why you need the unique identifier. If
• #38: Apps are always forward compatible but……
• #46: There is no way to make a phone call from the XOOM so dialer app is not there. If you call the dialer from your application it will not launch. Unless you explicitly specify the <uses-feature> tag, permissions imply that features are required. Permissions do not filter an app, the <uses-feature> tag does that. If you request permission for the Telephone without specifying a <uses-feature> tag the default filter is <uses-feature android:hardware.telephony” android:required=“true”/>. In this case your app will be filtered from the XOOM. Also keep in mind that on the wifi-only version of the tablet there is no IMEI or MEID, which in the past has been used as a unique identifier. If you query for it you get NULL. If you need a unique id, use the MAC address.
• #47: To find out what features may be blocking your app from a device there are two tools you can use: -- Aapt shows explicitly defined features with <uses-feature>. You must use the version of aapt that is provided for the latest Platform-Tools component available. -- MOTODEV App Validator is a web-based tool that lets you pre-test your application and show you where your app might fall through the cracks – such as implied features (permissions defined without a corresponding <uses-feature>). It shows you other things as well such as strings that are not completely localized.
• #52: There are two new features in 3.1 to support USB. Firstly there is built-in support for USB host mode that lets apps connect and manage peripherals. The device itself must have a USB controller, which the XOOM does. So the XOOM can operate in USB host mode. The second update is USB support for connected devices. There are two types of hardware supported: -- Peripherals can be a USB device meaning that they depend on the Android device to be the USB host. Cameras are a good example of this. -- Peripherals can also be a USB accessory meaning that they operate as the USB host to the Android device. A robotics controller is an example of this. At Google I/O they had an exercise bike with a mounted XOOM. The bike was the host and reported calories burned after pedaling some distance to an app on the XOOM.