Yesterday, I defined a very basic UX for the app. So, when designing an information architecture, I need to ask myself what information the app will need to make that UX a reality. The easiest way to answer that question is to look at the views and analyze where the information is coming from:
The first screen shows Twitter user profile pictures, usernames, and times for each Tweet. The second screen shows the actual text from the Tweet. So, it is obvious that this app needs to communicate with Twitter.
I also want to keep track of user scores, and I would like them to “sync” so that everyone can see the scores of their friends. This will require some kind of central database of scores. I would also like to generate statistical information (the “metrics” mentioned in the last post), but for now I’ll just worry about the score.
It seems as if there are 3 places where information will exist: ###1) The app itself (locally on the iPhone) ###2) Twitter ###3) The central database of scores
I’ll address these one at a time:
I already mentioned that I want to release this app in the iTunes App Store, so I have 2 options:
Using a hybrid development approach, I could write one app and release it on multiple platforms. In other words, I could release the exact same app on iOS, Android, and Windows Phone without writing new source code for each. Hybrid apps are increasingly popular in the enterprise world as companies implement new BYOD (bring your own device) policies. This creates a need for platform-agnostic software (apps that works the same on iOS, Android, etc..). If I chose this approach, I would use a free tool such as Phone Gap, but many businesses opt for more professional tools such as Appcelerator. I’ll shut up about it for now, but if you want to learn more, you can always Google it.
Using a native development approach, the source code that I write will only be compatible with iPhones and iPads. However, I will be able to utilize many iOS-only functions and optimizations that will unleash the full potential of the iOS platform. This difference is manifested in the small, trivial tasks that most people take for granted. For instance, when pressing a button or scrolling through a list, the native app will simply respond faster, display at a higher frame-rate, and feel better than a hybrid app. Here’s a good Google search if you want more information on the subject.
Using this approach will also enable me to use several Apple-specific software development tools. For instance, I will be able to write source-code that hooks into my Storyboard file (mentioned in the last post), which will enable me to visually edit my user-interface. Debugging and general configuration are also simplified when using Apple tools to make software for Apple products.
For this project, I will develop the app natively using Xcode.
Most consumer-focused online services, especially social networking services, will provide some type of API so that other apps and services can access user-data. In this case, the online service is Twitter and the data that we want access to is the Tweets in a user’s timeline. I have seen several different apps that pull information from Twitter, and I am fairly certain that it is possible to create an app that reads a user’s Twitter timeline. One quick Google Search and a few button-clicks later, I arrive at this page, which verifies that I can access that information.
According to dev.twitter.com, I will need to use version 1.1 of the Twitter API, which requires a security protocol known as OAuth 2 to verify both the user and my app before I can read the Tweets. So, all I will have to do is register as a Twitter developer, register my app with Twitter, and then my app will be able to read data from Twitter (if I format the network requests exactly right).
Basically, I need to save some numbers on the internet in such a way that my app can read and edit them. This will require a web server, or at least space on someone else’s web server. For the sake of generating statistics, it will be very helpful to store these scores in a relational database as opposed to a text file. Again, I have several options. I could build my own server, or I could buy a pre-built server, or I could rent a server from somewhere, or I could purchase a virtual server from a hosting provider. I could manage my own database, or I could pay a pre-configured database service. I could use an application framework such as Django, Ruby on Rails, or Java Spring to securely translate network requests from the app into valid database queries. Or, I could take the easy way out.
I will use a web-service called Parse, because it is easy and free. Parse, as a company, manages a large cluster of database servers. With minimal configuration, my app will be able to store information on these servers, and I need not concern myself with the details. Parse also has an incredibly rich framework for iOS that makes communicating with the database really simple; I just drag-and-drop some software libraries written by Parse engineers into my app’s source code, and I can save objects in the cloud using 1 line of code.
To sweeten the deal, Parse has also created a library that will allow me to create a new user in their database and authenticate them with their Twitter account, which saves me a lot of work. They even take it a step further and they provide a function that automatically formats the Twitter requests with that user’s Twitter credentials, so that communicating with Twitter is now extremely easy as well.
Parse is free until my app starts making more than 1-million requests in a month. Then, it will cost upwards of $200/month, depending on the amount of traffic I cause them. There are several other iOS backend services out there, but for this project, I’m sticking with Parse.
It’s not the prettiest thing in the world, but it gets the point across. Now that I have identified all of the sources of information, my next step is to explicitly define what information will be stored where, and how that information will be accessed. In my next post, I’ll refer to this process as the Data Processing Design.