Droids and droids!

For the second time in as many weeks, I was driving north on 85 to the Googleplex, lured by the promise of free food and insight into the Android platform. This event was held by the Silicon Valley Google Technology User Group; I'm not familiar with them, but they seem to be a new group with loose ties to Google proper. Unlike the earlier Campfire session, this was a slightly larger affair, a bit more structured, and felt less under-the-radar.

200 people had registered for the event, and a good chunk of them showed up. We were in the Tunis room in building 43 - a different location from Campfire, but the same place I went about half a year ago for the forum on mobile advertising. Food wasn't as interesting as at the Campfire, and there was no open bar this time around, but it was more of a meal - various kinds of pizzas, lasagnas, and a green salad. The meet and greet lasted from 6 until 7, and we'd been warned by email to arrive early to avoid long security lines, so I had close to an hour to kill before the talk officially started. I got into a nice chat with Julian and Richard, two other attendees who had recently started work on Android. They haven't done a lot of mobile development in the past, so I got to put on my explainer hat for a while... I still hesitate to call myself an "expert," even after three years in the field, but times like this make me amazed at how much more I know now than when I first started this gig. I feel like the more I learn, the more I take that information for granted, and erroneously assume that everyone knows it. Shades of the "Curse of Knowledge" from Made to Stick, I suppose.

There was a round of early introductions that clarified exactly who these people were and how the night would be structured. I realized that the people running the event were not Google employees, but the main speaker was. I'm embarrassed to admit that I am not familiar with him; it sounds like he's a pretty big player in the Java world. Anyways: Dick Wall runs with the Java Posse and is currently working for Google... I THINK he's one of their Developer Advocates, but I could be confused about that, as I will explain below. Bonus: he's English!

The first part of the night was focused on a slideshow presentation Dick Wall gave. After the first five minutes or so I was feeling a bit dejected - I had come to the event hoping to learn more about Android, and so far it seemed to just be re-hashing the official documentation on the Web. After a while, though, I started to perk up as I heard information I hadn't encountered before (or else had forgotten). He ran an interactive talk that was regularly interrupted by questions, and a few rambling declarations, which was both good and bad. It led to some good points being made, but at the same time it would occasionally derail the talk and led to a lot of comments like, "We'll be talking about that soon."

The first big "Aha!" moment I had was with the lifecycle of an Activity, which I thought I totally understood. One thing I just realized a few weeks ago was that multiple Activities can run in the same process. What I didn't know until last night, though, was that an activity's onFreeze method will only be called if it is going away due to another process. For example, if I navigate from a main menu Activity in my app to a Help Activity that is also in my app, I will receive an onPause in my main menu but not an onFreeze. However, if my Help screen is interrupted by an incoming call, then both the onFreeze and the onPause will be called.

The consequence of this is that you only need to bundle up your temporary data if you're moving to another process. This is because Android can silently kill your process when another Activity runs out of resources, and will resume your process when it's ready to be shown again. It's a cool system, and I now understand it better than before. That alone was worth the price of admission. (The event, by the way, was free. Worth the price of gas, I guess.)

One thing I meant to ask but never did: in the above example, would only the Help screen's onFreeze get called? If so, is there any way to capture the current state of the main menu Activity? Unless I misunderstand how this works, only the top-active Activity in your application will be notified that it is in danger of being destroyed.

UPDATE: The above 3 paragraphs are incorrect. See the bottom of this post for details.

I won't rehash the whole talk here - about 80% of it comes from the official documentation, which is much better than I'd be able to produce. I'll just call out a few things that I thought were interesting.

He seemed pretty dismissive of the need for threads. We didn't get too deep into this, but he did say that you generally don't need to make them. This seems in keeping with my experience - stuff like Handlers let you omit many uses for them, and for the long run you'll often want a Service - but it was the most explicit word I've heard yet about threading. I assume you'd still want to spawn threads for network connections and medium-length processing. This is probably another area where we'll be seeing Best Practices come out in the near future.

He confirmed my suspicions about Bundles by saying that they're basically just Maps, with a few changes, and pointed out that you can store Bundles in Bundles. This is something people have commented on before: Android terminology can sometimes be confusing. (He also pointed out that what Android calls a "View" is what most people would call a "Control.")

Some of the early Android hardware will have 3D acceleration hardware. I heard some audible laughs, but was not surprised... it isn't something you see in America, but Japan has had phones with these capabilities for years. If you don't believe me, look for videos of FF Before Crisis (two years old!) and the like. I don't think we'll be seeing killer 3D apps at launch, because they tend to require resources beyond what an individual developer would be able to contribute.

The first big bombshell of the night: XMPP is going away in the next version of the SDK! I was stunned and relieved. Stunned because I know that a lot of people are working on apps for the challenge that rely on XMPP for their data interchange. Relieved because I haven't spent much time at all with it, and so I don't feel I've wasted my efforts there. Still, I can see another backlash coming.

At the end of the talk, Dick demoed a cool little app he wrote called WikiLinks. (I think that was the name... WikiNotes, maybe?) He said it will be made available on Google Code in a few weeks. Anyways, it's a tight-looking simple app that lets you edit pages, scans them to find Wiki links, and lets you follow those links to other pages. The app demonstrated how efficient Android is when working with Intents and Activities. Each time you clicked on a Link, it creates a new Intent and fires it. Every Intent maps to the same Activity - the WikiLink. However, even if you are clicking 40 links in succession and creating all these Intents, during the whole time you're using a single process - Android is re-using its resources while maintaining its open, pluggable interface. It was a cool demonstration that should help alleviate some skepticism over performance.

Speaking of which, the most encouraging thing I heard all night was that performance on the emulator is a good predictor of performance on the device. This is very different from my experience with BREW and J2ME, where applications that run well on the emulator can crawl once you get on the phone. Dick said that, in general, applications will run at least as fast on the phone, and maybe a bit faster... in particular, text input is less laggy on the phone. Anyways, I was delighted to hear this; it's something I've been worrying about.

There was a long run of questions before the break. A few interesting things came out here. First, support for touch was added recently to Android. The current SDK has some controls you can click on. Upcoming SDKs will enhance this support. However, true multitouch like the iPhone is a trickier problem. Dick didn't want to go into specifics, but it sounds like there might be some patent issues or other legal considerations in play.

One of the GTUG folks asked about J2ME support. I often think that questions like this miss the point, but there's a lot of people who understandably are reluctant to surrender years of development work. In the past, some OHA affiliates have expressed an interest in adding this support. The bottom line, though, is that Android will be open-sourced, so if anyone wants J2ME, they can make it.

They cut off the talk and took a break. During this time they ran a nice raffle, using a cool application based on Java FX that looks a lot like Wheel of Lunch. It spun and spun, people came up to claim their swag (Google thermoses, T-shirts, etc.). And - wait for it - I was a winner! My name was the last called, and I took my prize, a black T-shirt. It was labeled "Google Developer Days", which was clearly a lie. It was also labeled "Large", which I also think is a lie, but will need to wear the shirt before making sure.

Afterwards we had breakout sessions. The vast majority of people moved to the front of the room for the Android session with Dick, but other GTUG people ran sessions on other technologies... there was one for Maps, another for Gears, one for Open Social, and possibly more. They introduced Ash, an Android Champion, who will be running the sessions on Android in the future. A Champion is someone who promotes a technology and facilitates learning, and I think is an awesome name. I'll now have to decide whether to come to their monthly meetings for the Android sessions... I kind of doubt I will, but it is tempting.

The breakout was pure Q&A. I tapped out some notes on my iPhone, so I'll dump those in here. Here we go!

The first question was about the backlash against Android and the bad press it's been getting. Dick listened sympathetically. He explained that, more than anything, Google was just surprised by the amount of excitement Android generated, and wasn't prepared to deal with it. In the first 24 hours after the SDK was released, it was downloaded over 10,000 times. A chunk of these started doing serious work and posting on the discussion groups with questions. He said that they had 5 people to handle all of this, and just couldn't keep up. I don't think he meant they had 5 people on the dev team - that seems way too small - so I'm guessing he's referring to the Developer Advocates or other people meant to directly communicate with the community.

The overall response could probably be summed up as, "I feel your pain, but I don't want to apologize." They've been very busy, and they're focused on getting the next version of the SDK out, improving the state of Android, and while they want to help people, they just don't have the resources and it isn't their only priority. This matches my experience on the group - I asked a question about support for hybrid maps a few weeks ago and still haven't gotten a reply. I don't blame the Googlers - hackbod, Dan M, romain guy, and anyone else who chimes in. They always give great answers, and the group is quickly becoming a useful resource to learn about how to use something, or what doesn't work. But there's just a lot more activity on the group than they can keep up with. Dick says that they've been trying to hire more people, but it hasn't been working.

The worst news I heard all night: porting to the new SDK "will be painful." They aren't just fixing bugs and adding features; they're also changing APIs and removing things. I think XMPP is probably going to have a lot of fallout. Dick also specifically mentioned that the Content Provider system is going to be changing a lot. He said that WikiLinks took a few hours to port from Version 3 of the SDK to Version 5, so I'm shuddering at the thought of how long it will take to port a more complex app. That said, he hopes to write a porting guide that will explain how to make this shift.

Once again, his tone was sympathetic without being apologetic. They want to focus on making the SDK as good as they can, even if that means breaking things. After Version 1.0 comes out and the first phones ship, they'll be tamping things down, but up until then, anything should be fair game.

On a related note, he explained a bit more about the status of the challenge, and specifically the controversial decision to extent it. Background: they initially set a deadline of early March, which was heralded as a "firm date." They now have pushed it back to the middle of April to give people more time to submit. A lot of developers feel betrayed: they have devoted a lot of time and energy trying to meet the deadline, and now that Google has yanked it back, their chances of winning will diminish due to the increased number of entries, plus they will need to re-write their applications to make them competitive with whatever the latest version of the SDK ends up being. As Dick explained it, there were a lot of problems with the current version of the SDK, and some developers were frustrated because they couldn't make the apps they wanted to on it. The plan had been to release version 4 in enough time for everyone to switch to it before the deadline. However, they (Google) missed their deadline for version 4. Version 5 will be released in the very near future, and just leaving a few weeks before the deadline wouldn't be enough time for people to take advantage of it. So, they moved it back.

For the record, I'm disappointed in this decision, but it isn't my choice to make... it's Google's money, their contest, and they can do whatever they want. It has certainly not endeared them to the early adopters, however.

Talking generally about the challenge, Dick said that it hasn't exactly gone as planned. On the one hand, it sparked a great deal of interest in Android and got people looking at it, which has been Google's goal all along. On the other hand, the competitive nature of the contest has made people more inclined towards secrecy, less likely to share what they have learned or talked about ideas. If they had it to do over again, they might not have done the challenge at all.

There has been a lot of concern on the groups over the Terms and Conditions for the challenge, which (at least as of this writing) includes some very distressing statements such as "You agree that you will not be entitled to any rights in, or compensation in connection with, any such similar or identical applications and/or ideas." Basically, any member of the OHA is free to take your idea (whether or not you win the contest) and make that exact same application without paying you a dime. Again, there was some concern that people won't submit their apps, instead waiting until phones ship so they can sell them without worrying about "stealing." Dick was actually surprised to hear about this. The one thing he said was, "Google doesn't have a history of screwing people over." This is in keeping with the semi-official responses on the blog, which boil down to "We are running this contest to generate goodwill towards Android, and it would be stupid of us to ruin all that goodwill." He said that, if Google really wanted an app that you wrote, they'd be more likely to hire you than steal your idea. (Good answer!)

Someone asked about development in C++. My impression here has been that it's currently not supported and might possibly be in the future. It turns out that, while that's the official story, the reality is that some people have been getting C++ code to work on Android. The Google team is aware of these efforts, and, unofficially, think it's great. They can't support it, since their hands are full with the official Java SDK, but they aren't going to stop it. Also, the SDK will be getting support for JNI, at which point it will become possible to call C++ code from the Dalvik VM.

Someone asked about distribution. This still hasn't been decided, but Dick mentioned that there had been some talk of doing a vending machine, like for iGoogle gadgets. Google could be a (not the only) clearinghouse: you send your app to Google, Google sells it to people and gives you a cut of the money. This is the first time I've heard that suggested, and it's an exciting possibility: it gives a chance to really make a business from this while hewing to the open philosophy of Android and breaking out from a Qualcomm-style tight control. That said, the team's current focus is on finishing Android itself - "We're very busy" was a common refrain this night. These sorts of questions will be answered later on.

Along the same financial lines, another person inquired about advertising. Dick laughed. Everyone wants to know about ads, and everyone cares more about it than Google. He dismissed the rumors that, when you make a call on an Android phone, you will need to listen to a 30-second advertisement. Google's official position, the reason why they are doing Android, is to use it as a tool for keeping the Web open. There are more cell phones than computers in the world, and Google has a vested interest in making sure that all of them will be able to get on the Internet and browse freely, without being locked down in a walled garden. That's the big picture, and Google isn't interested in nickel-and-diming users. As he put it, his boss had told him, "Your job is to help developers make money." Google isn't after a slice of the pie, they just want to make sure everyone has access to the pie.

Will Android run on non-phone platforms, like GPS units or set-top boxes? Not at first, but after it's open-sourced, it will probably be ported everywhere. When will it be open-sourced? Google doesn't own all the code in Android - some is contributed by OHA partners - so it can't open source it all now. But, the agreement signed by OHA members says that all the software will be released when the first phone ships. So, we'll have access to it soon!

We don't know if there will be SyncML in the next SDK. It's a popular technology, but Google isn't sure yet what the syncing story for Android will be. Again, they want to get it right, not necessarily fast.

The main focus now is just on making it work and getting it done. Because of that, they aren't as devoted to standards as other players. Earlier in the talk, Dick had said that while J2ME was a great technology for its time, devices have now advanced to the point where its design is too limiting, giving Android a great opportunity to rethink how to do mobile development. If this includes breaking standards, so be it. Google is aware of the pain that this can cause developers, but believes it's important to make software better. (As an example, think of Google Docs. By releasing this tool for free, Google killed off some companies who were charging for similar services, but the market as a whole got stronger. Again, after Android is released they'll be able to focus more on standards, but right now, it's intentionally being kept quite fluid.)

The Google philosophy, in case you can't tell yet, is "Have a very long beta period." During that beta, they're free to tinker, and users are rewarded with improved products, but nobody should expectit to be stable.

The browser is built on Webkit and is comparable to the iPhone browser. People have had good experiences getting iPhone web apps to run on the Android browser. There will inevitably be some quirks, but so far, they appear minimal.

He isn't sure how judging for the Challenge will work. Ash, the Champion, said that he has heard that each OHA member will judge all the applications, using whatever criteria they want, and the winners will be determined based on that consensus. Also, Dan Morrill is in charge of the challenge, which was news to me but makes sense. I imagine there's a lot of pressure when you're responsible for distributing millions of dollars!

Finally, someone said, "When can I buy a gPhone?" "There is no gPhone!" was the immediate and correct response. As Dick said, Google has no interest in getting into the hardware game; they want others to get into the game, and want to help them succeed. As for Android devices, they will be shipping in the second half of 2008 - they still don't know exactly when.

At this point, they started to yell at us to leave, so we did. I was pretty impressed... it was already 9:30, but the last three and a half hours had flown by. It was a great evening for me, a chance to dig deeper into Android and, even more interesting, peek behind the Google curtain to learn more about what is actually happening on Android.

On my way out, I stopped and chatted in the parking lot with a fellow GTUG attendee. It turns out that he works for Yahoo, and as I drove home that night, I reflected yet again on how awesome Silicon Valley is. Just think about it! Google and Yahoo are, by all appearances, each others' biggest competitors (though even there, there is more friendliness than you might expect). And yet, an employee from one company could waltz into the other's campus and spend a night getting information from Google on its technology. Not only that: Silicon Valley is also the place that attracts people who, after working a full day creating technology for a tech giant, would voluntarily surrender an evening learning about different technology for another tech giant. We're all nerds, and we all get along. I love this place!

UPDATE: After testing out the onFreeze/onPause thing myself, I need to correct my above statement. I thought Dick had said that onFreeze will only get called if Android needs to recreate the Activity later (i.e., because another process is taking over), but I must have mis-heard. As I had previously thought, onFreeze ALWAYS gets called before onPause.

That returned me to my earlier confusion - why on earth have two methods for this, when they will always be called in combination? I haven't found an explicit explanation, but I think it may be just to simplify Activity design. Conceptually, onFreeze is responding to your transition to another Activity by storing persistent state; this state will later be passed to onCreate if the Activity was killed by Android. On the other hand, onPause is responding to your transition to another Activity by cleaning up non-persistent resources: reclaiming threads, canceling network activity, and surrendering any resource locks; these resources will be reclaimed in your onResume call, whether or not the Activity is still running in this process.

Continuing that thought: onFreeze can be omitted altogether if there's no state to restore. It isn't that Android doesn't call your method, just that you the developer don't need to do anything. In this case, your onCreate will always do the same thing.

Again, I'm not sure about all of this since I feel like I'm making it up, but it fits in with what Dick was describing and what I'm seeing in the emulator. If so, it's a keen design. I may need to revisit some of the Activities I've written in the past - I have been playing loose with the difference between onCreate and onResume, and between onFreeze and onPause, since they always seemed to move in lockstep (well, except onResume, which can happen every time you return to a screen). It will take a bit of work, but should make them more robust, and better citizens in Android!

UPDATE 2 3/17/08: Either I'm going crazy or this actually changed between M3 and M5. I'm now seeing the behavior that I thought Dick had originally described - when navigating from one Activity to another in the same application, only your onPause will get called, not onFreeze.

In practice, one thing this means is that I can't rely on onFreeze as a good place to store preferences, like I did in M3. I'll need to either move this to onPause or start updating preferences whenever they change.

I swear, one day I'll understand how this all works...