Enterprise mobility and Android

Its quite some time after the GoogleIO. Have been busy digesting some info and thinking a lot. Just a day before IO, I wrote some of my thoughts on Enterprise mobility. Today, I'll try and visit certain aspects in detail as well as try to list what Android has to offer as of now.

Now, from current trends in market and from my understanding till date, I see the current enterprise mobility having 3 components as follows :

1. Device Management
2. Security
3. Application management

Enterprises looking for a complete mobility solution are mostly looking at these three areas. I'll try to briefly touch on each of these and discuss what Android has to offer (and not offer) to enterprise mobility. [For clear separation, I have marked Android Specific details in BLUE : I know Green (#A4C639) would have been appropriate, but I didn't think it was good for reading :)]

1. Device Management :  Device management (DM) mainly deals with being able to remotely alter certain aspects of the devices. Again, I see DM being split into the following.



i. Provisioning deals with mass deployment of various settings on large number of handsets.  For instance, provisioning the devices with corporate WiFi information, VPN access parameters and configuration of email settings etc... For the IT department, being able to provision these settings is beneficial since it helps them carry out the tedious task as well as reduces chances of human error and avoid complex email instructions.

Blackberry and iOS have most of the DM functions baked into the platform. This means, one can configure a DM server (may require manual steps). Once configured, the DM server can send commands to the device which will be understood by the device platform and reacted accordingly.

Android, however, requires an on-device management agent (aka Device administrator) which should implement the Device Admin APIs (Android 2.2 onwards) in order to perform any of the DM functions. Furthermore,  Android doesn't support provisioning out of the box. Rather of all the top IT demands (WiFi, VPN, Exchange etc...), only WiFi can be configured programmatically by the on-device agent.

ii. Device Control deals with being able to remotely take certain actions on the device that may affect the end user. E.g. device lock, unlock, wipe, set/reset password.

With the device admin software installed, Android can do these basic device control functions like device wipe, lock/unlock and set/reset password.
There is however one way to achieve device control functions without having to install any device admin. The trick here is that most Android devices ship with a Email application which can be configured with Exchange information. By default Exchange uses the ActiveSync protocol for syncing mails. Of lately (I guess Android 2.2 onwards), I have seen that while configuring Exchange, the platform shows the standard Device Management screen asking for adding the Exchange as a device admin. If you do this, then by configuring the Email, you can execute device control commands like lock/unlock, set/reset password, wipe etc... To check this go to Settings -> Location and Security -> Select Device administrators. You should be able to see Email application being listed if you have configured Exchange (ActiveSync ).

iii. Device Policies : Policies allow enterprises to control certain settings of the device. This is different from provisioning in that policies can be considered as 'enforced' settings. While someone may change the provisioned settings, device policies are not "meant" to be changed. On Blackberry and to some extent the iOS, the platform restricts the user from changing any policies set by the IT administrator. These policies may include restrictions on the browser to disable javascript, avoid using the phone as USB storage device, disabling camera, etc...

Again, in the case of Android, you will need the on-device admin app to control (only) a subset of what the IT demands traditionally. Basic policies like enforcing a device password, password quality etc.. are supported out of the box with the Device admin APIs.

2. Security : By far, this is THE feature enterprises cannot live without. When enterprises allow data to be accessed remotely, its security is of prime importance. There are 3 components related to security that I visualize as follows:



i. Encryption : Any data that is stored by any application as well as any data that is communicated to and from the device, needs to be encrypted.

Android apps can use SSL tunnels through with data can be transported. However, the data stored on the device (phone memory and SD) is up to the applications. Prior to honeycomb (Android 3.0) there is no support for turning on encryption on the device. Even with Honeycomb, a device administrator application can request for the encryption process to begin, and it will start the encryption ONLY IF it is supported by the device on which the agent is running. Things are still pretty unclear about the way encryption is supported (hardware vs software etc...). One of my previous posts raises these issues. I'll update both the blog posts once enough information is available.

ii. Device Policies : I have purposefully included policies again under Security. I think this link is important to note. This is just to remind that policies are restrictive settings enforced in order to avoid security compromise.

iii. Compliance : Now, we have policies in place. And as I said these need to be enforced on the device. However, it may happen that the user knowingly or unknowingly changes some setting that violates certain policy (that cannot be technically enforced on the device - technology limitation). This may put corporate data at risk. It is important for the IT to determine such instances. This leads to constantly monitoring the device and making sure that it is "in compliance" with the policies.
Usually, compliance checking may be done on the server that monitors the device. This can be achieved by querying the device for certain parameters periodically and then running the compliance rules against the values received. These rules usually test whether the device adheres to all the policies, if not then the resulting actions could be anything from blocking corporate access for that device to wiping the device. This totally depends on the IT policies for the enterprise.

The device admin app can play the role of reporting parameter values to the DM server. To monitor Android for certain metrics, the server can implement the Google C2DM (cloud to device messaging discussed in this blog post) to send query messages to a device admin app which can reply back. 

3. Application Management : One of the basic goals for enterprises is to mobilize the business. As a result, enterprises have started mobilizing many internal applications. So, as a part of enterprise mobility, the IT also has to manage the mobile apps. Application management (AM) can be again viewed as having the two main functions :



i. Monitor/Debug apps : Since most of the applications may be internal apps, the development and testing phase becomes critical. Also, since these apps may directly affect employee productivity, debugging these apps during development and after deployment is crucial too. One of the tasks of AM is to help the development and debugging process easier. Once the app is in production, AM can help monitor the status of apps and surface any problems earlier. Monitoring of apps may also refer to getting an apps inventory and determining "blacklisted" apps from security point of view. This may tie back to compliance.

ii. Deploy / Remove apps : With many such applications there is a demand for Enterprise application catalog on which apps would be listed and shown/accessed depending on the role of the employee. Since these apps may contain critical corporate information, it is important for the IT to be able to control these apps remotely. Being able to install, remove these apps is one of the most popular demands from IT.

With Android, anyone can "sideload" an application. This means all the application (apk) files can be accessed via a webpage. However, there are few points to note. In order to install any application that is not listed in the Android Market (consumer app), one has to enable a setting called applications from an "Unknown Source". While doing so, the user gets a dreaded message that may scare him off. Also, it is worth noting that there is currently no official way to push the application on the device and install/uninstall it without the user intervention. If you already have your device admin agent on the device, then it can download the app binary and trigger the install process or trigger the uninstall process of an existing app which will redirect the user to the install/uninstall approval screen. There are some app markets (like AppBrian) which have (with limited capabilities) "managed" to remotely push and install applications on Android phones. However, there is no official way to do so.

So, here is a complete picture of how I see Enterprise mobility as of now:




To summarize, Android really doesn't have much to offer at this moment apart from few Device Admin APIs and Encryption (hardware dependent - 3.0 onwards). With the growing demand for Android and the changing trend of Employee liable devices, it certainly is a challenge for IT. The Google enterprise team unfortunately didn't seem to address most of these issues and didn't seem open to a lot of questions posed at the GoogleIO. The talk at GoogleIO can be found here : (http://www.google.com/events/io/2011/sessions/taking-android-to-work.html) I hope they have some plan for the Enterprise mobility because the wave has just begun.

Understanding Enterprise Mobility

[I'm sitting at a Starbucks waiting for the GoogleIO registration to open up. There is an interesting session 'Taking Android to work' which I'll be attending. Google's approach to enterprise mobility seems to be different than Blackberry or Apple : they don't have anything baked into the platform. The GoogleIO session will hopefully provide more insights into the future path. If you are an attendee and interested in this topic, I would definitely love to have a chat with you. You can follow me on Twitter : @advantej ]

For the past few months, I'm trying to understand the enterprise mobility space. It had kind of existed in the past but emerging again with a new face altogether. Its definitely a larger wave than the earlier one.

A look into the past: 
Laptops introduced mobility into enterprise. There were cell phones before, but those weren't 'smart' enough. Their primary purpose was just to carry out conversations. Laptops made it possible to take the work with you. There was also a short period that showcased Personal Digital Assistants (PDAs) which were rather bulky to carry around and capabilities mostly limited to managing your schedule, taking notes and some basic messaging. But the truly workable mobile devices were laptops.

The Enterprise Viewpoints: Two sides of a coin
The Good:
For enterprises, mobility means a lot. It is a means of growing business, capturing opportunities and bringing back information, knowledge, keeping the organization going on, no matter where the people in the organization are. Be it the CEO, CTO, marketing or sales people or any other management folks or your awesome engineers: mobility builds the necessary bridges whenever it matters to achieve the required goals.

The Worrisome:
However, practically this means accessing company resources from devices and environments on which enterprises may not have any control. While mobility helps enterprises grow the concern about information security in uncontrolled environments makes enterprises take a step back.

In the laptop/PDA wave, managing devices was pretty much conventional. There was nothing new to do at least for the laptops because they had to deal with the same operating systems on laptops for which IT management was already being used for a long time.

For pretty much long time, RIM provided enterprises with a solution to control the Blackberry mobile devices, enabling them to configure, manage and enforce policies on the devices.

With Apple and Android powered devices entering the consumer market with different form factors, mobility has a new face. Not just that there are a lot of devices from different vendors and operating systems, its the fact that employees are consumers first. They are pretty much demanding the use of devices of their choice for accessing enterprise resources. Moreover, people don't like to carry multiple devices : a personal device and a company owned device. They want it there - all in one.

The challenge for the IT is to support multiple mobile devices ensuring safety and security of enterprise resources. Apart from security which is central to enterprise mobility, IT demands being able to configure devices no matter what OS its running.

Being a newbie to this space, I think of a lot of questions that I'm trying to answer. With many enterprise applications emerging, is enterprise mobility management limited to managing just the devices ? What about the applications ? Do we need to control and analyse those too ? With employee owned devices is it acceptable to enforce enterprise policies all the time ? Some policies require control over the hardware as well. In my masters thesis, I explored context awareness frameworks for mobile devices and prototyped one. I was wondering if it makes sense to exploit user context for enterprise policies. This may help in selectively applying policies depending on user context. This may help develop a win-win situation where employees don't feel controlled all the time but would be able to access the required resources. (For curious reader : here is an interesting academic research project trying to identify high level contextual aspects for a mobile user.)

Have got these questions and many more.... but one thing for sure - this wave is very large, unavoidable, with a lot of challenges and comes with competitive problems for the architects and engineers to solve.


[Thank you Starbucks for the internet !]

Android Thread Constructs(Part 4): Comparisons

In this series of posts we have seen the following thread constructs:
1. Basic threads and communication between them [see article]
2. Understanding the Main thread or the UI thread [see article]
3. IntentService [see article]
4. AsyncTask [see article]

NOTE:  These are Android specific constructs. Android also includes the java.util.concurrent package which can be leveraged for concurrent tasks. That is out of the scope of my discussion.]

So, when to use what ? What is the exact purpose of each ? What are the drawbacks of using one over the other ? Which one is easier to program ?

I came across all these questions when trying to understand each of these. In due course of time, I have come up with some guidelines which I discuss in this post.

NOTE: Any of the recommendations made in this post and the table below are not comprehensive and final. There may be better and alternate ways of doing things. I would love to know any different views and get an insight into a different thought process. The views expressed in this post are my personal views.

Service
Before proceeding further, let me touch on the Service class. Traditionally speaking, the notion of service reminds us of task running in the background while we can work and interact with the UI. This causes confusion for newbies. Because in Android, even if the Service runs in the background, it runs on the Main Thread of the application. So, if at the same time if you have an activity displayed, the running service will take the main thread and the activity will seem slow. It is important to note that a Service is just a way of telling Android that something needs to run without a user interface in the background while the user may not interacting with your application. So, if you expect the user to be interacting with the application while the service is running and you have a long task to perform in a service, you need to create a worker thread in the Service to carry out the task.
So, even if Service is not a threading construct, its a way of executing a task at hand. Hence I have included it in the comparison.

The table below tries to summarize various aspects of four task execution mechanisms : Service, Thread, IntentService, AsyncTask.

Most of the points in the table are self-explanatory. However, some points that need an explanation are numbered and explained  below the table. Also, this table is just to summarize about the concepts discussed in the previous posts. So, if anything is still unclear, I recommend to go through each individual posts in this series.

	Service	Thread	IntentService	AsyncTask
When to use ?	Task with no UI, but shouldn't be too long. Use threads within service for long tasks.	- Long task in general. - For tasks in parallel use Multiple threads (traditional mechanisms)	- Long task usually with no communication to main thread. (Update)- If communication is required, can use main thread handler or broadcast intents[3] - When callbacks are needed (Intent triggered tasks).	- Relatively long task (UI thread blocking) with a need to communicate with main thread.[3] - For tasks in parallel use multiple instances OR Executor [1]
Trigger	Call to method onStartService()	Thread start() method	Intent	Call to method execute()
Triggered From (thread)	Any thread	Any Thread	Main Thread (Intent is received on main thread and then worker thread is spawed)	Main Thread
Runs On (thread)	Main Thread	Its own thread	Separate worker thread	Worker thread. However, Main thread methods may be invoked in between to publish progress.
Limitations / Drawbacks	May block main thread	- Manual thread management - Code may become difficult to read	- Cannot run tasks in parallel. - Multiple intents are queued on the same worker thread.	- one instance can only be executed once (hence cannot run in a loop) [2] - Must be created and executed from the Main thread

[1] API Level 11 (Android 3.0) introduces the executeOnExecutor() method, that runs multiple tasks on a thread pool managed by AsyncTask. Below API Level 11, we need to create multiple instances of AsyncTask and call execute() on them in order to start parallel execution of multiple tasks.

[2] Once you create an object of an AsyncTask and call execute, you cannot call execute on that object again. Hence, trying to run an AsyncTask inside a loop will require you to each time create a new object in the loop before calling the execute on it.

[3] Recently I was brought to notice that AsyncTask is not recommended for long running tasks. While this is technically possible, I agree with the commenter. The idea here is any task which would potentially block the UI thread - I referred to this as a long task. May be I should have been clear. Thank you for pointing it out.

To be very precise, you cannot do something like :
        TestAsyncTask myATask = new TestAsyncTask();
        for (int i = 0; i < count; i++) {
            myATask.execute("one", "two", "three", "four");
        }

But you can do :

        for (int i = 0; i < count; i++) {
            TestAsyncTask myATask = new TestAsyncTask();
            myATask.execute("one", "two", "three", "four");
        }

[3] Thanks to comment posted by Mark Murphy (@commonsguy) : "there's nothing stopping an IntentService from communicating back to activities. A broadcast Intent is good for that, particularly with setPackage() to keep it constrained to your app (available on Android 2.1, IIRC). An ordered broadcast can be particularly useful, as you can rig it up such that if none of your activities are on-screen, that some manifest-registered BroadcastReceiver picks up the broadcast and raises a Notification."

Conclusion:
With a pretty understanding of the AsyncTask and the IntentService classes provided by Android, it would be a good idea to leverage these for most of the tasks as against trying to manage threads manually or implement your class as a Service unless there is really a need to do so.

Tricky Things:
There are some tricky scenarios that need some special handling. After all, we are dealing with a mobile environment and things are pretty unpredictable. For instance, the user opens your activity in which you start an AsyncTask, but before completion of the task, the user decides to exit the application (say by pressing the back button). Or your activity may be terminated (read kicked off) due to say an incoming call, when you are running a long task in the background. In such cases, where your application is not shutdown, but any foreground tasks have been closed or changed, all the background tasks need to know of this and try to exit gracefully.

Android thread constructs (Part 3) : AsyncTask

After examining thread communication, UI thread and then IntentService, I would like to talk about another threading construct called AsyncTask.

Similar to IntentService, AsyncTask allows us to run relatively long running tasks in the background. However, unlike IntentService the implementation is not straight forward. One of the reason people might think is that it involves generics ! There is no need to be afraid about those really. We just need to know 2 important things. One is the type of data that will be moving around and secondly these types cannot be primitive types like int, float, boolean etc... Before going further into the implementation, let me try to explain at a conceptual level.

NOTE: Recently I was brought to notice that AsyncTask is not recommended for long running tasks. While this is technically possible, I agree with the commenter. The idea here is any task which would potentially block the UI thread - I referred to this as a long task. May be I should have been clear. Thank you for pointing it out.

Concept:

You have a long task to do. You extend the AsycTask class and somewhere in there, specify your task. Then, from the main thread, create an instance of your extended class and call the execute() method. This should somehow result in a background thread executing your task. Pretty simple !

Now, there are 3 kinds of data that you will be dealing with:

1) Params : The parameters you pass on to the background task

2) Progress : The data units which the background task will be passing to you (UI thread) reporting its progress.

3) Result : The data that will be returned by the background task (to the UI thread) on completion.

Clearly there seems to be a communication going on between the UI thread and the worker thread. Hence, I like to visualize the AsyncTask as follows:

All the methods mentioned in the diagram will be a part of the extended AsyncTask class but however will run on different threads as indicated.

1) You have an instance of the AsyncTask and will call the execute() method. This method runs on the UI thread and serves as a trigger to the platform to spawn a worker thread.

2) Before handling the control to the worker thread, the platform will execute the onPreExecute() method on the main thread. We can perform any necessary task setup.

3) After this method finishes, the platform executes the doInBackground() method on the worker thread.

4,5) Now, whenever the worker thread calls the publishProgress() method, the platform calls the onProgressUpdate() method on the main thread with the parameters passed to the publishProgress() method.

6,7) Finally when the long running task is over i.e. the doInBackground() method returns, the return value is passed to the onPostExecute() method.

And, for all this to happen our AsyncTask class needs to know the datatypes for the 3 kinds of data discussed above.

It is important to note that just like IntentService, AsycTask also spawns a SINGLE worker thread and hence only one task can be run in background. Furthermore, once an instance of our AsyncTask is created, you can call the execute() method on it only ONCE. An exception will be thrown if you try to call execute() on the same instance of AsyncTask more than once. Hence, with AsyncTask if you want to run multiple tasks in background, create multiple instances and call execute on them.

Note: API level 11 (Honeycomb) adds the executeOnExecutor() method which enables to run multiple tasks on a pool of threads managed by AsyncTask class. I have not studied and tried this. I will update the post (or write a new one) once I try this out.

Implementation details:

Extend the AsyncTask class and pass to it the datatypes for Params, Progress and Result

class TestAsyncTask extends AsyncTask<String, Integer, Integer> {
}

So, here, we are telling that our worker thread will accept String parameters as input, the worker thread may publish the progress to the main thread as an Integer value and finally the return value of the doInBackground method will be an Integer. Note that the Integer class is used instead of primitive data type int.

Now, It may happen that, you have a worker thread that doesn't need any input, doesn't wish to convey any progress or any result. In that case, the AsyncTask definition will look like:

class TestAsyncTask extends AsyncTask<Void, Void, Void>{
}

Okay. Sticking with the first example, lets add in the doInBackground, onProgressUpdate and onPostExecute methods.

class TestAsyncTask extends AsyncTask<String, Integer, Integer> {

    protected Integer doInBackground(String... strings) {

        // Long running task - say processing of each passed string

        for (int i = 0; i < strings.length; i++){

               // Do processing of strings[i]

              publishProgress(i); // publish that ith string is processed

        }

        return 0;

    }

    protected void onProgressUpdate(Integer... item){

        Log.d("TestP", item[0] + " item has been processed");

    }

    protected void onPostExecute(Integer result){

        Log.d("TestP", "AsyncTask returned : " + result);

    }

}

From the main thread (say from your Activity or service), create an instance of the AsyncTask.

        TestAsyncTask myATask = new TestAsyncTask();
        myATask.execute("one", "two", "three", "four");

As mentioned before, if you want to run multiple AsyncTasks in parallel, just create another instance and call execute on it.

        TestAsyncTask myATask2 = new TestAsyncTask();

        myATask2.execute("five", "six", "seven", "eight");

There are 4 threading rules we need to follow for AsyncTask to work properly. These are mentioned in the AsyncTask documentation,  but I'll mention those again so that everything is available at one place.

1. The task instance needs to be created on the main thread.

2. The execute() method needs to be called on the main thread.

3. Do not  explicitly call any of the preExecute(), postExecute(), doInBackground() and onProgressUpdate() methods.

4. The task can be executed only once on one instance.

Thats all you need to know to execute AsyncTask.
I'm pretty much excited about my next post. I'm planning to do a comparison of various background mechanisms that we have seen till now as well as try to come up with some guidelines. I'm still working on it, hope to post them soon. Stay tuned !

Android Thread Constructs(Part 2): Intent Service

Continuing from Part 1 about the UI thread, today, I would like to discuss the IntentService class.

Concept:


In simple terms, IntentService provides a mechanism to run a long task in the background. We need not worry of any thread creation and management. It is all done behind the scene. We just extend our class from the IntentService class, and implement our long task in the overridden onHandleIntent() method.

On the specified trigger (which is an Intent), the platform will spawn a worker thread for our extended class and then call the onHandleIntent method on this thread. I like to visualize this as follows:

So, all the long running code can be executed in the onHandleIntent() method. We can be sure that this will not block the main (UI) thread.

It is worth noting here that if there are multiple intents that are received, they all will NOT execute in parallel. The IntentService class spawn a SINGLE worker thread. Hence all the consecutive intents will go into the message queue for the worker thread and will execute sequentially.

So, the obvious question is : What if I want to execute multiple tasks in parallel ?

I will defer to answer this till the end of this article series. We will first go through AsyncTask in the next article and then the concluding post I will try to consider various use cases, limitations and comparisons.

Implementation details:
Now for some implementation details. Extend your class (say MyIntentService) as follows:

class MyIntentService extends IntentService {
    public MyIntentService() {
        super ("com.foo.MyIntentService");
    }
    protected void onHandleIntent(Intent intent) {
        // call to any long running task !
    }
}

Thats it. You are all set ! Now, you can trigger this by calling the startService(Intent) method. We need not worry about stopping the service. Once the long running task is done and if there are no intents lined up in the message queue, the platform will automatically stop the IntentService.

I have stated again and again, IntentService is very useful when you need to perform a long task in the background. The interesting part here is that the trigger for starting the task is an Intent ! Now that opens a lot of opportunities. Don't get it ?  Here is hint : Your application need not be running at the time you want to start a background task ! All you need to do is have a PendingIntent for your IntentService. Now you can register this PendingIntent with many of the available callbacks in the Android APIs. So, now, even if your application is not running, and the PendingIntent is fired ! Wolaa - your background task is started  :)

Coming up next is AsyncTask.

Android Thread Constructs(Part 1): The UI Thread

Earlier, I talked on passing data between threads. I would like to continue the same "thread" of discussion and in the next few posts of this multipart article, explore and try to explain about various ways of performing tasks.

A pictorial and diagrammatic representation makes me understand concepts well. Every time I learn something new, I try to make a diagram in my mind. This helps me understand better. So, I'll be providing my own diagrams along the way.

Note : The diagrams I use are to help myself understand the concept and may not be an exact representation of the concept. You may still need to read the related documentation.

Enough said, lets get into the Thread !

The UI Thread:

So, in an Android application, each application is sandboxed and runs in its own process. Unlike traditional languages, the Android application may not have a single entry point. So, the application can be entered through from any of the application components (Activities, Services, Broadcast receivers) described in the Application Fundamentals on the developer blog.

All these application components run on a single Main thread called as the UI thread. I like to imagine this concept as in figure below:

So, as you see all the components will run on the MainThread or the UI thread. All the lifecycle methods (of Activity, Service, Receivers starting with on*) will run on the UI thread.

One of the main task of the UI thread is to manipulate the user interface. Hence, if you have long tasks to perform, you should not be doing those in the main thread. (I'm sure, you must have read this several times). The reason is that if you perform any long or blocking task - the UI thread will be blocked - hence blocking or delaying the UI updates and will lead the user to think that the system is running slow. The Android platform doesn't want this blame on itself, so when it detects that some long task is running on the UI thread for some application, it will declare that the application is "foobar-ed" and throw out the nasty ANR (Application Not Responding) dialog - pissing off the user and provoking him/her to uninstall, and underrate your application ! Deadly and Evil  :O

So, in order to do longer tasks, from any of the application components, you should create threads. However, its worth noting that you should not manipulate the UI from any worker thread. i.e for example if you run a long task on a thread on a button click as follows:

public void onClick(View v) {
  new Thread(new Runnable() {
    public void run() {
      Bitmap b = loadImageFromNetwork();
      mImageView.setImageBitmap(b);
    }
  }).start();
}

Code source : http://developer.android.com/resources/articles/painless-threading.html

Here, the worker thread is trying to update the UI. As the documentation states, this may lead to hard to find and funny (not for you) problems. So, updating the UI is the job of the main thread. The following figure helps me remember that :)

Now, it is evident and advisable that we do long and/or blocking tasks on worker threads and if any results are produced, convey them to the main thread. In my previous article, I talked about passing data around threads. This involves implementing Handlers, making appropriate Looper calls, obtaining the Message Object and passing it around, getting data from it blah blah blah... (Go read the article if you havent')

Android provides certain constructs that offload from us the tasks for creation and administration of threads and let us focus on what we need to do. IntentService, AsyncTask, HandlerThread are among those.

I'm going to discuss IntentService and AsyncTask (with my diagrammatic representations) in the next articles and then try to come up with rough guidelines regarding when to use each of the constructs.

Stay tuned.

Getting gingerbread on Nexus One

If you are an impatient person like me (when it comes to gadgets !), with a nexus one but no gingerbread yet, you might definitely be aware that there are official versions of Gingerbread 2.3.3 floating out there.

I faced some problems getting gingerbread to my N1.

<noobie_skip>
I had CM7 on my nexus one which is gingerbread but I wanted to get to a stock version (why ? my choice :D and for some reason gapps wasn't able to install the GMail app on CM7 !) Noobies, you are supposed to ignore this block
</noobie_skip>

So, I was able to get back to stock version 2.2 using instructions here. From then on my impatience triggered ignorance and things started to go foo bar !

I started getting a very strange error. Something like :

assert failed: file_getprop(“/system/build.prop”, “ro.build.fingerprint”) == “google/passion/passion/mahimahi:2.2.2/FRG83G/91102:user/release-keys” ll file_getprop(“/system/build.prop”, “ro.build.fingerprint”) == “google/passion/passion/mahimahi:2.3.3/GRI40/102588:user/release-keys”
E:Error in /sdcard/update.zip 
(status 7)
Installation aborted

Eventually, I figured out that I was trying to directly jump from FRG33 to GRI40 (This is Gingerbread 2.3.3) ! All the zip files floating out there are incremental - they only take you one level up !

So, you may want to check the file name. For e.g. :

2854b06b22b9.signed-passion-FRG83G-from-FRG83D.2854b06b.zip

This file will take you from FRG83D to FRG83G. You will need to go on flashing each one. So find all the zip files that will take you from your version up to GRI40

For me it was from FRG83 -> FRG83D, then FRG83D -> FRG83G and finally FRG83G -> GRI40

Wooohooooo. Gingerbread it is !

Hope this helps someone !

Note: Unfortunately I cannot provide you with all the zip file paths. Since the links may be broken or get broken over time and I do not wish to keep on updating those. Use our friend Google to get to the files ! :)

Android : Passing data between main thread and worker threads.

There may be situations where you want to spawn a thread from your Activity or Service to handle long running (and may be blocking) tasks. In such cases, its sometimes necessary to pass data back and forth between the main thread and the worker thread(s). E.g. if the worker thread finishes a task and returns the result to the main activity to display the results OR you want to keep a worker thread around and ask it to switch between tasks depending on some message you pass to it.

In the past, I faced some problems understanding these concepts associated with different classes in android.os like the Handler, Looper, HandlerThread etc...

I'll try to explain these concepts in a simple language. Probably most of these explanations are from the developer documentation, but I thought consolidating these at one place may help to get a good picture.

Ok. So, when an application runs, it runs in a Main thread called as the UI thread. Any other thread can be created using the standard java.lang.Thread class. As I said in a typical situation you will spawn a thread, may be pass some data to it OR the thread may pass back some data to the Main thread from time to time as well as when its done executing.

Let us consider the task where we need to send data to a worker thread. So first, we create a worker thread.

STEP 1: Create a worker thread

class MyThread extends Thread {
    @Override
    public void run(){
    }
}

In our main thread...

MyThread mThread = new MyThread();
mThread.start();

When you have to pass any messages to a thread or get messages from a thread, the receiving thread needs a MessageQueue. By default, a thread created by using the java.lang.Thread class will not have a MessageQueue associated with it. Its just a plain old thread as in the Fig. 1 (Yes, I know. What an innovative diagram !! :D ).




Now, we need to attach a MessageQueue to our thread. The Looper class provides the method prepare() to create a message queue for a thread. We need to call this method from the receiving thread's run method.

STEP 2: Call the Looper methods

class MyThread extends Thread {

    @Override

    public void run(){

           Looper.prepare();

           Looper.loop();

    }

}

As you see, there is one more Looper method called in the code. This loop() method will start running the message loop for the current thread. In simple terms, it will start looking at the MessageQueue and processing the messages. This is how I interpret the Looper as in Fig. 2.

But, who sends the messages to the MessageQueue and how are these processed ? There is a class called the Handler. The Hander allows us to send and process Messages (as well as Runnable Objects) associated with the thread's MessageQueue. So, we need to create a Handler. It is important to note that the Handler is associated with the thread that creates it ! The Handler provides methods to handle (receive) Messages as well as send and schedule messages. For details, please refer to documentation.

STEP 3: Create a Handler to receive the Messages

class MyThread extends Thread {

    public Handler mHandler;

    @Override

    public void run(){

           Looper.prepare();

           mHandler = new Handler() {

                   public void handleMessage(Message msg) {

                       // Act on the message

                   }

           };

           Looper.loop();

    }

}

If you notice, this code is the same that is listed on the Looper documentation page here.  Few things to mention here are. The Handler is created in this thread, hence it is associated with the default Looper (read MessageQueue) in the current thread. There are constructors for the Handler that allow us to specify the Looper (again, read MessageQueue). This allows us to write a cleaner code by writing the Handler class separately and passing on a Looper (again, again, read MessageQueue) when the Handler is created. I'll get to this in a while. But as I have insisted, it is worth noting that whenever the developer documentation refers to a Looper, you can assume they are talking about a queue. I'm really not sure why they have surfaced the Looper class. It creates more confusion (at least for me). Also, when dealing with passing the messages, with this mechanism, we really need not care of the MessageQueue call. That is the reason I haven't linked it to the documentation. Anyways... things are what they are ! For me, I like to interpret this whole mechanism as depicted in Fig. 3.

Let me know if you like PAT or your way of viewing it !

So, now any other thread having the reference to mHandler will be able to call the send or post methods of the Handler class to send a Message (or a runnable object) to our thread. The code for sending message will look like:

Message msg = Message.obtain();

msg.obj =  // Some Arbitrary object

mHandler.sendMessage(msg);

Pretty simple yeah ! Btw, there are various methods to set/get data for the Message object which can be found in the developer documentation for the Message class.

Summary of Steps :

1. Create a Handler in the receiving thread [If it is the main thread, create one in the main thread]. By default the handler will be associated with the default queue (Looper).

2. So, if the receiving thread is created by using java.lang.Thread, then we need to call the Looper.prepare() and Looper.loop() in order to set up the message queue for the thread.

3.  In the sending thread, prepare a message object (or a Runnable object)

4. Get a reference to the Handler in the sending thread and call the send/post methods on it to send a message.

HandlerThread:

Since by default java.lang.Thread doesn't contain a message queue (Looper), Android provides a class called as the HandlerThread which already contains a message queue. The only difference in using the HandlerThread class over the method described above is that you need not call the Looper.* methods.

On creation of a HandlerThread, Android will create a thread containing the looper. So, in the main thread the code will look like:

HandlerThread myThread = new HandlerThread("Worker Thread");  

myThread.start(); 

We separately create a Handler as follows:

class MyHandler extends Handler { 

    public MyHandler(Looper myLooper) { 

        super(myLooper);
    }
    public void handleMessage(Message msg) { 

    }
} 

Now in the main thread, we get the looper for the HandlerThread and pass it when we create the Handler as follows:

Looper mLooper = myThread.getLooper(); 

MyHandler mHandler = new MyHandler(mLooper); 

Whenever we want to send a message from the main thread, we do it in a similar fashion.

Message msg = mHandler.obtainMessage(); 

msg.obj =  // Some Arbitrary object

mHandler.sendMessage(msg); 

I like to visualize this as shown below in Fig. 4 where we write the Handler separately and then pass a looper to it on its creation.

Nokia chooses WP7 over Android

Going through the news reader this morning, I learnt that Nokia, one of the greatest manufacturers of mobile devices has chosen WP7 over Android. Not that I hate WP7 (as of yet, since I haven't tried it), but I would have loved to have my favorite Android on Nokia devices.
Being from India, where Nokia phones are seen as prime devices (at least till recently), and having used few of Nokia phones before, I was eagerly waiting to hear Nokia adopt Android.
Now, it will be an interesting market to see. I'm not much concerned how this affects WP7 (sorry Microsoft, not a big fan), though for the time being it will definitely be a breather for them. I'm worried about the future of Nokia. But still I hope that somewhere in future, Nokia will shake hands with the green robot !

BTW, did I hear somewhere that Nokia CEO Stephen Elop is a former Microsoft employee ! Ahem ahem ...

Android development cheatsheet

Here is a list of commands I find useful when developing applications. Do add to comments any commands that you use and find useful. I'll update accordingly. Also, I would be interested if anyone has any android UI related cheat sheets :)

android

-    Create/delete/view Android Virtual Devices

-    Create/update projects

-    Update the SDK with new platforms, addons and docs.

android list target

android list avd

android --help

android create avd –n <avd_name> -t <target_ID> -c <size>[K|M]

android create project --target <target_ID> --name <prjname> --path <where>

                       --activity <activityname> --package <package_namespace>

android update project [--name|-n] <prjname> [--target|-t] <target_ID>

                       [--path|-p] <thepath_to_prj>

android create lib-project --target <target_ID> --name <prjname> --path <where> 

                           --package <package_namespace>

adb

adb [-d|-e] install <path_to_your_bin>.apk

adb push <local> <remote>    - copy file/dir to device

adb pull <remote> [<local>]  - copy file/dir from device

e.g : adb push foo.txt /sdcard/foo.txt

adb shell

adb devices

adb –s emulator-5554 shell

#sqlite3 /data/data/com.example.google.rss.rssexample/databases/rssitems.db

sqlite>.exit

adb logcat [<option> … [<filter-spec>] …

[V – Verbose, D – Debug, I – Info, W – Warning, E – Error, F – Fatal, S – Silent]

adb logcat <tag1>:<priority1> …..

e.g. : adb logcat ActivityMgr:I MyApp:D *:S

others 

mksdcard [-l label] <size>[K|M] <file>

emulator –avd <avd_name> –sdcard <file>

telnet localhost <emulator-port>


#From inside telnet:


- sms send <sender phone number> <text message>

- geo fix <longitude> <latitude> [<altitude>]