Wednesday, August 20, 2014

Design Patterns in Cocoa - How Much You Know ??

         In continuation to the articles on most frequently asked questions in an interview, I add another here which can be the most expected one to be asked. If you happen to fortunately survive any technical interview past 30-40 mins, you may notice that the topics on which the questions asked thereafter becomes generic and will be more of analogous in answers. Its the time for you to bring your understanding to wire and show your sense of application to your learnings to the problem on hand. So when the process of designing a solution to any software problem begins, thats when the understanding of Design Patterns do rise. "Any solution you design to solve a problem on hand is a Design Pattern" off course. Its quite obvious that the kind of design being adapted would be based on the kind of the problem to be solved.                   

        Cocoa architecture in itself has many Design Patterns implemented in any iOS project you create. So when you create an iOS project even beyond you knowing, there are many Design Patterns at work, making your life of application development easier. If so, lets know what are those design patterns implemented by Cocoa which you will have used for sure as an iOS developer, but may not be aware of.                  

        The first set of files which you start looking at in any iOS project is AppDelegate. This file has the methods needed to write in the logic for different states of app functioning like Foreground state, Background state, resigning active, becoming active etc. These things are quite evident and understandable, thanks to Apple standard of verbose naming convention of functions. But were you aware that AppDelegate is an example of "Singleton Pattern" of designing solution ? You might have noticed the practice of storing API Keys, Session Variables and other tokens in AppDelegate. But have you ever questioned why ? AppDelegate is a Single Shared instance that you access throughout the classes in your application and you dont ever do a "alloc" on it but rather use [UIApplication sharedApplication] which fetches back the shared singleton instance of reference. A single object created is shared throughout and is therefore called as Singleton Pattern.                

          Having started with AppDelegate and realising how Singleton Design pattern is in play with it, lets explore some other design patterns which come within. In the same AppDelegate class have you noticed that your class subclasses UIResponder  and implements a delegate by the name  <UIApplicationDelegate>. Take your time and explore UIApplicationDelegate and you will get to know that all the methods you have implemented in AppDelegate are prototyped in <UIApplicationDelegate>. This is called as "Delegation Pattern". A class delegating the responsibilities of it to a different one and make that delegate to conform back to it on task completion is called as Delegation. Where do you most get to see delegation and why ? What exactly is delegation ? In the MVC approach, a controller interacts with its view using delegation. A delegate always has a 1:1 relation with its view controller. But why does a delegate enforce 1:1 relation ? And if so why should delegation be used between a controller and a view ? A delegate appointed is always expected to report back to his master class and not others. A view element can always be tagged to a controller to drive it and cannot be shared by multiple controllers. For Ex : Screen A can always be tagged to Controller A and cannot be shared by Controller A and Controller B. This therefore enforces 1:1 relationship between a view and a controller and therefore they interact using delegation pattern.  Other popular examples of delegation pattern are UITableViewDelegate, UITableViewDataSource, UIAlertViewDelegate, UItextFieldDelegate, UIScrollViewDelegate etc.

      Most of you might be knowing that Objective C is a dynamic language. All it means is that the memory operations do happen at run time and the type of object and function linking is deferred to run time and doesnt happen at compile time. Now coming back to memory a bit, how do we allocate a block of memory for any object in objective c ? Its quite well know that all of us do use alloc method. Isnt it ? But do we know where is this method defined ? Do we know how does this method become available even with our custom classes without we doing anything ? Do we know how this method is internally implemented ? Ooopss.. Lets stop questions for a while here and start answering them. alloc is called as a factory method and is an example of "Factory Design Pattern". alloc is defined as a part of the NSObject class which is the root class of all objective c classes.  Most of the classes in objective C act as interfaces for a cluster of classes which sub-class the interface and are called as "Class Clusters". When alloc is called on any class, NSObject acts as a factory which manufactures an object and returns a reference to it using a suitable subclass of it from class cluster. In reference to this, most of you might have seen that when working with NSArray your program might crash giving an error with __NSArrayI or __NSArrayM. Have you ever given a thought as why did your program crash or did give error with these classes as references whereas you used NSArray ? Now go back few lines and relate it to the explanation there. NSArray is a public superclass of a cluster of classes which include __NSArrayI or __NSArrayM. NSArray just acts as a factory which returns the object reference when called upon alloc with it, hiding the implementation details underneath. When will __NSArrayI be used or when will __NSArrayM be used will be discussed in a different post "Class Clustering". So do you now realise how frequently and efficiently has Factory Design Pattern been used in all the frameworks of iOS and you also had used it in all your programs but you never knew about it ??!!

      
        In most of the cases we might have used notification centres to broadcast a notification using the default centre and thereby inform all the observers of a particular change. As soon as the word broadcast strikes your mind, it should even strike you that this follows 1:n relationship and not 1:1 unlike delegates which we saw a few paragraphs above. If so, lets see of what significance can these be and how better can we use them in our coding. Whenever an object wants to broadcast a message to all other objects in the eco-system which are interested in it, then it broadcasts a notification. All the objects which are interested in listening to this notification will register themselves as an observer to these changes. Lets see it in action. Now lets assume that a row of an employee table was being deleted and this has to be notified to n classes which have to perform actions accordingly. All these classes which are supposed to act onto the deletion that happens on employee table record register themselves as observers to the "delete" event happening on employee table object. Now as and when the deletion happens and the table object broadcasts a deletion notification using the notification center all these classes perform associated actions. This is called as "Observer Design Pattern". Most of you might have used this for keyboard appearing notification on beginning to edit a text field so as to adjust your layout. As we did see that a controller coordinates with the view using delegation pattern, a modal coordinates with controller using observer pattern. A modal which might be a table in the database might be used across multiple controllers unlike views which were tagged to a controller. Therefore modals will have to signal a change on them to all the controllers which they are associated with and thereby Observer Design Pattern comes in handy.

          Whenever you try to add a new class to Xcode project you are forced to select a superclass of that which has to be either a View or a Controller or a Modal(NSObject). Do You know by default you are following "MVC Design Pattern" here ? Now lets quickly see what MVC pattern is and why it is the most emphasised of all for designing the architecture of the project. Modal - An object in which the data resides V - A view element to represent the data residing in the Modal object C - Driver which maps elements of V with M. This is as simple as it is. Properly structuring an application to have easy mapping and storage of data on to the view is all about MVC.Now lets see how does this help. When we have a proper MVC architecture followed we thereby ensure that no data(Modal) is tightly coupled with a View and hence the same data object can be used across views. For example : Lets assume the details of an employee are to be shown in 2 different screens in a different layout. If we follow MVC, we ensure that employee data object is nowhere tightly coupled with any of the two screens which need to render it in a layout of their own and thereby we can reuse the same object in both the screens. Both the screens will have their own controllers to interact with the same employee modal object to coordinate with. This thereby ensures re-usability, better modularisation and as the objects are loosely coupled, changes such as adding a field to the table ot removing a field from the table does not demand significant rework. 


         These are some of the Design Patterns which are quite extensively used in Objective C and the list keeps growing for the enthusiasts. Any problem at hand can be easily solved by understanding how the solution can be approached using a design pattern. The best part is that all these design patterns can be blended with each other, each one implemented for a feature that best suits them and thereby architecture the design of application in a much easier way. Now I guess you are proud to have used so many Design Patterns in every application of yours in Objective C even though you never might have designed them on your own :) 






Wednesday, June 11, 2014

CoreData - Do you see a snag ?

I some how have got to hear this in multiple forums at multiple stages. Especially in interviews where it generally starts with "How comfortable are you with Core Data ?" and ends with "Aware of any draw backs with Core Data ?".

So, here I write up a small article to build up the repertoire of those who are gearing up for a switch and are apprehensive of the interviews and the other set of people who had to sit blank when this was hurled at them in their interviews and could not help other than ducking this question and googling the same.

   The one word answer to this, the word that you can emphasize and stress on to save you is "In - Memory". You can get away easily with a single statement "Core Data is In - Memory". Now if you want to proceed with this to further strengthen your explanation and convince the interviewer, below is the explanation for you with a case considered.

Use - Case

Lets consider the case of a collage making app. The maximum images that can be allowed per collage be 8-10. Since the maximum number of images being used is already a limit imposed lets not limit the size of image.

The app is expected to support both online and offline mode. Offline mode should let the user see the collages he has created already though creating new collage may be restricted to online mode.

If the user has created a collage of 8 images each of which is around 3-4 MB lets consider. To support offline viewing of the collage thereby created we need to store these images in our app somewhere. Now the question arises as where do I store it and how ? As Core Data is the topic in discussion, lets consider we use Core - Data.

How heavy the operation would be for your persistent coordinator to fetch these images from Core Data and render them in you image views of the collage ?

Would not the App crash in a compact environment giving a memory exception ?
This is where you have to start counting on other ways of storing data for offline rendering.

If not Core - Dat what would be the other option to this case ?

Yes. NSDocumentsDirectory would fit in the need. Having your images stored in NSDocuments Directory would provide you the way to accomplish the offline functioning.


        As expected the other best answer which every iOS developer comes up with would be Thread Safety. Core Data managed object context not being Thread safe is one highlighting point for every developer scratching their heads and cursing Core - Data at times when complex threaded DB operations are to be performed. But before pointing at this, is any other framework in Cocoa Thread safe ? So is it justified to highlight managed object context not being thread safe as a snag of Core -Data just because resolving conflicts with Core-Data is a bit cumbersome when compared to other frameworks. I will some day post an article on Core Data - Thread Safety too.

 Cheers !!


"Open In" for sharing in iOS Apps

Hi,
Most of the iOS App developers may be wondering as why the most used and loved feature in Android "Open with" is not available in iOS. The reason for this being the way an application is structured in iOS. Files are encapsulated in an application environment called as Sand Box. So a file "F" downloaded using an app "A" belongs to "A" sandbox and hence is not visible to other apps on the iDevice. So lets consider a scenario where I have downloaded a RTF text file and I wanted to open it Evernote or any other app in my iDevice as developing my own file reader might not be an option always. How to accomplish this ? Have you noticed that DropBox does provide an option "Open In" to open any file in dropbox with other apps installed on the iDevice to do the same ?
UIDocumetInteractionController is the solution to this. I was developing an application where in I ran into similar situation and initially was deceived by UIActivityController to do the same. After pulling my hairs for couple of hours I did notice that  UIDocumetInteractionController is the solution to this and not UIActivityController. So below is the code as how to do this using a UIDocumetInteractionController.


// Declare a document interaction controller property

@property (retainUIDocumentInteractionController *docController;

NSURL *URL = [NSURL fileURLWithPath:filePath];
    
if (URL) {

        // Initialize Document Interaction Controller
        self.docController = [UIDocumentInteractionController interactionControllerWithURL:URL];

        // Configure Document Interaction Controller
        [self.docController setDelegate:self];

        // Present Open In Menu
       [self.docControllerpresentOpenInMenuFromRect:self.view.frame 
inView:self.view animated:YES];
    }

When this piece of code is executed the resulting output would be something as below based on the apps that are compatible to open the file installed on your iDevice.