Introducing iOS Design Patterns in Swift

-
In the process of developing this app, you’ll become acquainted with the most common Cocoa design patterns:
  • Creational: Singleton.
  • Structural: MVC, Decorator, Adapter, Facade.
  • Behavioral: Observer, and, Memento

Model-View-Controller (MVC) is one of the building blocks of Cocoa and is undoubtedly the most-used design pattern of all. It classifies objects according to their general role in your application and encourages clean separation of code based on role.
The three roles are:
  • Model: The object that holds your application data and defines how to manipulate it. For example, in your application the Model is your Album class.
  • View: The objects that are in charge of the visual representation of the Model and the controls the user can interact with; basically, all the UIView-derived objects. In your application the View is represented by your AlbumView class.
  • Controller: The controller is the mediator that coordinates all the work. It accesses the data from the model and displays it with the views, listens to events and manipulates the data as necessary. Can you guess which class is your controller? That’s right: ViewController.
A good implementation of this design pattern in your application means that each object falls into one of these groups.
The communication between View to Model through Controller can be best described with the following diagram:
mvc0
The Model notifies the Controller of any data changes, and in turn, the Controller updates the data in the Views. The View can then notify the Controller of actions the user performed and the Controller will either update the Model if necessary or retrieve any requested data.

The Singleton Pattern

The Singleton design pattern ensures that only one instance exists for a given class and that there’s a global access point to that instance. It usually uses lazy loading to create the single instance when it’s needed the first time.
Note: Apple uses this approach a lot. For example: NSUserDefaults.standardUserDefaults(), UIApplication.sharedApplication(), UIScreen.mainScreen(), NSFileManager.defaultManager() all return a Singleton object.
You’re likely wondering why you care if there’s more than one instance of a class floating around. Code and memory is cheap, right?

How to Use the Singleton Pattern

Take a look at the diagram below:
singleton
The above image shows a Logger class with a single property (which is the single instance), and two methods: sharedInstance and init.
The first time a client asks for the sharedInstance, the instance property isn’t yet initialized, so you create a new instance of the class and return a reference to it.
The next time you call sharedInstance, instance is immediately returned without any initialization. This logic ensures that only one instance exists at one time.

There’s a lot going on in this short method:
  1. Create a class variable as a computed type property. The class variable, like class methods in Objective-C, is something you can call without having to instantiate the class LibraryAPI For more information about type properties please refer to Apple’s Swift documentation on
    properties
  2. Nested within the class variable is a struct called Singleton.
  3. Singleton wraps a static constant variable named instance. Declaring a property as static means this property only exists once. Also note that static properties in Swift are implicitly lazy, which means that Instance is not created until it’s needed. Also note that since this is a constant property, once this instance is created, it’s not going to create it a second time. This is the essence of the Singleton design pattern. The initializer is never called again once it has been instantiated.
  4. Returns the computed type property.

Comments

Post a Comment

Popular posts from this blog

iOS Architecture

-
Image
I am pretty sure that even a few experienced iOS developers would have a hard time defining the iOS SDK in one sentence. The acronym  SDK  stands for  Software Development Kit . The iOS SDK contains the tools and resources to develop native iOS applications, which means that the SDK enables developers to develop, install, run, and test applications in the simulator and on physical devices. The two driving forces powering native iOS applications are Swift (or Objective-C) and the native iOS system frameworks. In the previous articles, we explored the Swift programming language. In this article, I want to explore the frameworks that power native iOS applications. You now know what the iOS SDK is, but what makes an application qualify as a native iOS application? The simple answer is that an iOS application is an application that runs on an iOS device. That's only half the truth, though. What about web applications that run in Safari? An iOS application is a Cocoa application
Read more

Property vs Instance Variable (iVar) in Objective-c [Small Concept but Great Understanding..]

-
Do you use properties or instance variables to store something inside an object? Let’s understand what is better and when. I think the subject is much less arguable if it’s about getting/setting some data from outside the class (right, properties should be used). So in this post we will focus on private and protected class members. Does it matter? It might sound not that important – why can’t we just make a random decision and stick to it? Well, properties / ivars are something that is used all the time. I think it’s a good practice to sometimes pay attention to how we do common tasks. It’s natural, and it’s a good way to increase efficiency as well – even a slight improvement sums up to something quite significant within time.  Performance Obviously, using properties will cost you some CPU because additional methods get called. But this is so insignificant in 99.99% of the cases! And for the rest 0.01% – use ivars, but be aware that the improvement you get is almost nothin
Read more

setNeedsLayout vs layoutIfNeeded Explained

-
Let’s take a look at the difference between  setNeedsLayout  and  layoutIfNeeded . As part of the normal startup process,  UIApplication  in iOS starts the main run loop for an app, which runs on the main thread. The main run loop processes events (such as user touches) and handles updates to view-based interfaces. As events occur, such as touch, location updates, motion, and multimedia control, the run loop finds the appropriate handler for the events, calling appropriate methods, which call other methods, and so on. At some moment in time, all events will have been handled and control will return to the run loop. Let’s label this point where control is returned to the run loop as the  update cycle , since this is how Apple refers to it in some of their documentation. You could use other terminology to conceptualize it, such as a break in the action, the redraw cycle, or a free moment. While events are being processed and dispatched, and as changes to views are requested, they a
Read more