Well, I really didn’t think Google would do it (again) but they handed out free phones to everyone attending this three hour evening session. We all got a Nexus One, on AT&T frequencies by default, but you could ask for a T-Mobile one. It only matters for 3G data; 2G data and voice are the same on both.
So now I’ve received four free phones from Google over the last 14 months. I’m using one as a phone, two others for development and sharing with co-workers, and now I have to figure out whether I’m going to migrate to this fourth one, or pass it on to a co-worker, and use it just for development. I’m sure not complaining, though.
I took an Android development class at Google IO in May, but it only last an hour and really just gave us time to take an existing app and uncomment code bit by bit to see what it did. I’m hoping to get a bit deeper tonight.
We’re starting with design principles, not jumping right into programming. Mobile apps are a bit different from desktop ones, and Google says that they want people to create great ones. Though I don’t know how much attention folks are paying to the speaker; they’re unboxing and setting up their phones.
Some good UI points: don’t just port your UI from other platforms; your app should behave like other apps on the same platform. Don’t do positioning and sizing that won’t adjust to different devices. Don’t overuse modal dialogs. Of course, DO support different resolutions, handle orientation changes, support non-touch navigation, and make large, obvious tap targets.
[Yes, I swear I’m paying attention. But I’m also updating my new phone to FroYo!]
Design philosophy: choose clear over “simple”. Focus on content, not chrome. Enhance the app through use of the cloud (Yes!).
Show feedback: have at least four states for all interactive UI elements: default, disabled, focused, pressed.
Avoid confirmation dialogs (are you sure?). Instead, support undo.
(By the way, we’re back on the OSCON_BG wi-fi tonight, and it’s performing very badly again. Of course, that might be due to everyone downloading FroYo to their phones via wi-fi, since they didn’t come with SIMs.)
Some new UI design patterns: Dashboard, Action Bar, and Quick Actions. They’ll show them in the context of the new Android twitter app.
This is all good content, but I’m ready for the “hands-on” part. Let’s build something.
Tim Bray just announced that Android is now shipping 160,000 phones a day, which comes to more than 50 million a year. So developers should be interested in creating apps for it, and tools to create apps for it. (Nobody’s mentioned AppInventor yet, though.)
Now we’re going to talk about how to have your app interact with RESTful services. I missed that session at Google IO (too much competing content there) and I care deeply about this, so I’m really glad to see this. First issue: why a native REST Client versus a Mobile Web App? Basically because web apps can’t do all the things a native app can do. Yet. Google’s working on it making web apps more and more capable, but there are still things you can’t do on your phone with a web app that you could do with a native app.
First up for REST: how not to do it. Start up a new thread to talk to the remote server, save results in memory, and then have your main thread take that data out of memory and use it. Why is this bad? Well, the OS can shut down the process any time the user navigates away from it (since the device has limited memory). So if you haven’t finished the fetch, or processed the data fetched to memory, it’s gone and you’ll have to do it over. Instead, you need to start a service for this, which the OS won’t kill as easily, and if it does kill it, the OS will save and later restore the state.
Now we’ll see step by step how to do that. There’s a diagram showing with 11 steps involved to have your activity create and use a service to perform a REST method. The specific example is getting a list of photos in an album, or saving a new photo to an album, accessed via a RESTful web service. Some other tips:
- Can use the new built-in JSON parser in FroYo
- Always enable gzip encoding. If the server supports it, it will not only download faster, but use the radio (and hence the battery) less.
- Run the method in a worker thread
- Use the Apache HTTP client library
The whole thing starts when the Service receives the Intent sent by the Service Helper and starts the correct REST method. Then the Processor that actually makes the request is done it triggers a callback, and then the Service Helper invoices the “Service Helper binder callback”. (I think I know what they mean by that.) It can queue multiple downloads.
That was how the Service responds to the Service Helper. Where does that come in? It’s what your Activity actually invokes. It’s a singleton that exposes a simple (asynchronous) API to be used by the user interface.
(Again, good information. But where’s the hands-on? I’ve already created the Hello, Android example and pushed it to the new phone, but I want to create something tonight!)
I’ve been to a couple of short session on programming Android, and created the baby Hello, World app, but I’m barely keeping up at this point. I strongly suspect that this example is way too complicated for the majority of people here who just don’t have any Android context to put it in yet.
Okay, we’ve finally finished the description of how that would work. Now we’re going to hear how to use the ContentProvider API. Which is apparently much simpler. Okay, now we have the background to understand all the stuff the Content Provider is doing for us. And finally, the third option is to use something called a Sync adapter. Those are new in Android 2.0+, and they are important. Use them! They’re battery efficient, but not instantaneous due to queueing.
Well, we’re moving on the Android NDK development kit (for native C/C++ code instead of using Java). I no longer believe that there will be any hands-on this evening. Good information, though. However, I have no intention of programming Android in C/C++. Still, there are nice advances. You can now debug NDK application on retail devices, starting with Android 2.2. But we’re now seeing the original Tetris code (from Russia, from a long time ago) running natively on an Android phone using it. Cool, but I’m still not going to do it myself.
And that’s it. No actual hands-on, except what I’ve done myself during gaps in the talks. But still a great session (even without the free phone, but FroYo is cool.)
Charles Engelke's Blog 