WHAT WENT RIGHT We built on top of some existing technologies to try and get a leg up on the competition. Our tile renderer uses the well known Mappy library, our chat system is built on top of IRC, and our backend is built on Amazon's scalable EC2 service. This strategy was very successful. We wouldn't have been able to implement what we did in such a short period of time if we hadn't done this.
Early on we made the decision to use a web service model based on JSON and a RESTful interface. Our server wiz got this up and running quickly and we were able to extend it with ease as our needs grew. Accessing the server's JSON data from within Android was also quite easy. All the fetched data gets cached in a MySQL ContentProvider, which was a bit cumbersome to setup but is easy to use thereafter. Parsing JSON objects in Android is a snap. I think we must've gone through about a dozen UI iterations. That's quite a lot for a 3 month project, but I think it ultimately resulted in an interface that is consistent and elegant. We went through two phases of heavy UI iteration, one at the beginning, and one at the end. Experience gained during the first phase allowed me to be very productive during the second phase when our designer was cranking out new concepts. The development environment and Eclipse in particular were a dream for the most part. This was a welcome change from Visual Studio. On the couple of occasions where I couldn't solve a particular Android problem by sheer perseverence or by looking for solutions online, I posted on the development forums and was promptly assisted by a Google employee. WHAT WENT WRONG >From the start, performance was a huge concern for us. There was an immediate performance limit imposed by our use of Google Maps, which eats a good chunk of CPU and requires regular garbage collection. To improve this situation, I employed strategies to circumvent the default map rendering logic in order to more intelligently prefetch tiles as you fly around and more efficiently render our wide variety of overlays. This had the added benefit of reducing the somewhat ugly- looking tile loading that you usually see when people use Google Maps. However, this only got us so far. Early on I investigated rendering the map to a 3D plane using an orthographic projection and moving that around instead, but due to lack of support for hardware acceleration in the emulator, this didn't gain us much. Then I flip-flopped back and forth a couple times between using the event-based MapView and using a thread-based SurfaceView. In the final weeks of development I made a final switch to using a SurfaceView with a proper time- sensitive game loop. I employed all the strategies mentioned in Google's performance tips page, but I probably spent too much time tinkering with algorithms, time that could've otherwise been spent improving the stability of the heavily multithreaded code. In the version we delivered to Google, emulated performance on a modern computer was quite good, with some chugging when you fly into new areas, but emulated performance on low-end computers was tolerable at best. There were times when an interesting new problem arose, and I probably spent too much time on it. For example, we came up with an idea to build and render generic buildings using voxel-like brick images rendered at different angles to give us the flexibility of 3D with the convenience of 2D. I spent a couple days getting this tech working before I came to my senses and realized how much extra work on top of that would be required to integrate and polish it. I suppose this is probably a problem that most self-managing programmers face. We spent a lot of time implementing features we thought actual users would expect, like editing and deleting footprints, and some options to help manage performance and battery life, and live notifications for when friends create footprints. None of these were actually seen by the judges. So rather than focusing on these secondary (though important) features, we could've spent that time creating a rock solid 3-minute introductory walkthrough experience within the world that would have had a better chance of improving our score. Instead, we spent a little time at the end to create a more open-ended experience in the hopes that judges would be curious and interested enough to explore. I already mentioned multithreading but it's worth mentioning again. Java and Android in particular make it pretty easy to use threads, but I think this is pretty dangerous. We ended up having a UI thread, networking threads, a rendering thread and some miscellaneous worker threads for stuff like animation and loading, not to mention whatever threads get launched as a result of the Android features we were using. The language and the SDK help you set all this up and even manage it to a certain extent, but the usual pitfalls are still there. I didn't employ enough rigourous testing of my multithreaded code, and as a result, we shipped with some known indeterminate crashes that sometimes happen when moving the map in strange ways (exiting buildings, flying up and down, teleporting, etc). We discovered very late that these crashes occur more frequently on lower- end computers. GPS became a problem for us. Although I was able to setup a mock location provider, it wasn't always stable, and there was confusion on the forums about whether or not judges would be able to load mock providers. We couldn't use the default mock provider because it was in California and most of our content was based in New York City. So we didn't use the proper GPS provider and displayed a hard-coded GPS location instead. We were unable to include music and sound effects due to instability with Android's MediaPlayer and extreme audio distortion when running the emulator on Windows Vista. Since my main development box is Vista and judges might be running Vista too, we didn't include any music or sound effects in our submission. As our UIs increased in complexity (despite our best efforts to keep them simple!) we encountered a stack size limitation that effectively capped the possible depth of our view hierarchies. This was frustrating because the error message was obscure and I spent a great deal of time trying to work around it (I assumed it was my fault). A Google employee was kind enough to explain the situation to us, and apparently view hierarchies will be greatly improved in the next version of the SDK. I experienced similar frustration with the animation system, which works brilliantly in simple situations but seems to break when you try to get fancy. I ended up abandoning some ambitious ideas as a result. File management for our art assets started to become a chore because you can't use subdirectories in the "drawable" directory. So we ended up having almost 400 very carefully named images. I was able to successfully record a 3gp video using the emulator's camera, but playback of the resulting file is unsupported in the current version of the SDK. As a result, we disabled video recording for our submission (although you can still take pictures with the camera). Lastly, the lack of tools for visually designing UIs meant that by the end of the project I was speaking and dreaming in XML. I explored some of the community-made tools but found them to be insufficient for the complexity of our view hierarchies. I spent a huge amount of time creating and hand-tweaking multiple complex XML files (not to mention styles and strings), time that could've been spent elsewhere if there had been a more robust tool for creating and managing all that UI data. Ideally the tool would be simple and powerful enough that our designer could use it without a programmer's involvement. Having said that, we were still able to accomplish a lot with the UIs...it just took more time than I felt it should have. Thanks for reading and I hope other people post their post-mortems, too. See you on the other platforms! Michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Challenge" group. To post to this group, send email to android-challenge@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-challenge?hl=en -~----------~----~----~----~------~----~------~--~---
