Android Market is open!
Let the awesomeness begin!
Labels: Android
Monday, October 27, 2008
Tuesday, October 21, 2008
Statusinator
I've updated the first app I wrote for Android, Statusinator. It is a client that you can use to update your status and upload photos to Facebook. It will be up on the Market as soon as it is launched, but until then you can get it from the Project Homepage.
Labels: Android, Statusinator
Saturday, October 18, 2008
Losing Some Steam
Oh no! I just realized the other day that some of the core code in the Android side of my Top Secret Project is going to have to be re-written. I am very sad about this and have started to lose a little steam. It doesn't help that I've spent the past two weeks letting the feeling linger while I hung out with friends in Toronto. I have one week before I'm back in Chicago for a bit and while I don't think I'm going to be able to make my app launch-ready by Wedensday (The G1 Launch Date) I feel like the app *is* coming along to some capacity. I sometimes dream of having a team of Engineers working with me on this project, all as dedicated as I am. If that were true, the past two weeks, each and every one of them would have written a total of 0 code for the app. I guess its a good thing right now that I'm not running a startup or anything like that. Who ever heard of a startup stopped because some crazy country up North decided to abscond the dude in charge?
Thursday, October 2, 2008
Catchup with two hands
its been six days and its time again to leave SF for a new place. I'm going to be in Toronto until the 15th. I'm in for work but ahould have plenty of time for fun. Heck, as I'm good at doing, I am in Toronto over a 3 day weekend too.
I have taken this whole week off of work, including Friday but excluding part of monday. In that time I have been able to catch up on several months of life. I got a haircut, went clothes shopping and had several Hendricks (great gin, thanks for the recommendation josebiro) Martinis. I have also added a few more needed features to the top-secret prokect and am still looking for someone to do some UI design work, I could also use someone who is interested in mobile applications, python, java and/or javascript because I think I need more people to work on this if I'm going to get this completed in any reasonable amount of time.
On one hand, I see that I am making steady progress. Every day that I sit down and focus on it, I walk away at the end with something newer and better than before. On the otherhand, some of the ideas that propelled me to work on this project seem so far away in the future that I'm worried ill never get to the cool problems that will make this project stand out. Heck, I've no doubt pumped some people (including myself) up about this and I'm sure it won't meet anyone's expectations.
On the other hand, I'm still happy about the work that I have completed, I just wish it hadn't taken four months to get here. My thought is that in the next few days ill start using the app on my own and see if in its current state it is usable. If not, I'm going to have to take a hard look at what it will take to make my project get there. if not I will have several months of rewrite ahead of me and I will surely have lost the first to market edge.
Sunday, August 31, 2008
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
Sunday, July 20, 2008
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:
- What is the best way to chain http operations where each request depends on data from the previous request?
- 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.
- Why am I constantly re-writing this stack?
- 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.
Friday, July 4, 2008
Monday, June 30, 2008
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.
Wednesday, June 4, 2008
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.
Monday, May 26, 2008
Statusinator
Last year after the Android SDK was released, I wrote a small app that allowed me to upload photos and update my facebook status with a native application. Here is the result. I re-implemented a subset of the official facebook API because I didn't understand it. (It wasn't "not invented here syndrome" it was more of a "I am not smart syndrome"). Anyways, I've posted the code at statusinator.googlecode.com and there is a Facebook app page as well.
Labels: Android, code, facebook, Statusinator
Tuesday, May 13, 2008
ADC Round 1 Winners! | Android Phone Fans
ADC Round 1 Winners! | Android Phone Fans: "City Slikkers - a Pervasive Game (alternatively Location Based Game) which takes place in the real-existing city. It is designed to connect a large number of players through-out the world and change the way the surroundings are seen. The central idea behind the concept is to give people the opportunity to symbolically interfere with the everyday urban environment and come into contact with previously unknown people. By PoroCity Media and Virtual Logic Systems." I'm very excited about this Android contest winner. It'll be exciting to someone else's take on my idea for "Missing." I think I am most interested in their statement that the game will "affect normal life as the everyday city is no longer the same due to the player's experience." I didn't take into account that masses playing this game will end up having an impact on the non players. Bringing a new landscape into a city, one that isn't people getting from home to work or from point A to point B has great potential to make each city this takes place in a bit more personal. Sure many people will have their own thing to do and many others wouldn't be interested in this fantasy but some people will latch on and every new player will make the game more persvasive. I was not very keen on the description that "As the playing community will always be a minority they hereby form some kind of elitist, secret society which is based on knowledge, but not financial or political power." That attitude could definitely sour the experience, bringing a futher gap between gamers and the general public. To really make this work there has to be varying levels of involvement and complexity. As a weak game player I don't want the game to run to far above my head which this seems to imply.
Labels: Android
