EP Mobile is now on iTunes, putting an end to the arduous process of porting the program from the Android to Apple environment. The version on the App Store is feature by feature equivalent to the Google play version. As addressed in my post on porting the user interface, the look and feel of iOS is quite different from Android, with certain features absent or different. For example there is a lack of drop down lists in iOS — instead there is something called a Picker View that looks like it belongs on a slot machine, taking up half your precious screen space. Constraining myself to just the widgets offered in Apple’s toolkit, I was able to duplicate the functionality of the Android program, though superficially the two versions look a lot different.
Android programs are written in Java and iOS are written in Objective C. Both languages are object-oriented languages, though admittedly with some big syntactical and structural differences. These differences are at first somewhat jarring. Java method calling is similar to C++, for example:
MyClass myClass = new MyClass();
int x = myClass.getX(32);
whereas in Objective C the equivalent would be:
MyClass myClass = [[MyClass alloc] init];
int x = [myClass getX:32];
Objective C is actual C with an object syntax applied from one of the first object-oriented languages, Smalltalk. The bracket syntax is used to indicate that, rather than calling functions on a class, messages are sent to the class. This concept and several other features of Objective C result in this language leaning more toward dynamic or runtime polymorphism similar to the Smalltalk language itself, or more recently, Ruby, rather than static or compile-time polymorphism seen in Java or C++. What this basically means is that it is easier to pass messages to objects at runtime without knowing the exact nature of these objects than it is with a language like Java. This may seem abstruse, but it turned out to be helpful as outlined further on. Other differences: Objective C as it derives from C is a compiled language, whereas Java is interpreted (after being compiled to metacode). Also, Objective C is almost exclusively used only in Apple products, whereas Java is a general purpose language (though since acquired by Oracle, seems to be losing its popularity, other than to program Android). After initially being a little put off by Objective C, I have to say that it grew on me. It is a simpler and in some ways more elegant approach to adding objects to C than that of C++, which has become almost too complex to use. And thankfully when I took up Objective C the language had introduced ARC (automatic reference counting) so I didn’t have to worry about dangling pointers and such. Java already has garbage collection built into the language which is one reason it is so simple to use.
Object-oriented programming is one of several strategies to improve clarity of code and prevent code duplication. Both Google with Android and Apple with iOS emphasize using the MVC (Model-View-Controller) pattern of coding, which keeps the data model separate from the view showing the data and the controlling code used to access the view and the data. Android and iOS implement the MVC pattern differently. With Android, you create an
Activity, which maps to a Java class, and you pass a resource file which contains the layout of the
View in the Activity’s
onCreate() method. For Activities that use the same or similar Views (i.e. the drug calculators or risk score modules in EP Mobile), it is easy to just reuse the View in different classes, which can themselves be subclasses of a common superclass that contains common code, such as the creatinine clearance calculation code in the drug calculators. In iOS, however, each view is either a instantiation of a view class, such as a
UITableViewController, or is a derived from a user class which is itself a subclass of a view class, e.g.
UIViewController. Using Interface Builder in Xcode, you connect these View classes to the data and delegate class(es) that contain the Model and Controller code. It was not obvious to me at first how to provide different data to the same View, with the result that in the first modules that I coded, I resorted to one of the no-nos of object-oriented programming, the giant switch statement. As time went on, I found that a better solution was not to use a switch statement or inheritance, but to use the technique of composition. As an example, the multiple accessory pathway and VT algorithms in EP Mobile all use one view. I created a SimpleAlgorithm
protocol, which is similar to a Java
interface. The protocol contains methods to handle clicking on the Yes, No, and Back buttons depending on the step of the algorithm, and methods to calculate and display the result. I then created classes for each algorithm that implemented this protocol (e.g. an
EPSArrudaAlgorithm class). When an algorithm module loads in the program, it just loads the appropriate algorithm class and sends methods to that class. Neat and clean!
id<EPSSimpleAlgorithm> algorithm = [[EPSArrudaAlgorithm alloc] init];
Note the syntax
id is a shortcut for pointer to
NSObject is the base class for all classes in Objective C. So
id is a generic pointer to any object. Adding the protocol in angle brackets after
id provides some type safety information to the compiler.
It took about 6 months to convert EP Mobile from Android to iOS. Every line had to be rewritten. There was little if any cutting and pasting. In the meantime, adding new modules has been put on hold. It’s time to get back to improving the program. My goal in writing the program was to off-load as much of my brain as I could to my cell phone, at least in regard to arrhythmias. As always, I am open to any suggestions for corrections or improvements. Please let me know.