AF Networking Simplifies iOS Http Requests

I wrote this post a month or so ago on implementing http requests using the built in iOS libraries. I've been building a iOS app with a Rails on Mongo instance functioning at the backend API. I just switched everything over to AF Networking, which has helped simplify my network calls greatly!

If you compare these two approaches you can see the simplicity AF Networking gets you!

And then you just implement the two methods given to the networking operation callback block. In this case, processResult and processFailure. It's so simple! And so much less code than the standard iOS option.

The AF Networking github page.

iOS Data Synchronization - How???

I'm working on an iPhone app at the moment and I'm approaching the time when I'll need to do data synchronization with my backend Rails API. Up to this point, I've only pulled data down to the mobile device so the backend has acted as the sort of 'master' of the data. Now, data entered on the device will need to be incorporated into the 'master' data and available to all users.

I've sort of been deferring the decision of how to implement this until the last 'responsible' point because it's a daunting task... and done wrong, would perhaps need to be completely done over again in the future.

I remember the pain on my last project (an Android tablet app) after we brought in our first solution to data syncing between device and backend. We suffered through 3 months of headache and then gutted the whole thing for another strategy. The odd thing is the initial thing we'd gone for was one of the Android 'recommended approaches'. These things called Cursor Adapters. Steer clear! I'll maybe do a different post on these and why they are painful.

So, I'm cautious about using libraries intended to be a one-size-fits-all. Luckily I guess, I haven't actually found any for iOS, so I think I'll be rolling my strategy.

These are the questions I'm asking myself.

1. How close are the data models between the device and backend?
2. How much data will be need to be synchronized?
3. How frequently will it need to be synchronized?
4. If the user deletes the app and reinstalls it, will data need to be downloaded to the device in the same state as before the delete?
5. I'm going to need to know which data came from which user.. how will I tag the data as such?
6. How to queue up changes if they are made while the user if offline?

Because I don't have a huge amount of data that will need to be synched, my initial approach will be to set up a process that checks for changes across the tables where they might occur (initially only 2 for my case) and then pushes these to my RESTful backend using JSON over an HTTP post request. My backend, will then store these data in separate tables where the user and timestamps are recorded. After this, I should be able to set up another timed request. More posts as I move forward on this!

iOS provisioning HELL (solved)

Sometime I feel like the relationship I have with Apple is quite similar to that one would have with a bipolar boyfriend or girlfriend. The good times are really good... and the bad times are REALLY bad. But you just stay because you can't imagine life without them. :-) They brought us smart phones, mac books and iPods. You can't give those up! And they obviously brought us mobile apps easily distributed though an app store. This is great!

But it's well known that it's a pain the ass releasing your app through their long and tedious process. Provisioning used to be a nightmare! It also used to be hard to get your app to beta testers because you needed their phone's UDID and then you would have to produce a different build for each UDID. PAIN!

Test Flight was the earliest tool out there for managing your builds and distributing them to stakeholders, testers, etc.. I was even talking to Jeff Soto from the iOS Brooklyn Meetup and his team at Tendigi are building a tool to integrate Test Flight with their QA process. Very cool!

I've actually just started using AirOnApp because they go one step further and remove the need for collecting each of the UDIDs from every device that you'll distribute to during testing. They resign the app automagically for the each device. :-)

I'm planning on releasing my app in the next month and will use their automated release process as well. Hoping that goes as well as beta testing distribution!

iOS 6 Facebook Integration

<script src="https://gist.github.com/4161726.js?file=AppDelegate.m"></script>

<script src="https://gist.github.com/4161735.js?file=AppDelegate.m"></script>

Add the plist item 'FacebookAppID'

Add the entry to URL types.

Knock this into a delegate method.

<script src="https://gist.github.com/4161746.js?file=gistfile1.txt"></script>

<script src="https://gist.github.com/4161750.js?file=gistfile1.m"></script>

Configuring Environment Variables iOS

Say you've got an iOS app talking to a backend api. Maybe this api runs as localhost on your machine when you're in development and maybe you also have staging and production environments out in the cloud somewhere. What's the best way to set this up?

I've gone with an encapsulated pList... setup as follows.

This is my pList file.
I encapsulate that in a class called EnvironmentVars.

After which, I can access it as follows from anywhere. This is an example of using it to create a NSUrl object.
Objective C code can be terse. I find it's best to exercise encapsulation to the extremist point to maintain sanity.

Post 4.3 Xcode & Command line tools

I'm currently getting new mac mini ready for Ruby on Rails, iOS and Android development. I had Xcode 4.3 installed by default but I didn't have the standard /Developer directory where you get all the lovely command line tools used for Ruby development. Some of my gem installs were working, but some were not. Was seeing stuff like this from the terminal:

$ make
-bash: make: command not found

Weird, right? Where are my command line tools?

Turns out, in Xcode 4.3 and later, you have to specifically install these and they aren't in the /Developer  directory.

Once Xcode is installed. Go into Preferences > Downloads Tab > Components Pane

From there install Command Line Tools.

Boom. Terminal works.

iOS development - Writing an app - Pt 2 - Choosing data storage

This is the 2nd in a series of posts concerning iOS development. I want to begin my app by choosing a data storage technique. I'm leaning towards Core Data because I want to hook it up with my models using xCode's for iOS 5 storyboards... but I realize I need to do my due diligence and research all the options. So, here they are with an outline of my needs.

The vision for my app will definitely involve some robust storage capability. Without saying too much, the foundation for my app will be a users ability to build, track, and share recipes. I'd like to investigate my options for this. My research has concluded that in iOS development you have a number of on-device data storage techniques as your disposal.

Property Lists - These are sort of key-value pair storage techniques. You define them programmatically and they're loaded when the app starts. I suppose this is the simplest, most basic option. It's limitation would be you don't get any relational capabilities.

SQLite - With this option you get the relational thing at least in your database because it's SQL. It's my understanding that the support for this comes from some C libraries included into the iOS framework. Since SQLite works off a single file, you can seed this with your data and load it into your application. I plan to investigate this further in another post. It appears this option involves the requirement of writing your own sql queries. Boo.

Core Data - This is sort of the Maserati option. Core Data is provided and customized to work with xcode development. You get your relational structure. You hook it to your data models via xcode. You don't have to deal with database connections or schemas. It's basically the only option where you get an ORM feeling.

My decision is to move forward with Core Data. Not only will it satisfy the curiosity of how storyboards work with it, but it's the ORM option. And I love ORMs. Don't get me wrong, I can write my fair share of SQL, but if there's something out there that does all this for you... why not use it?

iOS development - Let's write an App - Pt 1

This will be the first in a series of posts where I document the process of writing an iOS 5 app using Xcode. I've been playing around here and there for about a year. I want to take it to the next level though. I'm going to write an app around storing, tracking and sharing home-brewing recipes.

As I write my app, I'm going to move through the decision-making process, high-lighting what I'm thinking about and why I'm making the decisions I'm making.

I've obviously already made a couple decisions so I'll go ahead and document those here.

1. Why a home-brewing app? Because I love home-brewing. :-) (Even though I don't do it anymore.... see: the size of my NYC apartment.) I also think there's a gap in the market here... be it a somewhat niche market.
2. Why native iOS? Well, my current 9-6 job is native Android development. I want to explore something outside of this. I thought about doing an HTML5 or jquery-based mobile website. And, I appreciate the fact that you reach more users this way. It's just that I'm less interested in exploring these right now. I want to play around with Xcode, especially some of the latest features.  

So, off we go!