I'm too surprised Duo didn't win. Actually I'm interested to know what a criterion of judging for learning the reason I've failed. And like Duo, I hope more to succeed in the business world.
andy On May 9, 2:34 pm, nick <[EMAIL PROTECTED]> wrote: > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
