September 9, 2013

Today Software Magazine: From 0 to App Store in 6 Weeks Flat

TSM iPhone and iPad AppsOnly a few years ago, the IT community here in Cluj-Napoca lacked even the most basic form of self-identity. While there were a number of IT companies, they all focused on their own software, hardware, or services.

As one might imagine, this meant a number of individuals with pretty much the same background, the same interests, and same problems, but there was no common interaction pool, no place for us to gain visibility, share solutions to problems and – why not? – gain new insights into what it’s like working for our respective employers.

Slowly, the idea of a magazine that would relate to the local IT community, that would become the meeting point of all IT-related specialists, took shape. A small but committed group of engineers, managers and editors gathered to flesh out the idea for the magazine, and eventually coming up with the name that would adorn our monthly magazine: Today Software Magazine (TSM).

From the first TSM issue, which contained only three or four articles, the specialist magazine has grown in just over a year to become a consistent and diverse collection of content. It provides know-how and thought exchange and drives interaction both online and offline, with topics ranging from the explanation of new technologies to all sorts of problems and solutions that one may encounter in day-to-day activities specific to the IT industry, no matter what the employer or the project is.

As one of the major players of the local IT industry – with challenging and diverse projects varying from PHP to .Net and anything in between – 3Pillar saw the great potential, from its inception, of Today Software Magazine to serve as the focal point of the software development community in Cluj-Napoca.

Thus, we are truly and profoundly proud to host the launch of the September 2013 issue of Today Software Magazine, something we have looked forward to for many months now. We are even more proud to host the launch party than we would normally be because we will also be celebrating the launch of the Today Software Magazine iPhone and iPad apps, which 3Pillar developed in partnership with TSM.

Targeted towards iPhones and iPads, the application demanded expertise, energy and enthusiasm from four talented young 3Pillar engineers. The development team was comprised of three iOS developers – Tudor Stanean, Daniela Bulgaru, and Madalina Miron, and one QA engineer – Robin Molnar – all of whom are mindful professionals devoted to helping TSM become what the local IT community expects it to develop into.

The TSM application for iOS was produced by 3Pillar engineers under the “iOS Competency Center” umbrella – one of the many competency centers at 3Pillar. Our iOS Competency Center is where our iOS developers learn and develop the skills necessary to properly build an iOS application. Among the things our developers learn in the iOS Competency Center are how to incorporate different components and their interoperability, how to incorporate sane design and usability principles, and even implementing elegant and specific client-server communication mechanisms.

Now that you know some of the background of how the app came to be, let’s delve into the various phases of the 3Pillar development process.

Project Kick-Off

Once the decision to get involved with TSM’s iOS application was made, we called upon Ovidiu Matan, TSM’s editor-in-chief, to help start the project. He shared with us his vision of the application, along with his expectations, which is customary for a project kick-off meeting.

By highlighting key points of sought-after delivery, we started sketching up the application: what devices (iPhone, iPad) to make the app available on, what operating system(s) we would support (iOS 6), how we envisioned displaying the information, how the user would interact with the application, views, settings, options and more. We also shared the technical issues, challenges and risks that we identified.

Based on our preliminary talks with TSM’s editor-in-chief, the 3Pillar team drafted some initial mockups on how we thought the application should look, and delivered them to TSM for feedback. Here are some samples of how imagined the application would look and feel after our original kickoff meeting. The first mockups are for the iPad display and the second set is for iPhone:


TSM's iOS application

Magazine App Development

Once the core functionalities that needed to be included in the app were finalized, we then focused on what needed to be accomplished on our side and TSM’s side to develop the app. We agreed with TSM to develop the application using an agile scrum methodology, with short, two-week sprints.

The kick-off meeting took place in early July. Considering that adding one app to Apple’s App Store can take four to ten days, and knowing that we were targeting mid-September for a TSM app launch event, we were hoping to have an initial App Store release ready after only two sprints. We prioritized the feature list and the scope of the initial version and, of course, we also looked into whether or not external help was needed. We also conducted a risk and individual tasks analysis, so as to remove any possible obstacle or risk, in order to complete and deliver the app on time and well in advance of the September release party.

Last but not least, we decided upon what tools to use during development (GitHub as a code repository, JIRA for project/task management, TestFlight for distribution of test builds, etc.) and we created the appropriate communication and collaboration channels so as to allow for seamless and open collaboration between the TSM and 3Pillar teams.

Project Architecture & Responsibilities

Particular to this project, if you’ll allow me to indulge in a little wordplay, the client (TSM, that is) developed the server of this client-server system, together with the corresponding server-side communication mechanisms. 3Pillar built the iOS client application for it, along with such mechanisms as client-side communication and other wonderful and user-transparent features. The image below shows the component parts of the iOS applications and how they work together to serve content up to the end user.

Mobile Application Architecture

Application Programming Interface

The Application Programming Interface (API) was discussed and documented by both parties, and we concluded that TSM should implement the server API and then the 3Pillar team would implement the iOS client’s communication mechanism to the implemented API.

After several discussions and meetings, the following API requests were defined:

Issues Request

The Issues Request is called at application startup if the latest issues haven’t already been locally saved.

Request format:

Response format:

"label":"Numărul 11", 

The “imagePath” field is used to download each issue’s cover image. This process is done in a background thread, so that it will not negatively impact the user experience.

Articles Request

The Articles Request is called for each issue, and it responds with all of the articles available for the requested issue. Articles for the latest available issue are downloaded first, followed by the articles from older issues, which are downloaded in the background so that it won’t have a negative impact on the user experience.

Request format:

Response format:

"title":"Cu clipboard-ul ...\u00een nori la Startup Weekend Cluj", 
"summary":"Vineri, ziua de ...", 
"authorName":"Mircea Mare", 

Following the client’s request, the response packages up a list of objects in the format detailed above and, for performance reasons, the article image will also be downloaded in the background.

The field “completeArticle” tells us if the content of an article is available to be displayed or if we shall redirect the user to the web article. The article is loaded directly from the URL which is received in response in the “content” field.

Authors Request

Following an elegant optimization flow, this call is made whenever author details are necessary and they are not readily available locally. That is, whenever author details are needed, and they are already in the application database, the API call is not made.

The call is as follows:

Request format:

Response format:

{"name":"Mircea Mare", 
"description":"Software storyteller\r\n@ Cloud Clipboard", 

The single-object response to the call has the format detailed above and, as with any other requests, if not already in locally stored, the author image is downloaded in the background.

Objective C Code

One of the most important parts of the application is data management for the answers offered by the server and saved onto the device. So, in order to link the application components – components like data management and network trafficking – several classes would have to be used. This includes classes like TSMLocalDatamanager and TSMnetworkManager, frameworks that allow for data storage on the device and client-server communication.

Specifically, we used CoreData for locally keeping data and AFNetworking to properly manage requests and answers to and from the TSM server.

Some of the most used methods are listed below:

Data Storage

■        – (NSArray *)fetchedAllObjectsForEntity:(NSString *)entity;

■        – (void)addAuthorWithAuthorID:(NSNumber *)authorID info:(NSString *)authorInfo name:(NSString *)name imagePath:(NSString *)imagePath;

 Adds a new author entity to the database with respect to the given input parameters.

■        – (Issue *)issueWithIssueID:(NSNumber *)issueID;

This returns an issue object from the database that has the provided issueID. The returned object will be of the type “Issue,” which will match entirely the object description from the database.

API Request Calls

■        – (void)getLatestUpdatesSinceIssue:(NSInteger)issueNumber;

Applies the request by which the latest updates are received from the server and the local data is updated to reflected those changes.

■        – (void)getArticlesForIssue:(NSInteger)issueNumber inContext:(NSManagedObjectContext *)managedObjectContext;

This call is used to get all articles for a certain issue. The managedObjectContext is provided as an input parameter to cover the cases when the articles are downloaded in the background and temporarily saved on a different context, being a mechanism for background downloading.

■        – (void)getAuthorWithAuthorID:(NSNumber *)authorID;

This call creates and sends the request to the server to get information regarding a certain author by sending the authorID value as a parameter. This way the API will send the iOS client the author with the specified authorID value.

■        – (BOOL)hasNetworkConnectivity;

This call is used to identify if there is internet connectivity or not. This method is useful when we try to identify the connectivity, especially when the iOS client is preparing to make a call to the server or it prepares itself for downloading several images or other type of data.

For providing an accurate value, this method is defined using the Reachability framework, which can be used to detect the connectivity signal availability and the network type.

Design Elements

Due to our very good collaboration, in which we agreed that TSM was due to provide the designs for the application’s design elements, we managed to have a basic UI in a very timely fashion, early in the product development cycle, with only slight styling updates up to the final version.

Obviously, most of the missing UI elements were replaced by placeholders until the final version of the elements was available.

Starting with the skeleton of the application, then adding the underlying helper objects (helper views, deck view and helper objects), we created a separate object for each of the main elements of the application: issues view, compact article view, detailed article view, settings page and more.

Using the general-to-specific approach, we ensured the main functionality of the application was working, long before the final UI elements were delivered by the UI designers, because such objects are functional and responsive to user-interaction and, also, are independent from their looks in the final phases of the application development lifecycle.

QA Testing

Here at 3Pillar, we consider quality to be a key element of any application. Thus, we planned to include a QA engineer in the team as early as possible. And, as soon as he joined the team, the development process improved, as the QA engineer helped discover untested parts of the application or even unwanted behaviors.

The QA effort was divided into two parts, one per each device of interest, iPhone or iPad, targeting full functionality testing and, in respect to that, all aspects of the application and user interaction.

In term of traceability, we used our internal processes and tools (JIRA) for all updates, bugs or enhancements, and our developers worked closely with the QA engineer to make sure not only that we build the right application, but also that we build the application right.

Also, in spite of the reduced number of sprints, we used a three-stage testing approach, starting with exploratory testing, so as to strengthen the acceptance criteria and the team view on those, then this exploratory testing was phased out and replaced by feature testing (as complete features were being getting shaped). Then, toward the end of the application development process, the approach shifted to regression testing and final stabilization of the application.

It might not need to be noted, though, that the aforementioned testing approaches were always combined and none of them was entirely phased out. We just shifted focus from one aspect to another as development was moving along.

Typical Development Timeline

We at 3Pillar take great pride in being truly agile. So, accounting for the amount of work, the desire to only create a minimum viable product, the targeted launch date and the Apple App Store approval process, we agreed to a two-week sprint schedule. We planned for an initial submission to the App Store after two two-week sprints, and the second release after two more two-week sprints.

As with many customer-oriented processes, however, changes required by our partner, changes related to non-trivial aspects of the application, and delayed deliveries for some UI elements led us to having the initial release after the third sprint only. Enough time was built into the development process, however, that it did not impact the scheduled application launch event.

Sprint 1 Activities

At first, we defined the infrastructure (tools) necessary during the application development process (development tools, GitHub repository, TestFlight) then we proceeded to define the API required for the client-server communication, together with defining the basic UI elements and their behavior.

In an upwards process, from the cells and the view of the application: magazine issue cell, article cell, article view and so on, we integrated everything as a whole, while also working on the API, defining the way the application requests package issues, articles, information about authors, and everything else. This includes how the requests will be retrieved from the server, along with the roles and responsibilities of the client application and the server, so implementation work could be started, along with some user-transparent features.

This is the result after the first sprint, when the application started to take shape:

TSM Sprint 1 iPhone and iPad Apps

Sprint 2 Activities

During the second sprint, in terms of API development we finished implementing most of the functionality, as follows: fetching articles per issue, article content, author info (short description and picture).

We also refined the UI and the corresponding user experience, making sure that the application works in both English and Romanian, allowing for a consistent look and feel of the application, regardless of the language used.

Furthermore, we ensured that our partners at TSM had the server-side communication up and running, and they also provided us with the required designs and missing UI elements.

On the QA side, we included Robin in the sprint, so as to deliver a higher quality application, and he contributed by helping identify scenarios that were initially overlooked, by finding bugs and by providing pertinent views on the application flow and user experience aspects.

After the second sprint, the iPad application was ready for its first contact with the 3Pillar public, while the iPhone version still needed some UI elements:

TSM iPhone and iPad Apps After Sprint 2

Sprint 3 Activities

Client-server communication was finalized during the third sprint and we also incorporated the feedback we received after demoing the application from the second sprint, together with a few last-minute UI changes.

For the lagging-behind iPhone version, we added the missing UI elements and bug fixes, while simultaneously running extensive tests on all devices that we targeted.

Now that the application is ready, we are proud to have offered a nice user experience backed by stable and reliable client-server communication. This ensures that articles show up nicely, the author information is elegantly retrieved in a background thread, and we reach both English and Romanian readers.

Following is a screenshot of one of the latest versions of the application:

Today Software Magazine iPhone and iPad Apps After Sprint 3

Product Launch

As mentioned before, our sought-after goal was to have the applications launch in conjunction with the September launch of Today Software Magazine in an event facilitated and hosted by 3Pillar in Cluj-Napoca. For this, we intended to publish the application to Apple’s App Store so that by the time the September launch takes place, the application will be readily available for download and feedback from the TSM community on how it can be improved.

Even though development ran over by one sprint, we started an earlier integration with TestFlight to ensure that when the application is deployed it is in a proper state. Later in the development process, once we had an app both 3Pillar and TSM would be proud to put our names on, we submitted an initial version of the application for approval to the App Store.

This is why we invite everyone with ties or interests to the Cluj IT community, be it for technical reasons to read relevant articles, be it for HR reasons, or otherwise, to install the application and use it. We also encourage people to send us feedback on the application itself, so we can improve on future versions.

Future Releases

Elegance can exist in simple things. For this reason, we’d like to continue contributing to TSM and the TSM application, a future in which we envision an offline mode in which articles are available offline, if they were available last time the app was online, together with new settings to control how much and for how long TSM data is stored, or the use of the push notifications.

We could also allow bookmarks and in-app rating and commenting to articles to strengthen interaction around information and to emphasize the feeling of community around a shared opportunity.