We are excited to share with you some great news! Today we are officially announcing the availability of the iOS SDK for Contentful. The arrival of the SDK should make it very straightforward to integrate the Contentful API and to distribute your content to iOS apps.
Read on to find out what our iOS SDK does and how you can use it to build content-driven apps more easily. The coffee guide app from our recent hackathon will provide an example and walk you through building a simple app from start to finish.
There are three different ways for integrating the SDK into your own apps, described in detail in the README. For the purpose of this article, we will use CocoaPods, a dependency manager for Objective-C, which makes it easiest to keep the SDK up-to-date:
However, you are free to use Git submodules or download a static framework if that suits your workflow better.
The class CDAClient manages all requests to the API. For most apps, you will have a single Space which contains all your data. In this case, it is recommended to create a singleton category on top of CDAClient to make it simple to dispatch requests from any part of your app:
For creating a client object, the Space key and a Content Delivery API access token are required.
Now that the client is available everywhere, you can fetch entries:
Each CDAEntry has a fields property, containing the values for Fields defined in the content model. To decouple your app from Contentful, you can register custom subclasses for Content Types, like this:
The BBUPlace class defines properties like:
so that you can deal with Entries like with any other value object.
In the guide app, the class also implements the MKAnnotation protocol, which enables directly showing Entries in a map view.
The initial view of the guide app is a list of all coffee places it knows about. For common tasks like this, the SDK brings some UI components which can be customized to your needs. In this case, we will create a subclass of CDAEntriesViewController, a UITableViewController optimized for showing a list of Entries matching a certain query.
The basic setup is done in your subclasse's init method:
The cell mapping is a dictionary for specifying which property of the UITableViewCell corresponds to properties in the content model. In addition to that, the shared client is specified as the client to use and the entries are limited to a certain Content Type. Setting the query property is optional, in that case all Entries will be shown.
If you want to show Resources in a UICollectionView, there is CDAResourcesCollectionViewController. It works similar to the Entries view controller:
You need to specify a layout, just like in a normal UICollectionViewController and there is also the cell mapping again. For convenience, there is a ready made collection view cell class which fetches images from the URL in its imageURL property, so that is what we are going to use in this example. The resourceType property defines which type of Resource is going to be fetched, in this case Assets. A CDAAsset has a direct accessor for the URL which is used in the cell mapping here. Finally, the client needs to be specified, like in the previous example.
Of course, it is also possible and often needed to write normal UIViewController subclasses and just pull in some data from Contentful. The class BBULocationViewController from the guide app does just that, utilising the BBUPlace class mentioned earlier. That way, it does not have specific knowledge about the Contentful SDK.
Two things to consider here:
For more information about managing content in native iOS, watchOS, tvOS and OS X apps, see our article: Selecting an iOS CMS.