With WWWDC starting next week, Apple have been extremely busy; and so have I. Last Friday I submitted my latest iOS app, the first version of Tournament Scheduler and got approved in just over 24 hours without error or revision, the fastest submission time I have experienced for my apps. Whatever reason apple expediting app approvals, or them just working hard or bumping up the numbers of approved apps in the store in time for the conference; I'm not complaining! It's nice to get an app approved without rejection in such fast rate. Don't take away my own effort though. I've been labouring on this app and I have enjoyed every bit of development. Without getting too technical, I'd like to share some architectural decisions I made in developing this little app. Also take a look at the app video preview below to see what it's about.
The app does what it says on the tin (or so I claim). It schedules tournament fixtures targeted for amateur sport coaches, league and tournament organisers. The schedules come in 4 different types namely; round robin, American round robin, single elimination and double elimination. I built a similar app four years ago in the form of iTournament Lite, however it is limited with two schedules and is rather old and in need of an update.
With this in mind, I started thinking about the over-all architecture of the app. I knew I was going to use Realm.io as my backing store based from my previously launched app Wind Times. It's very easy to use and is blazingly fast. Realm's website has a lot of valuable resources and one of them was relevant to this project. I watched Andy Matuschak's talk about value types entitled Controlling Complexities in Swift or Making Friends with Value Types. I was also aware of a talk in the 2015 WWDC about crusty entitield a Protocol Oriented Programming Language in Swift which ties in with the whole concept of value type programming et al. In the end, I wrote the main scheduling routines from value types with protocols as opposed to using classes. For this particular project, I will write another post about value type programming.
The other concept I applied to the app was Model-View-ViewModel pattern or MVVM for short. This design pattern has been around for quite some time now and was developed by the people from Microsoft since 2005. I really like this design pattern as it has many advantages over the simplistic and conventional MVC pattern pervasively adopted by Apple. One of the many advantages is it's highly testable and maintainable because the separation of concern is enforced. This enforcement comes at a cost. The cost is the overhead of writing the view model layer for each model view relationship. On simple applications this can be seen as overkill but in my opinion it's worth it because sometime in the future you would want to add functionality and without this infrastructure the complexity will start piling up into a massive view controller (MVC).
Finally and not the least and actually the most interesting is the use of RxSwift, the Swift version of the ReactiveX also developed by Microsoft. There is a lot of literature to take in when developing with RxSwift including functional reactive programming (FRP) and asynchronous programming to name a couple. In a nutshell I would describe FRP as programming in mathematical equations to solve fourth dimensional problems (time). Whoa, that's a handful. Ironically, the way I used this in the project is simplistic in that I used asynchronous programming as the binding between the relationship of the V-VM of the MVVM pattern I described above. Without RxSwift the alternative to this binding is key value observation or KVO that comes with boilerplate code to implement. KVO has been around for a long time and I even used this in the first re-incarnation of my iTournament app. But RxSwift is more elegant. I have yet to learn more about RxSwift and functional programming in general as I am still a novice, and every effort I put into this, makes it more satisfying.
So what's next? Well there's a lot of exciting things to learn next week from the WWDC. Although porting this app over Android is an interesting prospect since most of the toolsets I've used including Realm.io, RxSwift and MVVM are platform independent.