Raw Notes: Cocoa Design Patterns

MVC (Model-View-Controller)
- Apples architectural pattern
- In general, design patterns are meant to be templets to better design your apple with scalability in mind. It also allows you to compartmentalize your app to reduce dependencies and have a robust application.
- Model – data and all its relevancy; persistence, model objects, parsers, managers, and network code
  - Network code
    - You want to have a single class that handles all aspects of networking such as HTTP requests, error-handling, etc.
  - Persistence code
    - Data that Is saved in a database like Firebase, core data (SQLlite), Realm.io,
  - Parsing code
    - Objects that parse network responses
    - i.e. JSON encoding/decoding objects
  - Managers and abstraction layers/classes:
    - Mini-APIs within your model layer that help communication between classes in your model, or serve as wrappers around more low-level API, or Data Stores such as HealthKit, or Firestore
  - Data source and delegates
    - Can be seen as data streams that you can provide to components within your controllers
    - i.e. data sources for your collection views or table views
  - Constants
    - Keeping your constants in a model layer wrapped around a class or model object is helpful for reusability throughout your application and easier to maintain, as there is a single source in which to change.
  - Helpers and extensions
    - This is where you would place any added functionality to data types such as strings, collections, etc.
- View- reusable containers that are presented the user on the user interface of the application
  - This layer is responsible for anything that your user interacts with or sees
  - Confused? Components that subclass from UIView, Core Graphics, Core animations
  - Classes that are part of UIKit/AppKit
  - This layer should not contain any networking, business logic, manipulating models, etc.
- Controller – the middleman between the view and the model.
  - This layer decides things like:
    - What should I access first: the persistence or the network?
    - Hoe often should I refresh the app.
    - What should the next screen be and in which circumstances
    - If the app goes to the background, what should I tidy up?
    - The user tapped on a cell what should I do next?
  - The controller can be seen as the engine or the brain of the app; it decides what to do next.
  - You probably won’t do much testing here as the controller is responsible for mitigating between the data and the model
Singleton
- A single static class that is used globally throughout your application.
- The singleton design pattern ensures that there is only once instance of the class. This is achieved by making the class private and creating a static instance of itself, that is said to be shared across your application.
- Ex, an API that allows to manipulate your applications data.
- Singletons have a bad rep for being misused by jr developers and senior developers.
Delegate
- The delegation design pattern simply allows you to pass the responsibility of a class to another class
- Think for example collection views. When you have a view controller that conforms to the collection views delegate, what is essentially happening, is your view controller is volunteering to fill in certain methods that the collection view requires to function, and for your view controller to ripe the benefits of the collection view.
- Apple –
  - Delegation is a simple and powerful pattern in which one object in a program acts on behalf of, or in coordination with, another object. The delegating object keeps a reference to the other object-the delegate-and at the appropriate time sends a message to it. The message informs the delegate of an event that the delegating object is about to handle or has just handled. The delegate may respond to the message by updating the appearance or state of itself or other objects in the application, and in some cases, it can return a value that affects how an impending event is handled. The main value of delegation Is that it allows you to easily customize the behavior of several objects in once central object.
  - The programming mechanism of delegation gives objects a chance to coordinate their appearance and state with changes occurring elsewhere in a program, changes usually brought about by user actions. More importantly, delegation makes it possible for one object to alter the behavior of another object without the need to inherit from it. The delegate is almost always one of your custom objects, and by definition it incorporates application – specific logic that the generic and delegate object cannot possibly know itself.
Responder Chain
- UIKit handles the responder chain by dynamically managing a linked list of UIResponders. The first responder is simply the root element of the list, and if a responder cannot handle a specific action/event, the action is recuresivly sent to the next responder of the list unitl someone can handle the action or the list ends
- You can customize the responder chain to change its flow.
  - You can force a UIResponder to become the first responder by calling becomeFirstResponder() and have it go back to its position by calling resignFirstResponder().
- Apps receive and handle events using responder objects.
- A responder object is any instance of the UIReponder class.
  - What objects subclass the UIResponder?
    - UIView, UIViewController, and UIApplication
  - How do you manager event, actions, and reponders?
    - UIKit manages most responder-related behavior automatically, including how events are delivered form one responder to the next.
- The responder chain is managed by the UIApplication singleton. It queues the events and appropriately sends them to one of the receivers mentioned below
- UIControl Actions
  - Actions that are registered using the action/target pattern
  - For example, when you addTagert a UIButton or resignFirstResponder
- User Events
  - Represents a single UIKit event that contains a type (touch, motion, remte-control and press)
  - Touches, shakes, motion, etc.
  - Example: When the button is tapped, the system detects the action, and goes along the responder chain until it finds a valid responder to the action. If a responder is not found, then the event is dropped.
  - Ex: the hitTes:withEvent: method of UIView walks the view hierarchy, looking for the deepest sub view that contains the specified touch. That view becomes the first responder for the touch event.
  - If the view is the root view of a view controller, the next responder is the view controller
  - If the view is not the root view of a view controller, the next responder is the view’s super view
  - If the view controller’s view is the root view of a window, the next responder is the window object
  - If the view controller was presented by another view controller, the next responder is the presenting view controller
  - UIWindow: The window’s responder is the application object
  - UIApplication: The app object’s next responder is the app delegate, but only if the app delegate is an instance of UIResponder and is not a view, view controller, or the app object itself.
  - How do you differ between different types of touches?
    - UIControl, subclasses of UIView, abstract the process of handling touch events and expose the ability to assign actions touch events.
  - When no target is specififed, UIkit will search for an UIResponder capable of handling the action.
- System Events
  - Low memory, rotation, etc.
  - System related events are received by UIApplication and are sent to the app delegate, the appe delegate then handles the events
  - In order to handle system events, UIResponder subclasses can register themselves as capable of handling specific UIEvent types by overrideing the methods specific to that type.
- The first responder
  - For every event, UIKit designates a first responder and sends the event to that object first
  - The first responder is given the opportunity to handle user actions
  - On the other hand, touch events will not be sent to the first responder, the events are sent to the view found by doing a recursive hit-test.

Event type first responder

Touch events the view in which the touch occurred

Press events the object that has focus

Shake-motion events the object that you (or UIKit) designated

Remote-control events the object that you (or UIKit) designated

Editing menu messages the object that you (or UIKit) designated

Apple
- Controls communicate directly with their associated target object using action messages. When the user interacts with a control, the controls sends an action message to its target object. Action messages are not events, but they may still take advantage of the responder chain. When the target object of a control is nil, UIKit starts from the target object and traverses the responder chain until it finds an object that implements the appropriate action method.
- Gesture recognizers receive touch and press events before their view does. If a view’s gesture recognizer fail to recognize a sequence of touches, UIKit sends the touches to the view. If the view does not handle the touches. UIKit passes them up the responder chain
Observer (Key-Value-Observers (KVO), Key Value Coding(KVC))
- Apple
  - Notify objects about changes to the properties of other objects
  - Key-value observing in Cocoa programming pattern you use to identify objects about changes to properties of other objects. It is useful for communicating changes between logically separated parts of your app – such as between models and view. You can only use key-value observing with classes that inherit from NSObject
- KVC
  - Allows you to access a class properties using strings instead of property accessors, or instance variables
  - What is a key and keypath?
    - Key: similar to a key in a dictionary, the name of the property we want to access or modify
    - Represents all the properties of an object, which comes in way until to reach the desired value/property
  - Subscribing
    - Observer: The object to register for KVO notifications. The observer must implement they key-value observing method observeValueForKeyPath:ofObject:chage:context:.
    - Keypath: They key path, relative to the receiver, of the property to observe. This value must no be nil.
    - Options: A combination of the NSKeyValueOptions values that specifies what is included in observation notifications. For possible values, see NSKeyValueObservingOptions
    - Context: arbitrary data that is passed to observer ValueForKeyPath:ofObject:change:context
  - Responding
    - There is no way to specify custom selectors to handle observations, as one might used to from the Target-Action pattern used by controls. Instead, all changes for observers are funneled through a single method.- observValueForKeyPath:ofObject:change:context.:
    - Better Key Paths
      - Passing strings as key paths is strictly worse than using properties directly, as any typo or misspelling won’t be caught by the compiler, and will cause to not work.
      - A clever workaround to this is to use NSStringFromSelector and a @selector literal value
  - Unsubscribing
    - When an observer is finished listening for changes on an object, it is expected to call – removeObserver:forKeyPath:context:. This will often either be called in -observeValueForKeyPath:ofObject:change:context, or -dealloc
    - If you make a call to -removeObserver:forKeyPath:context: when the object is not registered as an observer (whether because It was already unregistered or not registered in the first place), an exception is thrown. The kicker is that there is no built-in way to even check if an object is registered!