My typical app development workflow involves brainstorming, idea formation, validation, feature selection, design iteration and eventually, development, a chain of events that usually takes atleast a month.
This time around, we decided to go from idea to app within a day!
In this post, I’d like to describe to you how my team of three built an iPhone and an Android app in 20 hours, both supported by a common Node.js back-end. Aside from documenting our experiences, I hope this post serves as impetus for those who have been mulling over their app related ideas for long periods of time but have yet to get serious development work under their belts. If you’re not interested in the nitty-gritties, skip ahead to the key takeaways listed at the very end of the page.
Before I get started, I would also like to point out that this is in no way a challenge to articles that have recently been doing the rounds describing the time and cost challenge of building apps. The apps that we built in these 20 hours were rich in features, but their design, security and robustness was far from release quality.
Timeline: The Making of Vigilance
Hours 0 to 2
It was 1.00 PM on a Sunday afternoon when I, @govind201, met with @satyamag, @vinothgopi. Prior to meeting, we had vaguely discussed building an iOS app capable of helping people avoid becoming victims of crime. Having been victims of assault and vandalism ourselves, we wanted to built a warning system to notify people when they accidentally wander into areas of high crime.
Eventually, we decided that “Vigilance” would monitor its user’s location, display its estimation of levels of danger at that location and list the most common crimes in the area. Thus, the user would be able to gauge his or her exposure to everything from car vandalism to physical assault. By means of the heatmap of crime reports provided, augmented with clickable pins, the user would also be able to temper his or her perceptions by manually analysing the reports.
By the end of the first two hours, we’d listed all the features that we wanted and made sure that we were all on the same page.
Hours 2 to 5
Two of us began by searching for raw data to gather off of the web. It took us about an hour to identify a couple of sources of data. These sources included reports of arson, robbery, assault, vandalism and sexual offences. Using Semantics3’s web crawlers, we were able to get hold of the data within a half hour, after which we spent a further half hour cleaning up the data and porting it to SQL. We decided to focus on California at first, since the goal for the day was to get a working product up and running, as opposed to being thorough.
In the meanwhile, @satyamag got underway with getting the basic infrastructure of the iOS app up and I got started on the API.
Hours 5 to 9
The API was to receive latitude and longitude coordinates from the app and return an estimate of the “danger level” at that location, the “confidence” in this estimation and a throttled list of the raw data that underlies these estimations.
By then, @satyamag had gotten a good chunk of the app up including polling the GPS at regular intervals and design for the page that was to display crime stats and details. The app was able to communicate with a mock static API that we’d set up for test purposes.
Hours 9 to 14
At all times, we were keen on ensuring that we did not fill in gaps with temporary hacks. We could have gotten geosearch in place through an on-the-go Haversian distance function embedded in a SQL query, but clearly, this would not be scalable in the long-run. Hence we looked to Sphinx search and after hours of struggling with Limestone, the only available Node-Sphinx connector, we got Sphinx geosearch to work. (Geo-search supported Limestone code to be up soon, since the current version does not provide adequate support).
In the meanwhile, @vinothgopi worked on merging data from multiple sources together, notably, combining data regarding sexual offences to data concerning general crimes. He then incorporated his aggregation algorithm into the Node server, adjusted JSON responses to meet the app’s requirements and eventually got the API up and running.
By now, @satyamag had completed both the map and the details view of the app and gotten it working with the API. We already had something on hand worth talking about.
Hours 14 to 20
In the meanwhile, @satyamag thought up an interesting feature. Since children are prone to wandering off into dangerous territories accidentally, and are not likely to have the presence of mind to monitor the app for information, he added a “child mode”. Essentially, the app would automatically SMS two of the child’s emergency contacts if and when the child is in danger. @satyamag accomplished this by integrating the nifty Hoiio API and before long, he was tweaking the graphics and colours of the app and adding deft final touches.
As @vinothgopi polished the API and tested the algorithm I decided to get underway with an Android app. I had previously built multiple apps that are heavy on geo-location and mapping; thus, using some of my previously written code, I was able to get the basic framework up. Thereon, I engaged in a sprint to replicate what @satyamag had done on iOS. By the end of the 20th hour, the Android app was done, albeit without some of the cool features that @satyamag had integrated.
Get your hands dirty! App development can often seem to be a mountainous task at the outset. A great way to get started is to just start writing code.
That said, plan for the long run. Don’t resort to hacks that will have to be redone later. Getting the entire basic skeleton down is imperative. Before the day had started, we didn’t know a whole lot about Node.js APIs, Sphinx search, iOS geolocation, SMS APIs and much more, but we’re now comfortable enough with these ideas to set informed deadlines for the future and make adept feature choices.
Have your basic design plan in mind before you get coding though. Massive design changes are difficult to affect and often render code redundant; but the fact of the matter is that most design considerations that are debated over long periods of time don’t fall into this category.
Jot down a list of “things to do” in the future as you build your app. This includes either additional features or security/design/scalability/cross-device considerations that don’t fall under the category of a minimal working prototype. For instance, I’ve made a note to build 9-patch images for my Android app during my next iteration.
If your app is reliant of pre-generated data, focus on a subset rather than attempting to get all the data ready at once. The toughest dataset to integrate is the first one, closely followed by the second. Beyond that, the difficulty curve plateaus.
Statutory warning: This mode of development may not be applicable to the development of all kinds of apps, particularly those that are graphics intensive, so use your own discretion in identifying parallels between our experience and your needs.
All in all, I hope this post gives encouragement to some of the less experienced but promising app developers out there. Feel free to get in touch with me via Twitter (@govind201), email (firstname.lastname@example.org) or comment on this post if you have questions or feedback. I’d love to have a chat about any of the stuff covered here.