Tag: swift

✍️ Note

What is Core Animation

Core Animation use bitmaps.

• UIView -> Layer -> Bitmap -> Hardware manipulation

Core Animation provides a general purpose system for animating views and other visual elements of your app. Core Animation is not a replacement for your app’s views. Instead, it is a technology that integrates with views to provide better performance and support for animating their content. It achieves this behavior by caching the contents of views into bitmaps that can be manipulated directly by the graphics hardware. In some cases, this caching behavior might require you to rethink how you present and manage your app’s content, but most of the time you use Core Animation without ever knowing it is there. In addition to caching view content, Core Animation also defines a way to specify arbitrary visual content, integrate that content with your views, and animate it along with everything else.

You use Core Animation to animate changes to your app’s views and visual objects. Most changes relate to modifying the properties of your visual objects. For example, you might use Core Animation to animate changes to a view’s position, size, or opacity. When you make such a change, Core Animation animates between the current value of the property and the new value you specify. You would typically not use Core Animation to replace the content of a view 60 times a second, such as in a cartoon. Instead, you use Core Animation to move a view’s content around the screen, fade that content in or out, apply arbitrary graphics transformations to the view, or change the view’s other visual attributes.

Apple Document

Layers Provide the Basis for Drawing and Animations

Layer objects are 2D surfaces organized in a 3D space and are at the heart of everything you do with Core Animation. Like views, layers manage information about the geometry, content, and visual attributes of their surfaces. Unlike views, layers do not define their own appearance. A layer merely manages the state information surrounding a bitmap. The bitmap itself can be the result of a view drawing itself or a fixed image that you specify. For this reason, the main layers you use in your app are considered to be model objects because they primarily manage data. This notion is important to remember because it affects the behavior of animations.

Apple Document

Most layers do not do any actual drawing in your app. Instead, a layer captures the content your app provides and caches it in a bitmap, which is sometimes referred to as the backing store. When you subsequently change a property of the layer, all you are doing is changing the state information associated with the layer object. When a change triggers an animation, Core Animation passes the layer’s bitmap and state information to the graphics hardware, which does the work of rendering the bitmap using the new information, as shown in Figure 1-1. Manipulating the bitmap in hardware yields much faster animations than could be done in software.

Because it manipulates a static bitmap, layer-based drawing differs significantly from more traditional view-based drawing techniques. With view-based drawing, changes to the view itself often result in a call to the view’s drawRect: method to redraw content using the new parameters. But drawing in this way is expensive because it is done using the CPU on the main thread. Core Animation avoids this expense by whenever possible by manipulating the cached bitmap in hardware to achieve the same or similar effects.

Although Core Animation uses cached content as much as possible, your app must still provide the initial content and update it from time to time. There are several ways for your app to provide a layer object with content, which are described in detail in Providing a Layer’s Contents.

Apple Document

Rendering Process

Layers Can Be Manipulated in Three Dimensions

Every layer has two transform matrices that you can use to manipulate the layer and its contents. The transform property of CALayer specifies the transforms that you want to apply both to the layer and its embedded sublayers. Normally you use this property when you want to modify the layer itself. For example, you might use that property to scale or rotate the layer or change its position temporarily. The sublayerTransform property defines additional transformations that apply only to the sublayers and is used most commonly to add a perspective visual effect to the contents of a scene.

Transforms work by multiplying coordinate values through a matrix of numbers to get new coordinates that represent the transformed versions of the original points. Because Core Animation values can be specified in three dimensions, each coordinate point has four values that must be multiplied through a four-by-four matrix, as shown in Figure 1-7. In Core Animation, the transform in the figure is represented by the CATransform3D type. Fortunately, you do not have to modify the fields of this structure directly to perform standard transformations. Core Animation provides a comprehensive set of functions for creating scale, translation, and rotation matrices and for doing matrix comparisons. In addition to manipulating transforms using functions, Core Animation extends key-value coding support to allow you to modify a transform using key paths. For a list of key paths you can modify, see CATransform3D Key Paths.

Figure 1-8 shows the matrix configurations for some of the more common transformations you can make. Multiplying any coordinate by the identity transform returns the exact same coordinate. For other transformations, how the coordinate is modified depends entirely on which matrix components you change. For example, to translate along the x-axis only, you would supply a nonzero value for the tx component of the translation matrix and leave the ty and tz values to 0. For rotations, you would provide the appropriate sine and cosine values of the target rotation angle.

Apple

Layer Tree

An app using Core Animation has three sets of layer objects. Each set of layer objects has a different role in making the content of your app appear onscreen:

• Objects in the model layer tree (or simply “layer tree”) are the ones your app interacts with the most. The objects in this tree are the model objects that store the target values for any animations. Whenever you change the property of a layer, you use one of these objects.
• Objects in the presentation tree contain the in-flight values for any running animations. Whereas the layer tree objects contain the target values for an animation, the objects in the presentation tree reflect the current values as they appear onscreen. You should never modify the objects in this tree. Instead, you use these objects to read current animation values, perhaps to create a new animation starting at those values.
• Objects in the render tree perform the actual animations and are private to Core Animation.

Each set of layer objects is organized into a hierarchical structure like the views in your app. In fact, for an app that enables layers for all of its views, the initial structure of each tree matches the structure of the view hierarchy exactly. However, an app can add additional layer objects—that is, layers not associated with a view—into the layer hierarchy as needed. You might do this in situations to optimize your app’s performance for content that does not require all the overhead of a view. Figure 1-9 shows the breakdown of layers found in a simple iOS app. The window in the example contains a content view, which itself contains a button view and two standalone layer objects. Each view has a corresponding layer object that forms part of the layer hierarchy.

Apple

For every object in the layer tree, there is a matching object in the presentation and render trees, as shown in Figure 1-10. As was previously mentioned, apps primarily work with objects in the layer tree but may at times access objects in the presentation tree. Specifically, accessing the presentationLayer property of an object in the layer tree returns the corresponding object in the presentation tree. You might want to access that object to read the current value of a property that is in the middle of an animation.

Important: You should access objects in the presentation tree only while an animation is in flight. While an animation is in progress, the presentation tree contains the layer values as they appear onscreen at that instant. This behavior differs from the layer tree, which always reflects the last value set by your code and is equivalent to the final state of the animation.

Apple

The Relationship Between Layers and Views

Layers are not a replacement for your app’s views—that is, you cannot create a visual interface based solely on layer objects. Layers provide infrastructure for your views. Specifically, layers make it easier and more efficient to draw and animate the contents of views and maintain high frame rates while doing so. However, there are many things that layers do not do. Layers do not handle events, draw content, participate in the responder chain, or do many other things. For this reason, every app must still have one or more views to handle those kinds of interactions.

In iOS, every view is backed by a corresponding layer object but in OS X you must decide which views should have layers. In OS X v10.8 and later, it probably makes sense to add layers to all of your views. However, you are not required to do so and can still disable layers in cases where the overhead is unwarranted and unneeded. Layers do increase your app’s memory overhead somewhat but their benefits often outweigh the disadvantage, so it is always best to test the performance of your app before disabling layer support.

When you enable layer support for a view, you create what is referred to as a layer-backed view. In a layer-backed view, the system is responsible for creating the underlying layer object and for keeping that layer in sync with the view. All iOS views are layer-backed and most views in OS X are as well. However, in OS X, you can also create a layer-hosting view, which is a view where you supply the layer object yourself. For a layer-hosting view, AppKit takes a hands off approach with managing the layer and does not modify it in response to view changes.

Note: For layer-backed views, it is recommended that you manipulate the view, rather than its layer, whenever possible. In iOS, views are just a thin wrapper around layer objects, so any manipulations you make to the layer usually work just fine. But there are cases in both iOS and OS X where manipulating the layer instead of the view might not yield the desired results. Wherever possible, this document points out those pitfalls and tries to provide ways to help you work around them.

In addition to the layers associated with your views, you can also create layer objects that do not have a corresponding view. You can embed these standalone layer objects inside of any other layer object in your app, including those that are associated with a view. You typically use standalone layer objects as part of a specific optimization path. For example, if you wanted to use the same image in multiple places, you could load the image once and associate it with multiple standalone layer objects and add those objects to the layer tree. Each layer then refers to the source image rather than trying to create its own copy of that image in memory.

For information about how to enable layer support for your app’s views, see Enabling Core Animation Support in Your App. For information on how to create a layer object hierarchy, and for tips on when you might do so, see Building a Layer Hierarchy.

Apple

If you learn more about Core Animation? Visit official document

✍️ Note

Some codes and contents are sourced from Udemy. This post is for personal notes where I summarize the original contents to grasp the key concepts (🎨 some images I draw it)

Bit Manipulations

There are 6 types of bit manipulations

• OR
  • 1 | 0 -> 1
  • 1 | 1 -> 1
  • 0 | 0 -> 0
• And
  • 1 & 0 -> 0
  • 1 & 1 -> 1
  • 0 & 0 -> 0
• XOR (if there is only 1 then It’s result will be 1)
  • 1 ^ 0 -> 1
  • 1 ^ 1 -> 0
  • 0 ^ 0 -> 0
• Not
  • ~1 -> 0
  • ~0 -> 1
• Left Shift
  • 1 << 1 -> 0000 0010
• Right Shift (See Apple’s document)
  • 1 >> 1 -> 000 0000

If you want to learn more details, visit Apple official documents

Example 1. Find if the N-th bit of a byte is 1

To check N-th bit, use checkBit.

func is1Bit(number: Int, at: Int) -> Bool {
    var checkBit = 1
    checkBit <<= at
    var result = number & checkBit
    return result == checkBit
    
}
let number = 789
String(number, radix: 2)

//index 0, 2, 4, 8, 9 bit is 1
is1Bit(number: number, at: 0)
is1Bit(number: number, at: 2)
is1Bit(number: number, at: 4)
is1Bit(number: number, at: 8)
is1Bit(number: number, at: 9)

//index 1, bit is 0
is1Bit(number: number, at: 1)

Example 2. Set N-th bit as 1

var number = 789
func set1Bit(number: inout Int, at: Int) {
    var checkBit = 1
    checkBit <<= at
    String(number, radix: 2)
    String(checkBit, radix: 2)
    number |= checkBit
    String(number, radix: 2)
}
print("Before: \(number)")
set1Bit(number: &number, at: 1)
print("After: \(number)")

Set N-th bit as 1 is very easy.

• Create checkBit
• Apply OR bit operation to the number

Input number is 789

When you set bit 1 at index 1, the result will be +2

Example 3. Print and count 1’s bits

In Swift, There is convenient API to print binary from Int

• String(789, radix: 2)

Alternative way, we can print all the bit information from right to left using checkBit

func printBitsAndReturn1sBits(_ number: UInt) -> Int {
    var input = number
    //Use unsinged Int, because signed int hold right most bit as signed information
    var checkBit: UInt = 1
    //MemoryLayout returns byte size of Int. It depends on architecture. 4 byte(32 bit) or 8 byte (64 bit)
    //To get bits we need to multiply 8 and -1 (because index starts from 0)
    let bits = MemoryLayout<UInt>.size * 8 - 1
    checkBit <<= bits
    
    var count = 0
    while checkBit != 0 {
        let rightBit = number & checkBit
        if rightBit == checkBit {
            print("1", terminator: " ")
            count += 1
        }
        else {
            print("0", terminator: " ")
        }
        //Right shift
        checkBit >>= 1
    }
    return count
}
printBitsAndReturn1sBits(789)

Above approach, The time complexity is O(Number of Bit)

We can optimize it by using subtract by 1. It’s time complexity will be O(number of 1’s) -> Assume we ignore print all the bit information. Just focusing on get 1’s count.

func get1sBits(_ number: UInt) -> Int {
    var input = number
    var count = 0
    while input != 0 {
        input &= (input - 1)
        count += 1
    }
    return count
}
get1sBits(789)

Example 4. Reverse the bits an Integer

func reversedBit(_ number: UInt) -> UInt {
    var number = number
    print("Input: \(number), Bits: \(String(number, radix: 2))")
    var reversedNumber: UInt = 0
    //Count: Get count of bit of the number, 789 has 10 bit
    var count = String(number, radix: 2).count - 1
    while number != 0 {
        let leftMostBit = number & 1
        reversedNumber = reversedNumber | leftMostBit
        reversedNumber <<= 1
        number >>= 1
        count -= 1
    }
    reversedNumber <<= count
    return reversedNumber
}

let result = reversedBit(789)
print("Ourput: \(result), Bits: \(String(result, radix: 2))")

Did you know Apple provides Sample Code? I learned App Architecture from Apple’s Sample Projects.

In this post, I drew the high level diagram of the Apple’s Sample Code.

Check Apple’s Sample Code

Visit Apple Developer’s site and filter by Sample Code

https://developer.apple.com/documentation/uikit

Project 1. Restoring Your App’s State

https://developer.apple.com/documentation/uikit/uiscenedelegate/restoring_your_app_s_state

This sample project demonstrates how to preserve your appʼs state information and restore the app to that previous state on subsequent launches. During a subsequent launch, restoring your interface to the previous interaction point provides continuity for the user, and lets them finish active tasks quickly.

When using your app, the user performs actions that affect the user interface. For example, the user might view a specific page of information, and after the user leaves the app, the operating system might terminate it to free up the resources it holds. The user should be able to return to where they left off — and UI state restoration is a core part of making that experience seamless.

This sample app demonstrates the use of state preservation and restoration for scenarios where the system interrupts the app. The sample project manages a set of products. Each product has a title, an image, and other metadata you can view and edit. The project shows how to preserve and restore a product in its DetailParentViewController.

The sample supports two state preservation approaches. In iOS 13 and later, apps save the state for each window scene using NSUserActivity objects. In iOS 12 and earlier, apps preserve the state of their user interfaces by saving and restoring the configuration of view controllers.

For scene-based apps, UIKit asks each scene to save its state information using an NSUserActivity object. NSUserActivity is a core part of modern state restoration with UIScene and UISceneDelegate. In your own apps, you use the activity object to store information needed to recreate your scene’s interface and restore the content of that interface. If your app doesn’t support scenes, use the view-controller-based state restoration process to preserve the state of your interface instead.

By Apple

High Level System Design

It uses Singleton DataModelManager.

All the ViewControllers access singleton DataModelManager directly to get data.

The logics are focused on how to save and restore the states using UIStateRestoring.

🌟 Interesting points

• It has two scenes.
  • Main Scene
  • Image Scene
• AppDelegate handles where user navigate to the scene by checking NSUserActivity

Project Folder structures

Project 2. Supporting Multiple Windows on iPad

https://developer.apple.com/documentation/uikit/uiscenedelegate/supporting_multiple_windows_on_ipad

This project is very simple. Most of the functions are belong to ViewController.

Learned from this project

• UICollectionViewCell’s reuseIdentifier is declared in PhotoCell.
  • static reuseIdentifier
• Function names
  • initialize the UI codes -> func configure()
  • initialize the storyboard -> loadFromStoryboard()
• Class / Struct name
  • I found Apple’s sample codes usually naming the noun + manager for class / struct.
    • PhotoManager
• Conveniently use Static / Singletons
  • UserActivity has multiple static properties

Project 3. Supporting desktop-class features in your iPad app

https://developer.apple.com/documentation/uikit/app_and_environment/supporting_desktop-class_features_in_your_ipad_app

✍️ Note

Some codes are sourced from Loony Corn’s Udemy Course (https://www.udemy.com/user/janani-ravi-2/). This post is for personal notes where I summarize the original contents to grasp the key concepts

Graph – Shortest Path Algorithms

Given a graph G with vertices V and edges E

Choose any vertex S – the source

What is the shortest path from S to a specific destination vertex D?

It is the path with the fewest hops to get from S to D

https://www.udemy.com/course/from-0-to-1-data-structures/learn/lecture/8506692#content

• There can be multiple paths to the same vertex with different distances
• Getting the shortest path is very similar to BFS
• We need to set up something called a Distance Table
• A Table of all vertices in a Graph

Type 1. Unweighted Graph, Find Shortest Path using Distance Table

Type 2. Weighted Graph, Dijkstra Algorithm: Find Shortest Path

Unlike unweighted graph, each edges having a weight or number. Its value can be negative or positive.

Dijkstra Algorithm is used for positive weights.

Bellman-Ford is used for negative weights too.

The algorithm here is quite similar to what we have discussed before in finding the shortest path in an Unweighted Graph (see Type 1 example)

There are 3 major differences

• We still use the Distance Table to store information
  • The distance from a Node now has to account for the weight of the edges traversed
  • distance[neighbors] = distance[vertex] + weight_of_edge[vertex, neighbor]
• Each vertex has neighbors
  • In a weighted graph – visit the neighbour which is connected by an edge with the Lowest Weight
  • Use a priority queue to implement this
    • To get the next vertex in the path, pop the element with the Lowest Weight -> It is called Greedy Algorithm
    • What is a Greedy Algorithm?
      • Greedy algorithms often fail to find the best solution
      • A greedy algorithm builds up a solution step by step
      • A every step it only optimizes for that particular step – It does not look at the overall problem
      • They do not operate on all the data so they may not see the Big Picture
      • Greedy algorithms are used for optimization problems
      • Greedy solutions are especially useful to find approximate solutions to very hard problems which are close to impossible to solve (Technical term NP Hard) E.g, The Traveling Salesman Problem
  • It’s possible to visit a vertex more than once
    • We check whether new distance (via the alternative route) is smaller than old distance
    • new distance = distance[vertex] + weight of edge[vertex, neighbour]
      • If new distance < original distance [neighbour] then Update the distance table. Put the vertex in Queue (Once Again)
      • Relaxation

Finding the shortest path in a weighted graph is called Dijkstra’s Algorithm

Shortest Path in Weighted Graph

The algorithm’s efficiency depends on how priority queue is implemented. It’s two operations – Updating the queue and Popping out from the queue determines the running time

Running Time is : O(ELogV) <- If Binary Heaps are used for priority queue

Running time is : O(E + V*V) <- If array is used for priority queue

Sort algorithm in Swift Foundation is TimSort (Insertion Sort + Merge Sort)

I wrote posts about Insertion Sort and Merge Sort.

You can check How to implement sorting algorithm in Swift

You can check the full source code at here

https://github.com/apple/swift/blob/main/stdlib/public/core/Sort.swift

TimSort

Sorts the elements of this buffer according to areInIncreasingOrder,
using a stable, adaptive merge sort.
The adaptive algorithm used is Timsort, modified to perform a straight
merge of the elements using a temporary buffer.

https://github.com/apple/swift/blob/main/stdlib/public/core/Sort.swift

Timsort is a hybrid, stable sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data. It was implemented by Tim Peters in 2002 for use in the Python programming language. The algorithm finds subsequences of the data that are already ordered (runs) and uses them to sort the remainder more efficiently. This is done by merging runs until certain criteria are fulfilled. Timsort was Python’s standard sorting algorithm from version 2.3 to version 3.10,^[5] and is used to sort arrays of non-primitive type in Java SE 7,^[6] on the Android platform,^[7] in GNU Octave,^[8] on V8,^[9] Swift,^[10] and inspired the sorting algorithm used in Rust.^[11]

It uses techniques from Peter McIlroy’s 1993 paper “Optimistic Sorting and Information Theoretic Complexity”.

https://en.wikipedia.org/wiki/Timsort