Some thoughts about moving development platforms from Windows Mobile (CE) to Android

Version 1

    fs

     

     

     

    Migrating from Windows Mobile/CE to Android

     

     

     

     

     

     

     

     

     

     

     
     

     

    REVISIONS

    REV

    DESCRIPTION

    DATE

    Changed By

    1. 1.0

    Initial Release

    1st September 2015

    Paul Hurford

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     


    Migrating from Windows Mobile/CE to Android

     

     

     

     
     

    1       Table of Contents

    1        Table of Contents............................................................................................................. 2

    2        Abstract............................................................................................................................. 2

    3        Overview........................................................................................................................... 2

    4        Android – getting started.................................................................................................. 2

    5        First Android Application................................................................................................ 3

    6        OS Architecture................................................................................................................ 4

    7        EMDK’s............................................................................................................................ 6

    8        Android what I found bad................................................................................................. 7

    9 Summary................................................................................................................................ 7

     

    2       Abstract

    A major shift in operating systems has led to a new emerging operating system used in the enterprise market, Android.  This white paper discussion some of the migration issues encountered and thoughts from a developer perspective.

    3       Overview

     

    With the windows operating systems Windows Mobile (WM) and CE coming to their end of life (2020) there is a need to migrate to another operating system. Android in the last few years has become the dominant operating system and has become the operating system of choice for new Zebra enterprise terminals.

     

    On windows WM/CE typically you developed an application in .NET or natively using C/C++ using visual studio as the development environment (IDE).  On Android you typically develop in Java with the option of native code (far less common) using Eclipse or Android AppStudio.

     

    I will also cover the EMDK (WM/CE) and the Android EMDK and MX features.

     

    4       Android – getting started

     

    Android has two main integrated development environments (IDEs) to choose from Eclipse or Android AppStudio.  I choose Eclipse as Android studio was in beta and Eclipse/ADT was the supported solution.  Android Studio is now the official IDE for Android development and includes all the Android SDK tools.  Or you can use any text editor and create your own make files, not to be recommended but does work.

     

    I found getting started with Android not too difficult downloading the Android Developer tools (ADT) which includes all the required build environment and IDE (Eclipse).  Compared to installing the Microsoft development environment, Visual Studio it is far more cumbersome and the install not as slick as Microsoft.  There are several stages that you can easily trip up on and found it easier just to re-install if you had any issues.  The ADT does not include the NDK (native C/C++) so this must be downloaded and installed separately.

     

    One drawback I found is that you decide where to install the ADT files – something you need to remember when adding the Zebra EMDK as you must select the correct directory to install into.

     

    5       First Android Application

     

    For my first simple Android application I started with the Android developer tutorials these are fairly basic but do take you through the simple basics of writing an application.  They do get a bit more complicated if you follow the tutorials but they do not explain why/how it works more of type this and this happens.

     

    When you start using Android you do notice some similarities between Windows and Android. One good example is that Android enforces separating out the business logic from the UI so that the UI always remains responsive, so you need to communicate from the worker threads to the main UI, messages are a good way to do this.  Windows works in exactly the same way but did not enforce it but if you did put business logic or code that took too long to execute you would block the UI, leading to “Unresponsive application” messages.  So how you design the code is very similar between the two different operating systems, if you do not you get the same sort of issues.   Android however does have some nice features to help with sending inter-process communication data – more on this later.

     

    One area that was very different was the UI layouts.  With windows its fairly basic simple drag and drop onto a screen using absolute co-ordinates.  But Android has a much more complicate system and it is difficult to initially understand but it is more powerful and does address some of the issues that you have with windows making application device resolution and screen orientation aware. Most windows application did not handle this well but Android has built in.  Eclipse and designing screens is very poor compared to visual studio.

     

    When designing your application the Android terminology is slightly different,

    Android Term                                                 Windows                                

    Activity                                                                       Screen/form (dialog)        

    View                                                                           windows control i.e. text, button listbox

    Dialog generally less content than an Activity         Dialog very similar to a form

    Drawable                                                                    none but collection of bitmaps/resources could be similar

    Intent                                                                           Message and serialization combined.

    Layout resource                                                          resource file but one for each screen, windows one file

    Manifest file                                                               none

    Service                                                                                    Thread, but system services similar to services.exe

    Intent                                                                           message or broadcast message

     

    One major difference to be aware of is that an Activity can be closed and started at any time by the OS screen orientation being an example.  So data persistence is a big issue in Android and needs to be saved when it changes unlike windows where you had control of when the form is closed.  This also has a major impact on how you design your solution and a good understanding of services/threads is required in Android as its likely most solutions will need to implement a service unless it is a very simple application with minimal processing.  With Android it is unwise to do anything in the UI that takes more than a few milli seconds, golden rule is don’t block the UI for any reason.

     

    Going through the tutorials is fairly easy – but it’s a big step up to the next level.

     

     

    This is called the ANR dialog – Application Not Responding.  If you see this message your application UI design is incorrect or poorly implemented. Generally, the system displays an ANR if an application cannot respond to user input. For example, if an application blocks on some I/O operation (frequently a network access) on the UI thread so the system can't process incoming user input events. Or perhaps the app spends too much time building an elaborate in-memory structure or computing the next move in a game on the UI thread. It's always important to make sure these computations are efficient, but even the most efficient code still takes time to run.

    In any situation in which your app performs a potentially lengthy operation, you should not perform the work on the UI thread other than core UI functionality, but instead create a worker thread and do most of the work there. This keeps the UI thread (which drives the user interface event loop) running and prevents the system from concluding that your code has frozen. Because such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic code performance, which is a method-level concern.)

    In Android, application responsiveness is monitored by the Activity Manager and Window Manager system services. Android will display the ANR dialog for a particular application when it detects one of the following conditions:

    • No response to an input event (such as key press or screen touch events) within 5 seconds.
    • A BroadcastReceiver hasn't finished executing within 10 seconds.

    6       OS Architecture

    With windows you had a fair amount of freedom do implement in many ways, some result in poor applications that where badly architected and used system resources in an efficient manner.  With Android this is also true but Android does try and enforce some rules in how you design your application and keep the UI responsive you don’t want any ANR’s.

     

    In windows I found the best way to architect a solution was to keep the UI interface simple and use messages from the worker threads to update any UI fields. This method also works well for Android as the background thread does the work and just lets the UI that it needs to update something. 

     

    Android has threads similar to windows and these do not allow any UI, indeed an exception will be thrown if you try and update the UI.  There is one exception the AsyncTask where you can update the UI via thread but these are designed for work that typically may take only a few seconds like downloading a web page. If you need to keep a thread running then a service is the best way, these can stay running even when the activity has been closed.  Typically an application would bind to the service and then unbind when it has finished and communicate with a message or intent.  The binding process is similar to COM in windows.

     

    Intents

    Intents are used everywhere in Android they are similar to a windows message either sent to an application or broadcast.  Intents however can have data associated with them in several ways unlike the windows message which only allows a DWORD (could be a pointer to memory structure) or WORD.  They are used to start activities (application), inter process communication, starting services, displaying/interfacing to the phone dialer and other Android core applications to name a few.

     

    Applications can choose which intents they receive either via the manifest or via some java code.

    Intent are basically a message that is passed between components (such as Activities, Services, Broadcast Receivers, and Content Providers). So, it is almost equivalent to parameters passed to API calls. The fundamental differences between API calls and intents’ way of invoking components are:

    • API calls are synchronous while intent-based invocations are asynchronous.
    • API calls are compile time binding while intent-based calls are run-time binding.
      Of course, Intents can be made to work exactly like API calls by using what are called explicit intents. But more often than not, implicit intents are the way to. 

    One component that wants to invoke another has to only express its’ intent to do a job. And any other component that exists and has claimed that it can do such a job through intent-filters, is invoked by the android platform to accomplish the job. This means, both the components are not aware of each other’s existence and can still work together to give the desired result for the end-user.

    This invisible connection between components is achieved through the combination of intents, intent-filters and the android platform.

    This leads to huge possibilities like:

    • Mix and match or rather plug and play of components at runtime.
    • Replacing the inbuilt android applications with custom developed applications.
    • Component level reuse within and across applications.
    • Service orientation to the most granular level, if I may say.
    • Here is additional description about intent, almost formal.

    Manifest

    WM/CE does not have the concept of the manifest (later Windows versions do). Every Android application must have one. It names the Java package for the application. The package name serves as a unique identifier for the application. It describes the components of the application — the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implements each of the components and publishes their capabilities (for example, which Intent messages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched.   It determines which processes will host application components.  It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.  It also declares the permissions that others are required to have in order to interact with the application's components.

    It declares the minimum level of the Android API that the application requires. It lists the libraries that the application must be linked against.

    Threading

    A quick note on threading.  Windows is fairly straight forward here create a thread and do something Android is similar but you must chose the correct way to implement that thread whether via a service, AsyncTask or just a thread, in each case you would normally sub class the base class and create your new class.

     

    One issue that was common in windows was that developers would start several worker threads and then have no mechanism to close them down cleanly and wait for their exit, often leading to applications to crash or hang on exit. Android has several features like windows to help here, in windows you typically would use events and wait objects to wait for a thread to close.  To signal a thread to close you can use the thread interrupt method, if in a wait function it will cause an exception to be thrown which you can catch or if in a loop would have to poll the interrupted flag of the thread.  To wait for a thread to exit you can use the wait/notify mechanism that all objects implement in java.  Another method is to use the ExecutorService this would allow you to wait for several threads to exit with a timeout.  Similar to windows WaitForMultipleObjects.

     

    Message Handlers – Runables.

     

    Android supports very similar concepts to windows in sending and handling message.  You send a message (integer number) with some optional parameters. Windows mechanism is fairly basic compared to Android you can send two values a dword and word, although the dword could be a pointer to some data.  Android has the same with arg1 and arg2 – you can also pass an object so a class and type cast and you can pass a bundle of data as well all basic data types supported.

     

    But what is really useful in java is that you can pass a runnable as the message. A runnable is a function (java code) so you can actually send a message that then executes some code and allows parameters to be passed as well.  Windows does not have this concept at all (unless you count pass pointing to a function). I find this concept very useful and has many uses when you design an application.

     

    7       EMDK’s

     

    The Zebra Windows EMDK has a rich feature set mainly because the OS lacked any native APIs in this respect.  Android however has many of the APIs found in the windows EMDK built into the OS as standard meaning that the Android EMDK appears to have less functionality, which is not the case as the core OS now supports this functionality instead of the EMDK.

     

    When you install the Android EMDK you must ensure you store in the correct location in the ADT directory. Windows/Visual studio automatically installs with very little user intervention.

     

    Android profile manager

    A quick note about the profile manager, this is used for controlling system parameters that are normally privileged in Android.  Such settings as controlling hardware power state, rebooting setting time etc.  You pass in some XML that describes the actions you wish to occur; this is the equivalent of the windows API DMProcessConfigXM.

     

    The profile manager works well for static profiles (settings) but when you need to create a dynamic profile I found some issues, in that you must use same profile names etc.  Also parsing the response back is a lot of work, far more than a simple API – say setTime that returns true/false.  If you use the profile manager suggest you wrap and test fully and do check returned XML. If you are an MDM then you have other options.

     

    You can control the radio power settings (on/off), WAN/GPS/BT/NFC/Ethernet with profile manager– but not WLAN through profile manager because you can do this with native code.  But means if you are doing a staging solution you cannot use XML but must write an application.

    8       Android what I found bad.

     

    On the whole Android is good but some areas I found frustrating.

     

    Eclipse

    As an IDE it does work and allows you to write Android applications.  But I do find it buggy and does hang, started with Juno now migrated to Luna which I find more stable.  I found it initially difficult to navigate my way around the menus and restoring settings that I had accidently screwed up.  Adding in libraries did cause some issues initially but now I am more familiar and learned from my mistakes.  It’s not a as slick as Visual studio and not as intuitive which is a shame.  Creating activities and layouts I found it very poor at again some improvements would go a long way.  I have not tried AppStudio so no idea if that is better.

     

    Android API depreciation

    Many APIs that you read about/google examples when you implement is deprecated Android APIs appear to change on a whim.  Windows in this respect is very good.  With typically two major OS releases a year it’s a major issue.

     

    Android Closing activities

    Would like android not to be aggressive here and let user close the application, also screen rotation why restart the activity?  Just have to live with this and ensure you persist any data.

     

    UI Layouts

    Too much of a black art.  Eclipse does not help either.  It is really worth spending time up front learning about layouts before you start any tutorials.

     

    Bad apps

    Android makes it easy to hack together a bad application that appears to work. This experience made me realize

    Why many Android apps suck: it's hard to do things the right way and easy to hack it together the wrong way.

    9 Summary

    Android has a very rich set of APIs and concepts to allow you to implement well-structured solutions this is something that I did not appreciated when I started; I just assumed it’s a small mobile phone and would be limited in what you could do.  This is not the case and I would even go further in that Android is as good if not better than windows in many areas and certainly fulfills the needs of the enterprise developer.

     

    Also the similarity with windows in several key areas helps but you may not notice this until you start to dig into Android a little deeper and start to design a solution.

     

    Android is powerful but it is easy to implement a poor solution as there are so many ways of doing the same thing.