I wasn’t able to quickly find any documentation on the Java SimpleDateFormat strings by locale…so I did what any Passionate Programmer would do, and I wrote a method to do it for me.

Then, I needed to get this file off of my emulator. To do that, I opened the DDMS perspective, selected my emulator in the Devices tab (emulator-5554), and navigated to data\data\(applicaton name)\files\(file name).

By default, Android apps run solely in a single thread – the UI Thread.  For most applications, this is perfectly fine.  There are, however, some good reasons that your application needs to be multithreaded.  For example -

• lots of data access – reading/writing to a database is slow
• download information from the internet – mobile networks can be spotty, or slow
• sync with other components – for example, performing Bluetooth pairing or communicating with a service

If you want your thread to be able to interact with the UI and still perform operations in the background, then you’ll need to use some Android specific classes.  The simplest form in Android is the Handler.  A Handler allows you to send/queue messages, execute Runnable objects, and even perform some fine grained scheduling.

One of the best uses for a Handler is for displaying progress.  When communicating progress via a dialog, or progress bar, or whatever, it is good to use a Handler because the user can still interact with your UI.  For example, if the user decides they don’t want to wait, they could press the back button.  Or, perhaps the operation you’re doing doesn’t require the user to wait, they can continue to use your app while information gets updated asynchronously.

Thinking of the G+, FB, or TweetDeck apps that try to backfill your stream…if those apps blocked your UI, and made you wait, you’d most likely never use those apps again.  Or worse, you might go as far as leaving negative feedback in the app store!

So, MaTT, how do we do this?

The example below uses a Handler to set the progress on the UI.  So while the Thread is doing some lengthy operation (mProgressStatus = doWork();), the Handler is able to update the UI by calling the Post method, and setting the progress.

The reason you NEED a Handler here, is because you can’t access the UI from the Thread object.  The Android UI toolkit is not threadsafe by default.  If you try to access the View to update it, there is a good chance you’ll get some amazing Null Reference exceptions.

Each Activity only needs one handler, so you can use that Handler for different tasks or for updating multiple UI components.

So, MaTT, when do we use this?

This approach is great for simple, yet long, operations.  You are still able to show progress to your user and you don’t block the UI while it happens.  Using Handlers won’t give you 5 stars in the market, but it can help keep you from getting 1 star.  Handlers are ideal for one-off situations where you need to do something, but don’t want to interrupt the user.  The other beautiful part about using a Handler is, you don’t have to worry about creating some complex messaging architecture that takes a week to develop and test.

If you find yourself putting Handlers all over the place, consider using a more robust solution like AsyncTasks which I will cover in more detail in my next post.

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion

Ultimately, users want to have multiple applications running, syncing data, and connecting to the internet.

One solution to meet this demand is to block the UI and potentially display progress.  This can be a problem because users who perceive an application to be slow, sluggish, or non-responsive will give your app poor reviews in the market.  A more ideal solution is to perform long running, slow, or blocking tasks in the background.  The same work is being done, but the UI is snappy, or responsive.  An added benefit is that you won’t end up having one of these gems while trying to get the latest news updates about the NFL Lockout… <sigh/>

Android has many options for performing background tasks.  Specifically, Android gives you the opportunity to define what process your component runs in, control threads, and communicate remotely with components and processes.  Great!  Let’s use this to make awesome applications.  What’s the name of this magical background task thingy?  Well, get ready, because there’s a list…

• Process
• Thread
• Synchronized
• Handler
• Messenger
• AsyncTask
• Service
• BoundServices
• IntentServices

In theory, this is great!  However, there are so many options that it can be overwhelming.  And you can’t just start moving everything to a new thread, because multithreaded applications introduce new challenges, like…

• What about concurrency?  Is that a problem? (That’s a rhetorical question.  Of course concurrency is an issue!)
• Deadlock, livelock, and  starvation (“Oh my!”)
• What do my users expect?  If I do things in the background, does that break the communication loop?
• I’ve heard lifecycle is important, what does this mean?

In a series of posts, I’ll cover the options, explain possible approaches, and make recommendations on when to use which options. I will even put up some sample code to help illustrate my points.  Along the way, I will answer the above questions and more.  After all, you want to be sure that you’re using the right tool for the job, right?

Android Thread Series:

1. Overview
2. Handlers
3. AsyncTasks
4. Services and Messengers
5. Conclusion

This was all true…until recently. My 3 years of working on embedded projects here at SEP has ended, and now I have started helping with some of the early stages of a mobile app.

My domain is definitely NOT mobile, but I would say that it isn’t that drastic of a change. And if my knowledge of software was in a Venn diagram format, I don’t think object oriented programming would be in the center.

So, in order to be as helpful as possible on this new project…I decided to educate myself on the mobile platforms that we will be using – Android, Symbian, and of course…iPhone.

There’s a lot of information out there.  Most of the time, I find myself going to multiple sites for that information, though.  One thing that has really impressed me so far is the work that all three of these platforms have done, in the way of documentation.

The Android library seems to be the most fluid, and easy to navigate.  All of the native packages and classes are easy to get to, and easy to read.  They even include examples of how each can be used.  Way cool, IMO!

The Symbian library seems to have a TON of information…literally.  It’s so much information, I find it difficult to find what it is I’m looking for.  Some of that might come with my lack of knowledge about the platform, though.  Under 1 site, we have documentation for the OS, APIs, hardware (and different versions), etc.  It’s quite the mother-load of information.

The iPhone library seems to be broken up into a completely different format.  Different being the key word.  Android chose to break it up by package and/or class.  iPhone seems to have a different method.  I’m sure I’ll like it better once I get neck deep into developing an app for the iPhone…but for now, I find it difficult.

To me, it is amazing how much time each company has invested into these libraries.  That’s not something that they are going to directly see any benefits from.  Immediately, you can tell that they are trying to make the developers happy!

“Daddy like”