The Costa Rica project was a marketing event native mobile application to be run on Android and iOS devices, for the purposes of providing event information, photo sharing, and reward based incentives to event attendees.
The process started with working with the business in order to generate high resolution wireframes, based on some of the functionality from the pervious year’s application. Through this process we also begin to elicit requirements and develop user stories. An important realization was that the function of this application required central data storage, which meant this mobile app would need to talk to a mid-tier that would store data in a database. We were not just building a mobile app, we were building a three-tier system that would have to be hosted and maintained in the cloud. The challenge of this project was that it had to be done in less than 6 weeks using 3 resources, which ended up being the primary force for driving scope and design.
As designs were finalized and detailed, project planning began and user stories were broken into tasks. Milestones were categorized by overall functional screen, and development was started. The only way this project was possible was through the heavy usage of existing assets, specifically AppContinuum for generating the initial codebase and infrastructure, Af Gradle for build management, Amazon EC2 for hosting, HTML5 Robot for test automation, and TestFlight for internally delivering the native iOS and Android mobile applications.
Another important consideration was that because these mobile apps were going to be submitted to their respective stores, we had to take into account the average length of the iOS submission process. While getting on the Google Play store for Android can be done in a matter of hours, iOS submission can take anywhere from 1 week to a month depending on if your initial application gets rejected. The assumption was made that we would need at least 2 weeks to get on the Apple AppStore, which meant we needed to be feature complete at least 2 weeks prior to the event.
Through continuous integration, every change resulted in unit testing, integration, and acceptance testing. Unit testing would verify code at the function level, integration testing would verify server-side functionality from the endpoint level, and acceptance testing would verify system behavior from a user perspective by executing automated tests in the web browser via HTML5 Robot. This allowed us to continually change the overall system while being assured that we were not breaking existing functionality. We later conducted load testing against the Amazon EC2 based infrastructure in order to best determine the Server and Database settings for hosting the projected event attendance numbers. The result was the endusers getting a fast and responsive native mobile application for the event.