BLOG IS MOVING:
Find all future updates at: blog.quazie.net
“You have 48 hours to write an iPhone app…. GO!”
That was the theme of my weekend and the main question at the start of Friday evening was “What to do?”
Within the week leading up to the competition my friend, Mike Harlow, asked me to work with him during the contest. He proposed his idea, a photo-based dig-like app for the iPhone. I was immediately interested, but at first a bit worried. Without someone who had knowledge of how to write a back-end, storing photos was going to be difficult and time consuming. I expressed my concerns and we went our separate ways, brainstorming all the while. A few days later I had a solution, flickr would do our photo storage, and a simple app engine back-end could store any additional information and serve up our xml, a solution that I was confident could be implemented with the limited back-end knowledge we shared.
I went into the competition with two goals : to have a working app in 48 hours and get to bed each night. In the end, I was able to meet both of these goals.
After the first day of coding, we had a working list-view and photos loading from flickr via a YQL call. Everything seemed to be working quite well. A few other teams had some great ideas and I was very excited to see what would happen. I won’t discuss them in detail here as we’ve been talking about various IP issues in class, but the ideas ranged from stand alone applications, to interesting word games, to crowd-sourced experimental applications. The ideas were plentifu l.
The next day was UIScrollView hell. Mike had been working on the UIScrollViews over night and had some promising results. After we got our pictures loading properly into the app, we decided to go with an interesting UIScrollView idea that involved having two parallel scroll views, one for portrait view and the other for displaying data when the phone was horizontal. This led to a lot of dificult coding, and learning a lot about the intricacies involved in having two different views to accommodate different orientations.
We never would have come to the conclusion that a UIScrollView was a good solution for our problem if it hadn’t been for the whole group of iPhone programmers there. The environment was great for learning, as people ranged from having extensive iPhone knowledge to being cocoa newbies . Personally, I think it’s the environment that makes these kinds of competitions valuable. It doesn’t matter if you win or lose (though it certainly feels awesome to win) because the quality of knowledge you gain in the short period of time is far greater than a similar amount of time spread out over weeks, working by yourself. You aren’t just presented with the group resources in any other environment, and for that reason I feel like competitions like this one should be held more often .
The final day of the competition approached. I arrived at the CSE building at 10am sharp, delayed only momentarily by a bike race that was happening around North Campus . I came in with one goal: hook up the back-end. The App Engine back-end I had created was a simple hookup. A simple put request here, a get request there, and I was able to add photo IDs to my database and increase Hail and Fail counts. I had the back-end perform the YQL search similar to the following:
select photo,id,secret,description,farm,server,title from flickr.photos.info where photo_id in (select id from flickr.photos.search where text = "dog")
To the resulting XML, I added my hail and fail counts, and the back-end was complete. The next step was figuring out all of flickr in 3 hours. This was harder than I had imagined. I applied for an API key and got to work. After an hour, I had authenticated my flickr user to the program, but I still had no idea how to upload a photo. An hour went by, one hour until the competition was over, and I still wasn’t able to get a photo uploaded to flickr. Half an hour later, after writing my first post request, I had it! A photo loaded onto flickr from my app! Then came the title, and once again it was not working. With 20 minutes to go I found an objective-c MD5 implementation that allowed me to properly sign my requests. 10 minutes to go, I figured out exactly how to construct the response with a title and description…2 minutes to go, I test the app on the iPhone…1 minute, it works!
I don’t think either Mike or Myself would have been able to complete the application in 48 hours without the others help. The idea started out as his brain-child and together we made it a reality. Mike did a lot of the graphical work and layout, and I did most of the python back-end and flickr ’integration. We both worked on the core of the app.. Mike was a real trooper, staying thorough the night when many went to bed. All in all, it was a great experience, and I’m glad I had the opportunity to participate in another coding competition, although I really hope to get a lot of sleep this weekend!
Here are some screen shots from the app I made durring the 48 hour iPhone dev competition. The app is called ‘Hail To The Pictures’, it is a local dig-like for photos for the University of Michigan.
This weekend, I participated in HackU, a Yahoo! sponsored event that happens at various campuses around the country. Throughout this past week, Yahoo! came to UofM, and I had the opportunity to participate in the competition.
For me, the events started on Wednesday March 18 when Rasmus Lerdorf, the creator of PHP, spoke in two of my classes. First, he revealed to the class how insecure and vulnerable a very basic University site is to hackers. Then, he took questions from the class. He provided me with some advice on working with open source projects, and gave some interesting responses to all inquiring students. Because Ramus came to my class that day, I had an increased awareness of Yahoo!’s presence on ca
Later that night, I was waiting to participate in my first “Coffee House Coders” session at Mujo (in the Duderstadt), and remembered that Yahoo! was having an event on campus, which undoubtedly meant free food. I walked in a little late, but just in time for dinner. I sat down, and listened to a presentation that discussed SearchMonkey, which I had heard about before, and YQL, which was soon to become my new best friend. I spent about an hour after the talk speaking with both Rasmus and Paul Tarjan about opportunities involving YQL and the geo-location APIs that Yahoo! created. I left with the seeds of an idea freshly planted, which would later grow into a winning HackU hack.
That night at “Coffee House Coders” I proceeded to investigate what I could do for my hack. I have been working with an open source mapping library for the iPhone this semester, called Route-Me, and I knew that with it I would be able to do some cool stuff. I spoke to Tom Croucher about some of the mapping APIs and eventually found a way to incorporate Yahoo! maps into my project. My hack idea had sprouted.
I arrived at the UM CSE Building right around 4pm to begin hacking and talking with the various Yahoo! evangelists that were running the event. I played my first game of ‘faceball,’ and came out as the winner, beating Tom 5 to 2. After a while, I settled down with my hack and started to figure out what I could do.
My first task was to use Yahoo! to tell me where I was; using some of their reverse geo-coding APIs and some YQL I was able to convert a lat/lon coordinate into both a city name and a woeid. I knew that I wanted to use the woeid infrastructure to dig down into a town, but I never expected it to be as useful as it turned out to be. After diving into the documentation and using a hack provided by Paul Tarjan to visualize some of the woeid infrastructure, I determined that ‘Points of Interest’ and ‘Land Features’ were my destinations, and began planning my infrastructure. I ended up writing some code that would recursively search through woeids, placing ‘Points of Interest’ and ‘Land Features’ onto my map as markers, and searching through other woeids for their children . After some time, I had a fully-functioning system that could display everything that Yahoo! found interesting in the users current city.
The data for Ann Arbor showed 360 points of interest, decidedly too much data to display at once. I showed what I had to Rasmus and he suggested trying to filter the results. I quickly implemented a filter on “Schools,” “Parks,” and “Others” for my app, allowing the user to view only schools, only parks, or only other types of places.
Next, I decided to make these points more interactive. I moved from using geo-data to w
orking with BOSS, and from navigating locations to navigating data. My goal: an “I’m Feeling Lucky” query; one search result that would give me the most relevant information by providing a specific enough search to render the desired results. I already knew the city I was in, and the woeids came with the name of the various places I had marked on my map. By using YQL, I was able to quickly make the necessary query to find the Yahoo! search result that was the most valid. A bit more hacking and I had a functioning web browser view in my app and could rapidly display the site to a user.
It was now 4am, and with the help of a Red Bull I continued on into the unknown, I decided it was now time to create my first web service. I had been complaining all day that there wasn’t any way for users to add information to the woeid system, so I decided that I should either shut up or do something about it. I was in the middle of a coding competition so I had no choice but to do the latter. I signed up for an Appspot account and began to learn both how to use Python and how to deal with arguing developers. Taking advice from both Tom and Paul at the same time was quite interesting as they each had differing opinions on the correct way to implement it, but eventually I was able to get the basics of my service going. Following quite a bit of error checking, hacking, and Python developing, I had myself a rudimentary front end and the ability to spit out XML. A quick OpenTable later and I was able to deal with my data quickly and easily through YQL. I threw together a few quick parsing rules and I was able to generate new markers using my back end as the data source. Once the markers were on the map they just worked with my “I’m Feeling Lucky” scheme.
The last few hours of the event were devoted to adjusting the appearance of the app. Getting some css advice on my front end, changing my input scheme for new poeids (“Place on Earth ” IDs, my name for the user-generated woeid extension) from ‘city name and lat lon of the new point’ to ‘Address’ a much easier data entry mechanism.
After coding for 24 hours and knowing that I was one of two teams that decided to spend the entire night, I was unsure of the other projects out there. Finally getting to see the Twitter/Flickr mashup game was great, as I had been following their project the whole time. I was completely blindsided by the y!Vmail team; they had a full, working text-to-speech mail system that functioned over the phone, which came together beautifully. The awards began and the Twitter/Flickr mashup came in third. I hoped that I was among the top two as I suspected that y!Vmail was still in the running. Rasmus began to talk about how difficult it was to pick a winner and how difficult it was to compare something crazy that hadn’t been done before to something like the y!Vmail system. And then he said, “We decided to go with crazy!”.
I never though I would win the event, I just wanted the opportuninty to show that someone could do a whole lot of interesting things in a way that was unexpected and unusual. My entire system, minus the web-service, was written to run natively on the iPhone, 100% objective-c, no Java, no PHP. Personally, I believe that this made the hack more difficult, but so much more interesting to make.
If you are reading this and your school hasn’t yet done HackU, or there is a coding competition coming up, give it a shot! Even if you are uncertain. If the event is as well-run as UM’s was, you will have a whole group of people at your disposal that can help you overcome various technical difficulties, continuously point out how you can better you system and give constant encouragement. Who knows what could happen?
Here are some quick screen shots of my winning hack for HackU. I’ll be posting more information on the hack and the 24 hours of hacking later in the week.
I’ve been developing an iPhone application for a while now. Hopefully in the next few weeks we’ll have gotten enough done to actually post some public photos, and some more information. But one thing that I was originally having trouble with (beyond the oddities that come with the iPhone dev kit itself) was how to make something happen after x number of seconds.
If you’ve looked into doing this, you might have thought that using a timer (likely an NSTimer) would be the best idea, and there are plenty of cases when this is true, but I have found that all of my needs have been met by delayed messaging.
How delayed messaging works is as follows: (I’m going to assume your classes inherit from NSObject, if they don’t then the following will not work, though they should all inherit from NSObject if you are doing iPhone dev work).
NSObject comes with the following function:
- (void) performSelector :(SEL) aSelector withObject :(id) anArgument afterDelay :(NSTimeInterval) delay;
This means you can send another object a call, with any valid NSObject in scope, after delay seconds. The opposite of this is the cancel, which can be called whether or not there is a performSelector call waiting to occur.
+ (void) cancelPreviousPerformRequestsWithTarget :(id) aTarget selector :(SEL) aSelector object :(id) anArgument;
The implications of these two calls are amazing.
In my own app I need to find out where a user is, but I don’t want to leave the GPS on if the user isn’t moving. Whenever I get new data about the users location I call:
[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(stopFindingUser) object:nil]; [self performSelector:@selector(stopFindingUser) withObject:nil afterDelay:5];
The above two lines of code do the following. Line one says that if there are any pending calls to stopFindingUser, cancel those calls. The second line says that in 5 seconds stopFindingUser will be called.
Delayed messaging is pretty simple, but incredibly powerful.
I’m going to try this again. I’m not sure what will end up on here, and I really have no agenda. If things work out, this should be a source of interesting info, personal computer/life hacks that work for me, iPhone development info, and eventually a place to post information on my European adventures. The blog may move, may grow, may become stagnant, but for now, this is my little place in the internet to place my thoughts. More to come.