A few months ago I stumbled upon a blog post by Robert C. Martin entitled “The Clean Architecture”. The author demonstrates how classes can be divided into layers, depending on how central they are to the problem at hand, thus leading to better separation of concerns and modularity. I think that the ideas presented in the article are really valuable, and would therefore like to share my thoughts on how they might apply to the platform I deal with most of the time, which is iOS.
I have been working recently on a Xamarin.iOS application for managing events. One of the application’s interesting and challenging features is the way it displays multiple lists of events with the help of some relatively advanced, but intuitive UI. This is what the homepage of the app looks like:
One of the fundamental mantras of software development is DRY – “Don’t repeat yourself”. It’s an important rule, because it allows us to save both space and time. Instead of rewriting a non-trivial algorithm, we use a method call, instead of correcting bugs in multiple places, we do it only in one. Would you ever not follow DRY? Well… yes, when you need to develop a mobile app. If your plan is to get as many customers as possible, releasing an iOS and Android version is a must. This means maintaining two very similar codebases. Can we do better? The answer is yes and it’s called Xamarin. It’s the platform we’re using for some of our newest projects at Trifork, and I would like to share with you our experiences, likes and dislikes. Read on if you’re not afraid to abandon Xcode and Objective C.
Being an iOS developer, I spend most of my time writing Objective C code. It is fun and rewarding but often not enough to fulfil all of my product’s goals. One of the most important ones is portability. To create a successful mobile application these days we have to target at least two of the biggest platforms: Android and iOS. Does it mean that we have to implement the same functionality twice? Yes, to some extent. While we can’t avoid developing platform specific parts of our app (assuming that we want to develop in native code), we always have the option of extracting common business logic into a single C++ library that can be shared between the Android and iOS clients. Following this path can save us a lot of development effort and potentially increase the app’s performance by bypassing Objective C message sending infrastructure. In this post I will focus on how to build a simple C++ library and start using it within your Xcode project.