Android/App Engine prototyping problems

Almost a year ago, Google unleashed its Android SDK in a preview capacity. One of the pain points I experienced with it was the tedium in creating ContentProviders. Today, I'm feeling the same tedium. A ContentProvider is the sole mechanism for an android application to share information with external packages. ContentProviders can be backed by any kind of data, file, database or live server with custom backend. The popular method is creating a ContentProvider that is backed by a database. Creating such a beast is a time consuming operation and making it with a SQL database is quite contrary to the BigTable based datastore API in Google App Engine (GAE).
In my top secret project, I'm using the HttpClientService api that I've defined in my Missing SVN repository (the top-secret project is indeed different than Missing) to interface with my server. Currently, the client does no caching of data -- all information it needs is pulled at user request, from the interwebs. When testing on my local machine, this is not a problem. I have a fast workstation and there isn't much packet loss or latency on a loopback interface.

Unfortunately, this won't work in the "real world." I'm now at the point where I have to implement a sql-lite backed ContentProvider that tries to model a table-based GAE datastore api. Not only does this mean I have to keep track of two different schema, one for GAE and one for Android, but it means I have to implement the same "get my data" api twice, with a layer of abstraction between the android UI and the ContentProvider I'm resenting having to create.

What I'm considering doing is using something like Google's Protocol Buffers or Facebook's Thrift to define my data model and create stub interfaces for both GAE and Android. This seems like a bit of overkill for the current state of my project but even in the not-yet-ready-to-show-anyone stage of this project I'm having to consider these very-high-time-cost coding excersizes. This is going to consume time when I should be iterating on features and trying to get the app in a state where I can finally start to use it. I think I've proto-typed the android app as far as I can go but I don't want to start spending hordes of time on this when I have several core concepts not-yet-implemented.

I'm also feeling the pain of knowing that the stuff I prototyped at the beginning of the project are going to have to be fully re-written and if I don't provide a more featureful content provider.

One of the ways you can provide an abstracted interface to the ContentProvider is by wrapping it in a Service, which of course requires yet another interface declaration, this one with java primatives and simple classes using the AIDL interface spec provided by Android. I figure I'll have to cross that bridge some day, I'm just glad I don't have to do it right now.

Labels: Android, appengine, facebook, Google, Java, missing, project

5:21 PM 0 comments links to this post

Design Patterns... BAH!

I started reading "Head First Design Patterns" last week, and taking advantage of my new-found knowledge I tried to refactor Missing's http client stack. Its taken me about eight hours and it works again. Its as ugly as it was before, maybe even more so.

The kookiness of the design stems from the fact that I want the ability to respond to an HTTP response, possibly from a different thread. Android has a cool thread/message-queuing class called a Handler, that allows you to post a Runnable to the handler and it will get executed on the thread in which the handler was instantiated.

Because I wanted to keep my http stack android-agnostic (not that I had a good reason for it, in fact I didn't even think of doing it at first.) I removed the knowledge of the Handler from the .http package.

Instead I created a decorator for the HttpResponseRunnable that does know about Android's handlers. For the sake of re-use on another project, I put it in the .http package... DOH!

On the positive side, I did manage to implement a design that allows me to dynamically create http requests and responses without having to subclass all the time. I don't know if in the long run that will be better.

Things I need to think about:

1. What is the best way to chain http operations where each request depends on data from the previous request?
2. How would I design the HttpService from the ground up? Where can I look at code that has similar features to the ones I'm coding up to see what design they used.
3. Why am I constantly re-writing this stack?
4. If I am going to have a large number of http callbacks, if there are many types of end points, do I want keep the ability to define them quickly, or do I go with something more verbose and more abstract?
   

Do you know Java? Want to discuss some of this with me? I'm a newb and could use insight from someone with more experience than I.

Labels: Android, code, Java, missing, project

4:42 PM 0 comments links to this post

Missing

One advantage of being several thousand miles from home is that you have the chance to sit down and work on things that you're normally too distracted to deal with.

As such, out here I've had the chance to work a bit more on Missing. I've re-written the http client stack I was using to use HttpClient 4.x instead of 3.x, with better abstraction and a multithread-but-threadsafe client. I've also gotten the LocationManager code working and the phone now supports a location update round trip. The server component needed a few tweaks to make this work but the majority of my time has been spent working on the Android client.

I became more enthused about this when jgib pointed me at sf0.org where they're running with the whole play-a-game-but-in-real-life-and-get-levels-and-stuff.

Labels: Android, code, missing

7:53 AM 0 comments links to this post

How to run the hacking part of a cyberpunk game. Part I

This was taken from a recent email exchange I had with some friends in regards to running our own cyberpunk game.

First off, to dash Josh's hopes and dreams: This is a cool idea but of all the games we play, this is going to be one of the more expensive ones. Plastic tubes, foam and duct tape are cheap compared to any projectile driving device. Second, if you're going to represent technology, then it has to be to some degree realistic, what game are you playing if your "internets" is just a hand wavy alternate dimension/plane with the minor environmental effects? I think in both cases you'll require some sort of investment in enabling technology. GPS, airsoft guns, light or wireless access points. Something that will bring out the cyber part.

Making the interwebs is a very difficult prospect. I've tried games like "uplink" and have spent much time figuring out how to make "hacking" anything other than a drab and boring experience; mostly because its a drab boring experience. If life were more like the movie Hackers we'd be much better off but there would probably be more capsized oil tankers in the seas and far more dead artists threating the world for 25 million dollars. Row ... row ... row ...

I think one thing that could make this whole game more fun is distributed involvement. Because you have communication devices at your disposal, its possible to involve people who are not physically located at the game. For example. Joe schmoe is busy one weekend and cannot be onsite. He happens to be the puzzle solver sort of person so he knows a lot of what is going on. During game play something comes up, a player calls Joe schmoe and joe schmoe looks up on wikipedia the solution to the puzzle. Winner! Or, do you not want to consider the world wide web at your disposal?

I think another source of inspiration for this sort of game are ARGs. They do a good job of blending reality with gaming and since we're already in a derivative of the cyberpunk, dealing with real world tech in game would not be a bad thing. This game is also going to need much more preparation than another rpg because writing a website is not as easy as writing in script on a parchment.

Because we're not playing a tabletop game we can look at what shadowrun /current/ edition does with Decking. Because of the way networks have firewalled themselves from the internet a lot of decking is done inside. The running team gets the decker into the corp network, then they do their thing. Or they kidnap someone with approprate access and use their accounts. They did a good job of getting a character class that was essentially a solo gig and made it in integral part of the runner team. In otherwords even your hacker characters are going to have to get in there and be involved in modules. This also means that where people are in meatspace is relevant to where they are on the "interwebs."

Now, here is my pitch and Josh is in disagreement with me here. I think that you need a software framework to be easily able to build and interact with virtual puzzles. I think you'll need multiple gps enabled smart phones (iphone, android or s60) or wireless network + PCs, a server, wireless networking to get this game off the ground. Communications play a large part in the cyberpunk world -- especially when they go out and the players who have come to rely on their decker or their off-site drones lose some control. I also think you need some evolution of my software (http://missing.googlecode.com) or something like it (hopefully there is something better than the crap I have put together) to build any sort of technological layer on top of your game. Now the problem is you need this stuff to be accessible which means, like I mentioned earlier smart phones and laptops for the game.

Labels: Android, code, cyberpunk, missing

10:05 AM 1 comments links to this post