In my last post, we ended up with this: <div class="row" align="center"> </div>
It indicates that I have selected Parse as the backend provider, and that my app will communicate with Twitter. Now, it’s time to define exactly what information goes where. I’m not going to attempt to walk you through my entire thought process; I’m just going to tell you what I decided.
There will be 4 classes of information that my app is concerned with: Users, Tweets, Guesses, and Tweeters. Here’s an overview: <div class="row" align="center"> </div>
Whenever someone uses the app for the first time, a user account will be created for them. This involves creating a User object and saving it locally (on their iPhone) and then saving it online in the Parse database. Because users must login with their Twitter account, each User will be directly associated with exactly 1 Tweeter object, which is just a reference to a Twitter account (more on that later).
These objects include all of this information. Obviously, these will be downloaded from Twitter using the API. The Tweets will be saved locally on the device the first time they are downloaded to prevent redundant downloads of the same Tweet, which will reduce the app’s network traffic. The actual Tweets will not be saved in the Parse database.
Every time a User attempts to finish a Tweet, a Guess object is created. This Guess object needs to provide information about: ###- The Tweet object ###- The User attempting to finish the Tweet ###- The User who Tweeted the Tweet (the Tweeter) ###- The actual word guessed ###- Whether or not the guess was correct
But wait! Here, we encounter a problem. What if a user tries to finish the Tweet of someone who does not have a Finish account? In that case, the Guess object will be unable to reference the Tweeter’s User object, because there will be no User object. For that reason, we separate the Tweeter object from the User object.
This is just a reference to a Twitter user, stored locally on the iPhone and online in the Parse database. Every Twitter user that has ever had one of their Tweets guessed by a Finish User will have an associated Tweeter object in the Finish database.
Each time a new User creates a Finish account by logging in with Twitter, the app will check to see if their Twitter account already has an associated Tweeter object in the Parse database. If not, a new Tweeter object will be created.
All User objects will have exactly one Tweeter object, but Tweeter objects do not necessarily have an associated User object.
The last thing that I will do before I actually start writing code is to explicitly define the process for putting data in the right place. Here, I will outline the process for 3 common actions: creating an account, refreshing the list of Tweets, and “finishing” a Tweet.
That’s it for the design of the app. The next step is to actually write some code and see if all of these pieces fit together. I’m sure that there are some minor inconsistencies in this design, but I am also confident that I can overcome them and code this up in just a few hours. Stay tuned!