Hands down the best demo I have seen. This would be the second (mine, weruat.com being the first) application I am planning on putting on my phone (when they come out).
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 -~----------~----~----~----~------~----~------~--~---
