In an Android app the class is defined in a single block using public and private terms to assert whether or not they are ‘public’ or ‘private’ classes, methods and variables. This is different to iOS, where the notion of public and private are established by the structure.
The header file in iOS makes public the methods and properties that the programmer wishes to make public to the app and all the rest remains concealed within the .m file.
We’d therefore take a class such as the one given by Mednieks et al. in Chapter 1 of their excellent book, Programming Android, and transform it into an iOS method by splitting it into two files. On the left you see the Android code (from Mednieks et al.) and on the right the iOS code (written by me).
When it is time to create an instance of our class we do so in the following ways.
and to call the incr() method within our class this is how Android and iOS would do this respectively:
This presentation might well make the iOS approach appear bloated, but there are many benefits to the Objective-C/iOS approach when the complexity increases, and it should not be dismissed so quickly.
This is the first in a series of posts for learning Android through the eyes of iOS or perhaps vice versa. I hope to follow up with more soon.
See the second part in this series of blogposts here: Android through the eyes of iOS: Object classes and class extensions (Part 2).
The header file in iOS makes public the methods and properties that the programmer wishes to make public to the app and all the rest remains concealed within the .m file.
We’d therefore take a class such as the one given by Mednieks et al. in Chapter 1 of their excellent book, Programming Android, and transform it into an iOS method by splitting it into two files. On the left you see the Android code (from Mednieks et al.) and on the right the iOS code (written by me).
| public class LessTrivial { /** a field: its scope is the entire class */ private long ctr; /** Constructor: initialize the fields */ public LessTrivial(long initCtr) { ctr = initCtr; } /** Modify the field. */ public void incr() { ctr++; } } | LessTrivial.h
#import <Foundation/Foundation.h> @interface LessTrivial : NSObject // make public the incr method -(id)initWithLong:(long)initCtr; -(void)incr; @end LessTrivial.m #import "LessTrivial.h" @interface LessTrivial () @end @implementation LessTrivial // make ivar - instance variable - available to entire class (but private to the class) long ctr; // Constructor: initialize the ivar -(void)initWithLong:(long)initCtr { self = [super init]; if (self) { ctr=initCtr; } return self; } // method defined to modify ivar -(void)incr { ctr++; } |
When it is time to create an instance of our class we do so in the following ways.
| LessTrivial lessTrivial = new LessTrivial(18); | LessTrivial *lessTrivial = [[LessTrivial alloc] initWithLong:8]; |
and to call the incr() method within our class this is how Android and iOS would do this respectively:
| lessTrivial.incr(); | [lessTrivial incr]; |
This presentation might well make the iOS approach appear bloated, but there are many benefits to the Objective-C/iOS approach when the complexity increases, and it should not be dismissed so quickly.
This is the first in a series of posts for learning Android through the eyes of iOS or perhaps vice versa. I hope to follow up with more soon.
Bibliography
Programming Android: Java Programming for the New Generation of Mobile Devices by Zigurd Mednieks, Laird Dornin, G. Blake Meike and Masumi NakamuraSee the second part in this series of blogposts here: Android through the eyes of iOS: Object classes and class extensions (Part 2).
Comments
Post a Comment