Be the first to like this
This work describes a solution to a costly problem that surfaces in software product engineering on Objective C technology stack. Particularly, it emerges when designing a software product targeting both OS X and iOS where a significant part of the functionality is common for both platforms. This brings in the question of how much code can be reused between the two implementations.
A multitude of concerns need to be probed and the solution domain can easily be a victim of combinatorial explosion. Like in many other cases, analysis in terms of design patterns can put things in perspective. Both Cocoa and Cocoa Touch (standard frameworks for application development in OS X and iOS respectively) highly encourage embracement of MVC as a design pattern. It is even a necessity for utilizing certain parts of the two frameworks. Therefore, it is wise to keep our solution inside the MVC design paradigm. Our exploration to the solution starts with a close examination of MVC and the role played by each component in the design pattern.
Controllers in both Cocoa and Cocoa Touch are responsible for managing views and responding to user actions, embracing Strategy pattern. They are tightly bound to the views they control and therefore are hardly useful outside the context of that particular view. At the same time views and controllers in OS X (based on NSView and NSViewController respectively) are disparate from views and controllers in iOS (based on UIView and UIViewController respectively). This is mostly due to differences between the two platforms. It inevitably confines cross-platform reusable space to model classes. On the other hand, it is not very unlikely to have certain views in the product that are supposed to appear and respond to user events in similar ways in the two platforms. Failure to exploit this cleverly in the architecture can lead to code replication causing less maintainability. It will also disrupt the homogeneity in user interface semantics of the application between the two platforms. Thereby strict adherence to traditional MVC hinders the architect from harnessing the power of this domain artifact.