How I implemented Meteor for iOS in only a few days, and you can too.
A quick guide to using Jesse Bounds framework for Meteor and Objective C
I currently have the pleasure of working with the start up MoyoMed. We are creating powerful iPad apps to help missionaries and non-profits deliver aid, triage, clean water, and agriculture to countries in need. Chad Elliott, our resident back-end expert, recently won several prizes at a Hackathon using Meteor. Once he demonstrated how we could use Meteor to connect aid workers in the field, with leaders back in the U.S., our eyes grew wide. After much deliberation, everyone was very impressed and it was deemed that Meteor was to be our new back end. Oh, and the deadline was less than 72 hours away.
A quick Google search lead me to Jesse Bounds Objective-DDP. A longer search lead me to the same place. This was an invaluable resource, but unfortunately his “How-To” section included one too many “TBD”s for me to not start panicking.
However, he has an excellent example “To-Do List” app that I worked with. Since deadlines don’t budge, I jumped in feet first and began reverse engineering it to implement it into my project. My hope is to throw in my two cents, and hopefully reduce some stress and spread the word of Meteor in Objective-C.
First off, a couple quick notes, Jesse utilizes CocoaPods which I was hesitant to start using in an existing app. So it took a little leg work, but it is possible to pull down the files and reformat them for non CocoaPods. If you would like those versions, let me know and I can throw them online. Also, he uses authentication, and you should too. Decoupling this framework from authentication is going to be a hairy project, and I wouldn’t suggest it.
To be clear, this is a post that will help you with Jesse’s Objective-DDP framework, which also uses ReachSocket. I can’t help you set up Meteor or with the web back end. This will help you implement Jesse’s work into your own app.
Step one is to set up a Meteor instance and publish it. You can learn more here: http://www.meteor.com/main. Then get very familiar with Jesse’s work here: https://github.com/boundsj/ObjectiveDDP. Now that you are set up and familiar with his To-Do app, I can add some value.
A lot of the heavy work is done by the App Delegate.
The important things to note are [self.meteorClient addSubscription: @”xxx”]; loginController.meteor = self.meteorClient; and …initWithURLString:@”..”.
These are things that are going to change with an implementation into your own app. First, you need to make sure that you are adding in subscriptions to the collections you set up in Meteor. It is very important to note that he is passing the Meteor object along once it is created using iVars. If you have an app that only has a couple views, this is fine, but if you have a complex app you will need to call on the App Delegate. You also need to make sure that you are connected to your Meteor instance. You should insert your website that points to Meteor in between wss:// and /websocket. I highly suggest you start with the LoginViewController as your rootViewController. It would take some work to get around that.
If you need to display other views in between the login screen and pulling or pushing info to Meteor, there is an issue. If you try to inject this code into your project you will quickly find out that the Meteor object is null and nothing is working. The best way to continue is to let the App Delegate hold onto the object, and call on the App Delegate when you need Meteor. Add #import “AppDelegate.h”. Now, you need to implement a method similar to this:
This will get the Meteor object from the App Delegate and will attach it to self.lists, which is the property I am using to get my survey information. Again, make sure that the collection you are calling on is correct and exactly matches the collection you set up in Meteor. Finally, for some comfort you can NSLog self.meteor and see the object is no longer null. Thanks to Objective-DDP and Jesse’s work, this is enough to start seeing information being pulled in from Meteor. We both put info into a UITableView, but I am sure you can come up with creative ways to display data. It is important to remember that you still need to be updating the UI to get the Meteor live updating experience. You will notice that he utilizes NSNotificationCenter to listen for an update and reloadData in the tableView, which is very effective.
Why stop there? You can also insert and delete information into Meteor. ObjectiveDDP handles that for you, and it is straighforward to implement into your own project. There are a few caveats though.
He utilizes BSONIDGenerator; this caused some issues for me. I would suggest using your own generator or methodology. You can also leave it out, and Meteor will generate one for you. Make sure that these parameters match up to your specific Meteor instance. Also, I noticed some odd behavior with the remove functionality, but it does work. It would be interesting to hear if that was just me or if you experience it too.
And that is it! Thanks to Jesse’s hard work, and some elbow grease on your end, Meteor is easy to get up and running into your iOS project. I am excited that this is being used to help save lives and create a better world for the less fortunate at MoyoMed. I would love to hear about how you are implementing the power and ease of use of Meteor into your projects.
Feel free to email me with any questions/concerns/edits/ideas. AntifragileDevelopment@gmail.com or visit my site AntifragileDev.com
