[TOC]

iOS App Lifecycle

Not Running: The app is not yet launched or has been terminated by the user or the system.
Inactive: The app is launched, but not yet running in the foreground. This is a transitional state, where the app may become active or go back to the "Not Running" state.
Active: The app is running in the foreground and receiving events, such as user input.
Background: The app is running in the background and still executing code, but is not currently visible to the user.
Suspended: The app is still in memory, but is no longer executing code. The system may purge the app from memory at any time to free up resources.
Terminated: The app has been terminated either by the user or the system.

Lifecycle Specifics

Launching from the background: If the app is in the "Background" state and the user taps its icon to launch it, the app will transition to the "Inactive" state briefly before becoming "Active". During this transition, the app may perform some setup tasks such as restoring its state.
Background fetch: Apps can register for background fetch, which allows the system to wake them up periodically to perform tasks such as downloading new data. When the app is woken up, it will transition to the "Background" state and can perform its tasks. If the task takes too long, the system may terminate the app.
Background tasks: Apps can request permission to perform background tasks such as playing music or recording location data. These tasks allow the app to continue running in the "Background" state and perform its tasks. If the app stops performing its task, the system may terminate it.
Memory pressure: If the system is running low on memory, it may terminate apps that are in the "Suspended" state to free up resources. If the app is terminated, it will need to be relaunched the next time the user wants to use it.
App extensions: App extensions such as Today widgets or Share extensions have their own lifecycle, which is separate from the main app. Developers need to be aware of the lifecycle of app extensions when designing them.
Background location updates: If an app requests permission to perform background location updates, it can continue to run in the "Background" state to provide location updates. However, the system may terminate the app if it detects that the app is using too much battery power.

UIKit key components

UIView is a fundamental building block of any iOS app's user interface. It is used to display content on the screen and manage user interaction. UIView provides a lot of flexibility for developers to create custom views and UI elements.

UIViewController manages the content of one screen of an iOS app. It is responsible for managing the view hierarchy, responding to user interaction, and coordinating data between the view and the app's data model.

UIWindow is a container for UIView and provides the main container for the app's user interface. The UIWindow object is automatically created by the system and is responsible for displaying the app's content on the device's screen.

UIView Dependencies

UIView is implemented using CALayer, which means that all views in iOS are "layer-backed". This provides a number of benefits, such as hardware-accelerated rendering, efficient compositing, and support for advanced animations and transitions.
UIResponder (provides the foundation for responding to user interaction)
CALayer is a low-level class that provides the underlying mechanism for rendering a view's content

UIResponder and Event System

All objects that handle user input and events, such as UIView and UIViewController, inherit from UIResponder. This allows them to respond to user input and interact with the event system.

In addition to touch events, UIResponder also handles other types of input and events, such as keyboard input and motion events. Subclasses can override the appropriate methods to handle these events and perform the necessary actions in response.

UIResponder also provides a set of responder chain methods that allow events to be passed up and down the responder chain. This allows events to be handled by the appropriate object, depending on the current state of the UI.

CALayer

CALayer provides the low-level rendering and compositing capabilities that are necessary for creating complex user interfaces. It is responsible for drawing the content of the view, as well as handling animations, transitions, and other visual effects.

Hardware-accelerated rendering: CALayer provides hardware-accelerated rendering, which means that graphics are rendered using the GPU rather than the CPU, resulting in faster and more efficient rendering.
Compositing: CALayer supports compositing, which means that multiple layers can be combined to create complex visual effects. This is used extensively in iOS user interfaces, such as when creating translucent or transparent views.
Animations: CALayer supports a wide range of animation and transition effects, including keyframe animations, spring animations, and implicit animations. This allows for rich and dynamic user interfaces that respond to user input.

Frame And Bounds

frame: A CGRect value that specifies the position and size of the view in its superview's coordinate space.
bounds: A CGRect value that specifies the position and size of the view in its own coordinate space.

Autolayout

Autolayout is a powerful feature of UIKit that allows developers to create responsive and adaptive user interfaces. It is a process of defining constraints between the views in a view hierarchy, which specifies how the views should be laid out on the screen.

The constraint system in iOS goes from parent to child views in the view hierarchy.

When you create constraints for a child view, you specify how that view should be positioned relative to its parent view or sibling views. The layout engine then calculates the position and size of the child view based on these constraints and the layout of its parent view.

In other words, the layout engine starts with the parent view and uses the constraints to determine the position and size of each child view. This process continues recursively down the view hierarchy until the layout of all views has been determined.

Autolayout process

The autolayout process involves several steps that are applied to the view hierarchy in order, from the root view down to the child views. The following are the steps involved in the autolayout process:

Create and configure the views: Before autolayout can be applied, the views must be created and configured with the appropriate constraints. This involves setting the view's properties, such as the size, position, and content, and defining the constraints that will determine the view's layout.
Prepare for layout: Before the layout is calculated, the views must be prepared for the layout process. This involves ensuring that the views are in a valid state and that any layout constraints that are not yet resolved are prepared for resolution.
Solve constraints: The next step is to solve the constraints that are defined between the views. This involves calculating the position and size of each view based on the constraints that are defined, and ensuring that the constraints are satisfied. If the constraints cannot be resolved, the layout engine will raise an error.
Lay out subviews: After the constraints are resolved, the layout engine will lay out the subviews of each view in the hierarchy. This involves calculating the position and size of each subview, based on the constraints that are defined between the subview and its parent view.
Adjust the layout: Once the subviews are laid out, the layout may need to be adjusted based on the content size of the views. This involves calculating the intrinsic content size of each view and adjusting the layout as necessary.
Update the view hierarchy: Once the layout is complete, the view hierarchy is updated to reflect the new layout. This involves updating the frame and bounds properties of each view, and redrawing the content of the views to match the new layout.

vladislav-yermakov/UIKit.md

Select an option

No results found