Delegate Design Pattern : Objective C vs Java

One of the most used design patterns in iOS is Delegate Design Pattern. The main usage on this design pattern is to delegate some functionality from called component to caller controller. On image below is shown simple diagram of this pattern where from main controller we call custom component with action to show data from concrete page loaded from the model. The custom component loads data and then displays. In case when no data is loaded for requested page the custom component throws notification thru implemented method in main controller from the custom component protocol. We can look on protocols in Objective C as in interfaces  in Java so the method which is defined in the protocol should be implemented in the the controller that expect some event delegated from the custom component, and also set instance on the caller controller to the custom component where the custom component will use method declaration to send some data to the caller controller or will try to execute the method.

       Delegate Design Pattern

To be much easier to understand, we’ll make comparison on implementation on delegate design pattern in iOS and in Java and we’ll see how can we create custom components in both platforms and use that components to return data to controllers where they are called.

Objective C version

ViewController.h

#import #import "ServiceConsumer.h" @interface ViewController : UIViewController @end

ViewController.m

#import "ViewController.h" @interface ViewController () @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view, typically from a nib. ServiceConsumer *consumer = [[ServiceConsumer alloc] init]; consumer.delegate = self; [consumer returnNumberToDelegate]; } #pragma mark - #pragma mark - ServiceConsumerDelegate methods - (void)executeWithResult:(NSInteger)testValue { NSLog(@"Returned value from delegate is %d", testValue); } - (void)didReceiveMemoryWarning { [super didReceiveMemoryWarning]; // Dispose of any resources that can be recreated. } @end

In header file we import delegate module but also we conform with the delegate of the module. In implementation we make instance from the service consumer but also we set the delegate to self which mean we need to implement the methods defined in the protocol.

 ServiceConsumer.h

#import @protocol ServiceConsumerDelegate - (void)executeWithResult:(NSInteger)testValue; @end @interface ServiceConsumer : NSObject @property (nonatomic, strong) iddelegate; - (void)returnNumberToDelegate; @end

ServiceConsumer.m

#import "ServiceConsumer.h" @implementation ServiceConsumer @synthesize delegate; - (void)returnNumberToDelegate { [self.delegate executeWithResult:32]; } @end

In ServiceConsumer header we can see the protocol definition but also the most important line, property definition as id – generic object that have to confirm to the protocol defined in here. In implementation we can see the method that call method executeWithResult which is defined in the protocol but it call it from the delegate property which mean that the class that will have implemented the method defined in the protocol and also confirms with the delegate, if that class call the method returnNumberToDelegate from the ServiceConsumer that class will receive the response in implemented method executeWithResult. We can see that the functionality is delegated thru line [self.delegate executeWithResult:32];

Java version

With creation on instance of the ServiceConsumer we initialize engine with the instance that implements IServiceConsumer interface. That is done in constructor here. In this class we also have one method returnConsumerData that same as in Objective C version, if is called from the class that implements that interface and have implementation for method printMessage defined in the interface, this method will call that method thru the instance set to interface in the constructor.

ServiceConsumer.java

public class ServiceConsumer { private IServiceConsumer consumer = null; private static final String MESSAGE_0 = "MACHINE IS RUNNING"; public ServiceConsumer(IServiceConsumer consumer) { super(); this.consumer = consumer; } public void returnConsumerData() { this.consumer.printMessage(MESSAGE_0); } }

In Java version instead of protocol in Objective C we need to have interface with defined method.

IServiceConsumer.java

public interface IServiceConsumer { public String returnConsumerData(String data); public void printMessage(String messgeData); }

The class that calls the engine makes instance from the ServiceConsumer class with setting the Machine.this to the constructor of the ServiceConsumer class because it already implements the interface. Also because it implements the interface it should also implement the methods defined in the interface in this case returnConsumerData. Method loadConsumerData is used to call returnConsumerData method implemented in the ServiceConsumer, which after calling return data thru method printMessage.

Machine.java

public class Machine implements IServiceConsumer { private ServiceConsumer consumer = null; public Machine() { this.consumer = new ServiceConsumer(Machine.this); } public void loadConsumerData() { this.consumer.returnConsumerData(); } @Override public String returnConsumerData(String data) { // TODO Auto-generated method stub return data; } @Override public void printMessage(String messgeData) { // TODO Auto-generated method stub System.out.println(messgeData); } }

iOS UI Runtime Builder based on XML Definition

The basic idea behind this toolkit is to separate UI implementation from the source code. This idea comes from the beautiful Java toolkit SWIXML which was implemented for allowing separation on UI from business logic in Swing based applications. This toolkit is also implemented in Android SDK core for same reason and is much more used then hard coded UI. The concept mutates to new programming paradigm which is also known as declarative programming where we specify UI and we regardless of how it will be created we just want initialized elements to manipulate with.

With using tool that allows us to make separation on UI from the business logic we will have cleaner code which is much better for reading and maintaining than putting everything into the class.

In iOS you can make UI with setting all properties into the code for every view that we use or by using Interface Builder which generate some messy XML structure that is understood only by the Interface Builder itself, but in this case because everything is auto generated we can’t change anything into this XML. Application that is implemented with using Interface Builder has also slower compile time than the application that has UI implementation into the view controllers. For that reason toolkit that separate UI from the code and keeps the UI definition as simple XML file instead of complicated XIB is welcome.

iOS Runtime UI Builder parse the XML UI definition with using the fastest XML DOM parser TBXML, creates object structure for every XML Tag with its attributes and keeps that objects in memory which is very fast because we don’t depend on complicated XIBs that are also slower to parse then simple XML file. After parsing and creating object structure, for every encapsulated view we automatically make initialization on each view with setting attributes which were defined in the XML Tags. The objects that encapsulate the views are stored into the fast data structure allowing us fast lookup for the concrete object and set initialized view to the reference into the code. With using this toolkit we make the code cleaner because every property is automatically set with changing complicated methods with only several written attributes into the XML Tags for every view that we create in main view. If we have complex views with many wrapped views inside them it’s not a problem, all that views will be automatically add into the parent view which gives us freedom to experiment with different UI concepts easily.

Check it on Google Code

https://code.google.com/p/ios-ui-runtime-builder/