Revisited Android in Enterprise Mobility ? Part 2
We covered the basics of Android for Enterprise Mobility in part one. This was not meant as a rant against Android but to point out that in the enterprise market stability and longevity are important features of an OS that underpin the supportablity of a deployment. In this post – Revisited Android in Enterprise Mobility we will look into this a little further.
Whilst Android is getting there with many enterprise mobility issues it is coming from the mass adoption by indivuals and carries some interesting baggage. Bottom line is that a device with an Android OS can be an excellent unit when used for the in the right circumstances.
Fragmentation of the many various versions of the Android OS each with different capabilities has come about by the very open source nature of the platform and its incrediable popularity in the consumer market. Open Signal studied this in some detail and the results are quite revealing.
An explaination of the different versions in detail.
Most people with an Android phone are at least on OS 2.1 – Eclair or greater. Versions of above 2.1:
- 2.2 – Froyo
- 2.3 – Gingerbread
- 3.0 – Honeycomb
- 4.0 – Ice-cream Sandwich
- 4.1 – Jelly Bean
- 4,2 – Jelly Bean
As with just about any OS the later the version the greater improved are the features but which one do you choose for your app? Things are further complicated when consumer hardware providers add their own custom layer to differentiate between the competitors. Differing OS versions will require different APIs. If you can access the camera on a Samsung unit, it doesn’t necessarily mean you’ll be able to do the same on your HTC. Even the most experienced device estate managers have found upgrading from one version to a later one can be a tough task. And that’s before you get to BYOD.
Do you make your application native or use a web browser? are all your devices using the same web browser with the same HTML standard?
Screen Size and Keyboard
In a recent tweet Derek Kessler listed all 27 of the screen sizes currently available in the Samsung range. Interestingly Apple iOS screen sizes numbered only 4.
Data input is usually an area most people overlook. Android devices generally use a capacitive screen meaning finger touch only. The obviously causes problems if the user is wearing gloves or has dirty hands. Where a stylus can be used to pinpoint a drop down list, highlight damage on a photo or enter a signature this all becomes difficult when using finger touch.
Android devices have differing screen resoultions and maximize screen estate using an on screen keyboard. But this means application space is reduced on screen when the keyboard is present. Text input can be slow with misspellings common. Windows Mobile Devices designed for the blue collar market can come with a physical keyboard for rapid data entry.
Barcode scanning in another issue. On Windows Mobile units scanners are built into the unit. On Android units you can buy additional handheld scanner connected via Bluetooth. or use the camera. A camera’s primary function is to take photos/video so asking it to scan barcodes in higher volume applications can be painfully slow…..
On a side note – How many games/apps are there for a Windows Mobile device that user can download? Maybe a handful is the answer and the user has to search the internet to find the cab file install. How many games/apps are there Android that a user can download? Thousands! Of course you can lock down an Android device using SOTI device management but this is one factor to consider.
If you have an application which is basic to use with lots of drop downs and limited text input it may work very well on Android. For more complex applications I’d strongly recommend considering your Total Cost of Ownership (TCO) options before buying am inexpensive consumer device for your roll-out.
Do not let the fragmentation of the Android OS put you off using it for your enterprise mobility project. Get in touch to discuss.