Good reusable solutions to problems usually come out of necessity rather than luck or leisure. Over the past 18 months I was always faced with problems of how to simplify the data integrity, security, and aggregation of multiple datasources, usually in big organizations that would then be fed in an iOS app.
The first solution to this issue is to create the "man in the middle". Essentially a proxy/web services layer that acts as the gateway to all the necessary model objects. Utilizing tools such as Gearman, CouchDB, MySQL, PHP, Python, Memcache and a little bit of Apache to make everything complete I was able to deploy a lightweight standard response to the iOS app. As requests from various business groups would come in I found myself taking more and more out of the app and putting that logic into the services layer. Instead of having to rely on the app to handle security, data integrity, computational analysis, image manipulation, etc. I pushed that onto a light weight stack server side that could be scaled easily and mainainted without having to revision the app for basic model object changes. The added benefits that I saw later on were that I could adapt the response based upon the request…(Android, iOS, mobile web, desktop browser, etc.)
Now that I was concentrating more on feature sets, bug fixes and UI enhancements I was still stuck with having to manage various model classes within the app. This was a serious pain point to me. I wanted to be able to consolidate the various list and detail controllers that I had down to one instance of each.
Objective-C runtime to the rescue.
Let me be very clear that objective-c runtime is VERY powerful and not for the faint of heart, but when used effectively can be quite useful. The approach that I took was as follow.
Use the existing "standard" json format from a web services layer and restructure the "responseObject" so that it gave meta information about the model name, properties for class, which properties should be displayed on the list page and detail page. By structuring the json (xml, plist, etc) play load this way I now can push changes to model object and display anytime I want.
In the github project I use an "Employee" object as the example. The app should be able to show a list of employees (title and subtitle) and then a detail page for each employee that would display up to 3 properties.
I have included another json file for "Events" just so that I can show the flexibility. The same list/detail view controllers are now reused for two different objects.
The (current) limitations.
- There is an assumption that your list view will use the subtitle uitableviewcell enum type.
- Parsing and creation of classes doesn't take into account types other than nsstrings. I have an idea to remedy this, just haven't implemented yet.
- What about images? Most list views have an image associated with it. What I am thinking about it having a flag set in the properties specifically for images so that they can be loaded asynchronously.
I will be adding in these features. I am still getting my head wrapped around some of the advanced features of runtime. Below are the links to resources that I used in my research.
Posted on slideshare is the presentation that I gave. It details the philosophical and practical importance of having an SOA that is similar to what I described. It was heavily inspired by the presentation written on the subject of NPR's SOA.
Presentation References:
