Wow Michael, thanks for the detailed report. I wish you luck with future development.
I have say though that I'm really surprised Duo didn't win. I think the general consensus was that this was one of the most complete and polished applications submitted to the challenge (that we knew of). I'm still trying to get over the smarts of losing (submitted Fluid Nexus), and I'm really interested to see who won. I definitely don't want to disparage the winners at all, and offer them the fullest congratulations--I'm just interested to see what the judges (i.e., the companies in the alliance) thought was important and, by extension, what they thought wasn't important. nick On May 9, 2:48 pm, Michael Johnston <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
