This blog was generated from CDN blog Created by: Larry Michalewicz on 08-04-2013 09:18:48 AM Designing Applications For the DX650 Writing applications for the DX650 is no different than writing applications for any other Android device. With that being said, a very common questions about our device and I’m sure other devices as well, is “Why doesn’t my app work on your device?.” My standard answer is “Because you did something wrong!” Obviously, that’s not a fair thing to say without more information. To understand the problem with modern devices, you have to take a brief look at the history of Android. To gain access to Google applications like the Play store a device must meet rigorous standards as defined at http://source.android.com/compatibility/ . The Android Compatibility Definition Document (CDD) and Compatibility Test Suite are used to define the standards and test that a device meets the standard. To fully understand why some applications don’t work on some devices, you have to look at the history of the CDD. For example, in version 1.6 (Éclair) the rule regarding the Camera is: Device implementations MUST include a camera Not much wiggle room there because in a formal specification, MUST means just that, it’s required and non negotiable. If you fast forward to the version 4.0 (Ice Cream Sandwich) CDD, it says: Device implementations SHOULD include a rear-facing camera and May include a front-facing camera. This is obviously a big change in the definition (a good one in my opinion), and it adds some complexity that developers need to deal with. Why would the definition change? In the beginning all Android devices were pretty much the same. As time passed there was a desire to have devices in different sizes and shapes, and it really didn’t make sense to force them all to the same characteristics. Another quick example. In Android 1.6 compatible devices were required to have an Accelerometer, Compass and GPS. In 4.0, the requirements are that a device must correctly report the sensors that it has and that the sensors must report accurate and genuine data (no fake sensors allowed), but there is no requirement that a device has any sensors at all. As Android changed, one thing they tried to do was preserve backward compatibility, so in many cases, an old app will work on a new device. There are exceptions of course, for example, if an application was written when cameras were required, that application will likely have problems on a modern device with no camera at all. So what’s the best approach to dealing with the fact that many different devices exists. I’ll suggest three methods Google Play Filtering Runtime Detection Just Deal With It (my favorite) Google Play Filtering All devices that access Google Play must passed the compatibility tests which means they must accurately report their features. For example: these are the features reported by a DX650 feature:reqGlEsVersion=0x20000 feature:android.hardware.bluetooth feature:android.hardware.camera.front feature:android.hardware.faketouch feature:android.hardware.location feature:android.hardware.location.network feature:android.hardware.microphone feature:android.hardware.screen.landscape feature:android.hardware.touchscreen feature:android.hardware.touchscreen.multitouch feature:android.hardware.touchscreen.multitouch.distinct feature:android.hardware.usb.accessory feature:android.hardware.usb.host feature:android.hardware.wifi feature:android.software.live_wallpaper In the Manifest for your application, you can if you want ,define various device requirements such as screen size, the presence of a rear camera or other device specific features. Google play looks at both the device requirement in the application Manifest and the features reported by the device and filters (removes) any applications that require a feature that doesn’t exist on a specific device. If you’ve ever wondered why applications are available for some devices and not others, now you know. You can get a full explanation of how this works here: http://developer.android.com/google/play/filters.html This filtering feature is great for applications that are deployed from Google Play, but as an application developer you may want to have the ability to deploy your application via other means, or you may simply want more devices to have access to your application. Runtime Detection Many problems can be solved before they exist by simply writing good code. As devices have change Android has done a great job of adding the ability to determine device characteristics at runtime rather than just assuming that the device had a specific feature. Take the Camera for example. Prior to Android version 2.3 the Camera had a simple “open()” method that returned the “default” camera which must be a back-facing camera. In Android 2.3, the front cameras were first allowed and all cameras became optional, new APIs were added to allow your application to get the number of cameras, the type of camera (front, back) and a new “open(int cameraId)” method that allows you to specify which camera you want to use. In my opinion, no modern application should ever use the old Camera.open() method, but instead should use the modern APIs to detect the cameras and open the specific camera that it needs. For a good example of detecting capabilities at runtime, check out James Catalano’s blog on using the from camera . These same techniques can be used for other device dependent features. Dealing with different screen sizes and resolutions is another complex subject. The Android Developer site has several great guides include “ Supporting Multiple Screens ” and “ Designing for Multiple Screens . Just Deal With It Detecting capabilities at runtime and writing your code to adjust accordingly is a good first step, but you can do more. Rather than just failing gracefully if a feature doesn’t exist, I think you can go one step further by writing your application to adapt, or “deal with” whatever capabilities are present on a specific device. For example, the DX650 doesn’t have a GPS. Is this a problem? Not really. GPS is a very low power signal and most GPS radios don’t work well or even at all indoors. Also, a DX650 isn’t a mobile device, so exact location isn’t necessarily as important as it would be for other devices. But what if your application needs to know your location when recording some event, or because you want to show businesses nearby. Not a problem. One of the Google services is a Wi-Fi based location technology, known as “Course Location” on Android. Remember above when I said a device “must correctly report the sensors that it has”. The DX650 reports Course location, but not Fine (GPS) location. Applications can be written to use Fine Location, Course Location, or even both depending on what is available at runtime. Cisco DX650 Device specifics Now that you understand the potential problems and several solutions, it’s worth mentioning a few of specific characteristics of the DX650. Screen Size: 1024x600 Screen Density: 160dpi also known as mdpi Orientation: Landscape Cameras: 1 Front Facing Camera Sensors: None Location: Course/Network based only Conclusion Taking full advantage of the tools and APIs available in Android is key to writing stable, well-behaved applications that work on a variety of devices, now and in the future. Even if you are only targeting a single device, like the DX650, I encourage you employ the best practices described above.
... View more
