iOS Developer Mock Interview | Tech Round (Round-2)

Summary

本期视频是关于iOS开发技术面试的第二轮，主要探讨了iOS应用的不同状态、应用生命周期、状态保存与恢复、委托模式、Combine框架的使用、Swift中的结构体与类、以及并发处理等话题。还讨论了UIKit的事件处理机制、视图生命周期和SwiftUI中状态属性与绑定属性的区别。整个讨论内容丰富，为iOS开发者提供了宝贵的知识和见解。

Takeaways

• 📱 应用状态：应用有五种状态，包括未运行、不活跃、活跃、后台和挂起状态。
• 📱 应用生命周期：应用在进入后台一段时间后，可能会被系统终止，此时应用处于挂起状态。
• 📱 状态保存与恢复：为了在使用应用时保持用户状态，如阅读小说的页数，需要在应用进入后台时保存状态，并在返回前台时恢复。
• 📱 委托模式：iOS中常用的设计模式，用于在对象间建立通信和数据传递，通过协议定义委托方法。
• 📱 通知与闭包：除了委托模式，还可以使用通知和闭包作为替代方案，适用于不同的场景和需求。
• 📱 Combine框架：用于处理异步和事件驱动的代码，提供声明式的Swift API。
• 📱 发布者与订阅者：在Combine中，发布者负责发送值，订阅者负责接收值，可以处理复杂的数据流。
• 📱 值类型与引用类型：Swift中的结构体是值类型，传递时会被复制，保证数据不变性；类是引用类型，需要小心管理以避免数据不一致。
• 📱 线程安全：在多线程环境下，需要确保对共享资源的访问是线程安全的，可以使用串行队列等机制。
• 📱 UIKit事件处理：UIKit中的事件处理机制包括触摸事件的传递，从硬件触发到视图响应。
• 📱 SwiftUI：SwiftUI中的State和Binding属性用于不同场景，State用于同一视图内状态的维护，Binding用于父子视图间的数据传递和响应。

Q & A

iOS应用程序有哪些状态，以及它们分别在应用程序生命周期的哪个阶段发生？

iOS应用程序有五种状态：未运行状态（应用未启动或已被终止）、不活跃状态（应用在前台但不接收事件）、活跃状态（应用在前台并接收事件）、后台状态（应用在后台运行但不在前台，例如播放音乐或下载内容）、挂起状态（应用在后台但不执行代码）。

当用户在使用应用时接到电话，应用会处于什么状态？

当用户在使用应用时接到电话，应用会进入不活跃状态，因为虽然应用仍在前台，但暂时不接收事件。

操作系统是否可以自动结束后台应用，如果是，这通常是为了什么？

是的，操作系统可以终止后台应用，这通常是为了释放系统资源。

当操作系统决定终止挂起状态的应用时，应用的状态是什么？

当操作系统终止挂起状态的应用时，应用处于挂起状态。

在iOS开发中，如何确保应用在后台一段时间后重新进入前台时，用户能够回到之前的位置？

在应用进入后台时，应保存相关信息，如用户的当前页面。这可以通过将数据保存到文件、数据库或使用默认设置来实现。同时，监听应用进入后台的通知，执行保存代码。当用户将应用带回前台时，检查并恢复保存的状态数据。

Swift中结构体使用堆还是栈分配？

Swift中的结构体使用栈分配，这是因为它们是值类型，当赋值给新变量或作为函数参数传递时会被复制。

为什么使用结构体可以提高性能？

使用结构体可以提高性能，因为它们是栈分配的，与堆分配的类相比，涉及的开销较小，通常对于小型轻量数据类型更加高效。

为什么在需要维持状态的情况下使用类而不是结构体？

在需要维持状态的情况下使用类，因为类是引用类型，可以保持对象的状态在不同地方的一致性。此外，类支持继承，适合需要子类化的场景，如UI组件。

如何处理类导致的数据处理不一致问题？

处理类导致的数据处理不一致问题可以通过使用串行队列来确保对类的属性的访问是同步和序列化的，或者使用其他同步机制，如操作队列、闭包等。

在UIKit中，视图的生命周期是怎样的？

视图的生命周期包括初始化（使用coder或frame）、布局子视图（layoutSubviews）、添加到窗口（didMoveToWindow）、视图更新（setNeedsLayout和setNeedsDisplay）。

UIKit中setNeedsLayout和setNeedsDisplay方法有什么区别？

setNeedsLayout方法用于标记视图的布局为无效并需要更新，触发布局更新。setNeedsDisplay方法用于标记视图的内容需要重绘，触发视图的绘制方法。

在SwiftUI中，状态属性和绑定属性有什么区别？

状态属性用于在同一视图中维护状态，提供双向数据绑定。绑定属性用于将数据传递给其他视图，并期望从子视图反映回父视图的变化，实现父子关系的双向绑定。

Outlines

00:00

📝 技术面试经验分享

本段落介绍了一个iOS技术面试经验分享系列视频的第二轮，重点讨论iOS开发相关的技术问题。面试者首先被问及iOS应用的不同状态及其在应用生命周期中出现的时间。接着讨论了当电话来电时应用的状态变化，以及操作系统可能在后台自动结束应用的情况。此外，还探讨了如何在应用进入后台时保存状态信息，以确保用户在重新打开应用时能够回到之前的阅读位置。

05:02

🔧 iOS委托模式和替代方案

这一段深入探讨了iOS中的委托模式，包括其工作原理和何时使用。委托模式是一种设计模式，用于在对象之间建立通信和数据传递。讨论了使用协议来实现委托模式，并比较了委托、通知和闭包等替代方案。还讨论了结合框架的使用，以及如何处理异步和事件驱动的代码。最后，面试者分享了他们在使用Combine框架时遇到的一些挑战。

10:03

🏗️ Swift结构体和类的应用

本段落讨论了Swift中结构体和类的不同用途。结构体是值类型，适合用于小型、轻量级的数据类型，因为它们在赋值或作为函数参数传递时会被复制，从而确保数据不变性。类则是引用类型，适合用于需要继承或与Objective-C组件交互的场景。讨论了使用类可能导致的数据不一致性问题，以及如何通过使用串行队列来解决并发读写操作导致的问题。

15:03

🔄 处理并发和数据不一致性

在这一段中，讨论了如何处理类可能导致的数据不一致性问题。提出了使用串行队列来同步对共享资源的访问，确保并发读写操作不会同时发生，从而避免数据不一致性。通过修改代码示例，展示了如何使用串行队列来安全地更新和读取资源。此外，还讨论了其他可能的解决方案，如使用Grand Central Dispatch（GCD）和操作队列。

20:05

📚 Swift UI和事件处理

本段落转向对Swift UI的讨论，特别是状态属性和绑定属性的区别。状态属性用于在同一视图内维护状态，而绑定属性用于在视图之间传递数据，并确保子视图的更改能够反映回父视图。此外，还探讨了UIView的生命周期，包括初始化、布局、绘制和事件处理。最后，讨论了如何通过自定义hit测试来改变触摸事件的处理方式。

25:06

🎥 总结与展望

这是视频脚本的最后一段，总结了整个技术面试经验分享的第二轮，并预告了下一轮将专注于系统设计。鼓励观众订阅频道以获取后续内容，并感谢观众的参与和支持。

Keywords

💡iOS开发

iOS开发是指针对苹果公司的移动操作系统iOS进行应用程序的设计、编码和测试。在视频中，提到iOS开发是为了引出面试者需要掌握的技术知识点，以及面试过程中可能会讨论到的相关概念。

💡应用状态

应用状态指的是一个iOS应用程序在其生命周期中可能处于的不同阶段，例如未运行、后台运行、前台运行等。了解这些状态对于开发者来说至关重要，因为它们影响应用程序如何响应用户交互和系统事件。

💡生命周期

生命周期是指一个对象或组件从创建到销毁的整个过程。在iOS开发中，理解视图或应用程序的生命周期对于管理内存、保存和恢复状态、以及确保应用程序响应用户操作至关重要。

💡委托模式

委托模式是一种设计模式，它允许一个对象将某些任务或职责委托给另一个对象。在iOS中，委托模式常用于建立对象之间的通信和数据传递，如视图控制器和它的委托之间的交互。

💡Combine框架

Combine框架是Swift的一个官方库，它提供了响应式编程的能力，允许开发者以声明式的方式处理异步事件和数据流。这个框架在处理复杂的异步操作和事件驱动的逻辑时非常有用。

💡结构体和类

结构体（Structs）和类（Classes）是Swift中的两种主要数据结构。结构体是值类型，它们在赋值或传递时会被复制，而类是引用类型，它们允许多个引用指向同一个实例。选择合适的数据结构对于确保代码的清晰性、性能和内存管理至关重要。

💡数据一致性

数据一致性是指在多线程环境中，确保数据在多个地方保持同步和准确的状态。在iOS开发中，处理并发访问和修改数据时，保持数据一致性是非常重要的，以避免潜在的错误和程序崩溃。

💡事件处理

事件处理是指应用程序如何响应用户交互或其他系统事件的过程。在UIKit中，事件处理涉及从硬件事件的捕获到视图和视图控制器的交互。

💡SwiftUI

SwiftUI是一个用于构建用户界面的框架，它允许开发者使用声明式Swift代码来构建iOS、macOS、watchOS和tvOS应用程序的界面。SwiftUI简化了界面构建过程，并提供了丰富的控件和动画效果。

💡视图层级

视图层级是指视图之间的层次结构，其中一些视图作为其他视图的父视图存在。在UIKit中，视图层级决定了视图的显示顺序和用户交互的处理方式。

Highlights

介绍了iOS应用的五种状态及其在应用生命周期中的发生时机。

讨论了在电话来电时应用的状态变化，即从活跃状态变为非活跃状态。

操作系统可以在后台终止应用以释放系统资源，此时应用处于挂起状态。

解释了挂起状态的特点，包括应用不在前台执行代码，但状态和数据保存在内存中。

讨论了如何在应用进入后台时保存用户状态，以便在回到前台时恢复到之前的位置。

提到了苹果提供的State preservation和restoration机制，用于保存和恢复应用状态。

讨论了委托模式在iOS中的应用，以及何时使用委托、通知或闭包。

解释了Combine框架的使用，以及如何处理异步和事件驱动的代码。

讨论了结构体在Swift中使用的原因，包括值类型的特性和性能优势。

探讨了类与结构体的区别，包括内存分配、引用计数和线程安全等方面。

讨论了如何处理类可能导致的数据不一致问题，包括使用串行队列进行同步。

解释了视图的生命周期，包括初始化、布局、添加到窗口和更新等阶段。

阐述了视图更新方法`setNeedsLayout`和`setNeedsDisplay`的区别及其用途。

描述了UIKit中事件处理机制的工作流程，特别是触摸事件从硬件到UI控制的传递过程。

讨论了Swift UI中状态属性和绑定属性的区别，以及它们在视图间传递数据时的不同用途。

提出了一个场景，说明了如何通过覆盖`pointInside`方法来改变触摸事件的处理，使其传递给视图层级中更低的视图。

讨论了Swift UI的舒适度，并提到了尝试和学习Swift UI的意愿。

Transcripts

hey guys welcome back to iode in our

mock interview experience Series this is

the second video for the technical round

before this we had an exploration round

if you haven't watched it I'll mention

its Link in the description please have

a look now let's jump on to our second

round which is going to be a very iOS

specific technical round hi P how are

you doing hi T I'm good how are you I'm

also good Pa thanks for asking

so let me give you a very quick walk

through of how this round is going to be

so in our last discussion we talked

about your experience projects you have

worked on challenges you have faced

right so this one is going to be

Technical and we'll talk only about is

development sure so in next 30 45

minutes we'll try to touch some of the

important concepts for iOS development

starting from the basics to complex

Concepts and we'll cover both UI

building and functionality

implementation sure I may ask you to to

fix some broken piece of code as well so

I hope that's fine with you yeah totally

all set yeah so let's get started with

your interview sure can you explain the

is application States and when each

state occurs during an app's life

cycle sure uh so there are five states

of the app the first one that is not

running uh this is the state where the

app is not launched or has been

terminated then comes the inactive that

is the app is running in foreground but

it is not receiving the events uh the

active state where app is running in the

foreground and receiving events as well

the background state where app is

running uh but but it is not in the

foreground for example playing music or

downloading something and then the

suspended state where the app is in the

background but not executing the code so

these are the five states okay can you

tell me the state when phone call comes

when user is using any app yeah it would

be inactive State because the app was

being used by the user so it was in

foreground but as soon as the call came

it stopped receiving the events uh so it

moved to the inactive state is it

possible that OS can automatically kill

the app when it is in

background yeah definitely I mean OS can

terminate the app running in background

and uh this is generally done to free of

the system

resources so what is the state of the

app and Os

terminat uh app is in suspended State uh

when it is terminated uh with the

intention of freeing of the

resources okay can you tell me more

about suspended

State sure so in the suspended State the

app is in the background but it is not

actively executing the code I mean uh it

it it has been uh Frozen by the system

to free up the system resources for the

other tasks while in this state the App

State and the data are preserved in the

memory but the app is not consuming the

CPU Cycles or using other system

resources so if the system needs more

resources or if the app has been in the

suspended state for for an extended

period uh without being brought to the

foreground the OS may decide to

terminate the app um when this happens

the app is removed from the memory and

its state is

lost okay got it so assume that you are

developing an app where users can read

novels MH consider that user was on page

167 then he or she got involved in

something and app went in background

after a couple of hours when user brings

the app back to the foreground he or she

should land on the same page same novel

how can you ensure this sure so uh this

is actually related to to the preserving

of the state before it gets killed now

when app enters the background uh we

should save the relevant information

including the users's current page in

the novel uh using it can be done using

the techniques like saving to a file or

storing database or defaults for that

matter

now since there is a possibility that

the app might get terminated uh when

when it is in the suspended state so we

should ensure that the information is

saved even when the app is killed so for

doing this we can listen to the

notifications like application did move

to background uh and there we can

execute the code and when the user

brings the app back to the foreground we

can check that if we are having the

preserved State data if it exists we can

use that to to restore it and uh move

move the users to the to the position

the 167 page as you mentioned so I mean

that is one of the ways through which we

can do this yeah this will work I think

but are you aware of any other way of

achieving this something which Apple

provides out of the box yeah I have

heard of State preservation and

restoration that Apple provides but uh I

haven't used it um I mean I read

articles about it and I'm aware that

there are couple of delegate methods in

F delegate I'm not sure about the the

name but uh but it involves some

protocol I think UI State restoring or

something like that through that it can

be done yeah you are right about the

protocol it's totally fine if you

haven't implemented it not every

application needs State preservation in

fact some of the apps it shouldn't be

done like banking apps sure I mean yeah

that that makes sense so let's talk

about delegations how delegation Works

in iOS it's Alternatives and when would

you prefer one over the

another sure so uh delegation is

actually a design pattern which is

commonly used in iOS for establishing

communication U and the data passing

between the objects now in this pattern

one object which is the delegate it it

trusts on other object which is

delegator uh with the certain

responsibilities or tasks the delegator

calls the methods on delegate to inform

about the events and to request the data

and for its implementation we use

protocols so the delegate adopts the

protocol confirming to the required

methods uh while the delegator holds a

reference to the delegate and for the

Alternatives of this delegate approach

we can use notifications or closures and

even even combined framework for that

matter U sorry I missed the last part of

your question what was it how do you

decide which one should be used yeah

right so uh the delegation is used when

you need to establish a onetoone

relationship between the objects um

especially if the delegate needs to have

more control over the delegator's

behavior uh it's also beneficial when

you need to ensure that type safety and

the clear documentation between the

objects uh while notification is more of

a publisher subscriber mechanism where

where an object broadcast the

notifications to other objects without

needing to know that uh who will receive

them so it's a good choice for

broadcasting events to multiple

listeners however uh this can be less

type save and harder to debug at times

uh the way uh I mean because of its

implicit nature for combine it provides

uh a declarative Swift API for

processing the values over the time it

is used for handling asynchronous and

and event driven code in a reactive

manner I would say so when dealing with

complex asynchronous data flows and and

event handling the combined framework is

a powerful choice I mean this is how we

can

decide uh how much comfortable are you

with combine yeah I have been using

combine for almost an year now so yeah

quite comfortable so what all publisher

have you used in combine and did you

find any challenge with any one of them

yeah uh I have used quite some

Publishers uh to to name some just

future uh data task publisher from URL

session pass through subject and The

Operators like map and filters because

even they are Publishers internally uh

and in terms of challenges I did face

some so once I I tried replacing the

dispatch group with the zip publisher

and struggled with it later I realized

that zip doesn't pass the data to

Downstream uh if any of the Publishers

fail which is not the case with dispatch

group I mean it notify function is

always called regardless of a success or

failure so that was a challenge yeah

that happens with zip anything else that

you have faced while learning

combine yeah another problem I faced uh

it was with pass through subject so I

thought that when I'll be having the

data I'll pass it as data and when I

won't have it I'll send the error so I

wanted to do this repeatedly because the

flow involved data validation but then I

realized that once we pass the error we

cannot use the publisher anymore so

there I invested some time and initially

it felt like a

challenge uh you mentioned about pass

through subject twice once with

Publisher and once as a challenge is

pass through subject really a

publisher uh pass through subject is not

actually a publisher but but it is used

to create the custom Publishers so a

pass through subject is basically a type

that confirms to both subject and the

publisher protocols and we can use it to

manually send some values to the

downstream subscribers and and handle

errors on completion events so it allows

us to create our own custom Publishers

that can emit values errors and and

completion

events you said that it confirms to both

subject and publisher protocols but if

we look at the Declaration of pass

through subject it says that it only

confirms to

subject yeah uh that is because the

subject inherits from the publisher

protocol so does publisher also inherits

from some protocol or

class uh I don't think so uh I'm not

sure but as far as I remember uh it

doesn't can you write the publisher

protocol

sure so it would be

something like uh

protocol

publisher which will take uh uh which

will return I think an output and a

failure

uh

then uh it will have a

method receive which will take a generic

param generate

subscriber uh subscribe which can be

subscriber which can be of Type S that

we have received as a generic

parameter yeah uh this this is how it

would

be uh do you want to go through it again

I mean do you think receive method would

look like

this uh yeah as far as I remember uh it

takes only one parameter that is

subscriber so yeah so so that means any

entity can be a subscriber and that can

be passed to receive

method yeah uh any entity can be used as

a subscriber uh no what I mean is are

there any constraints for the entity to

be a subscriber or can I directly pass

some view models in STS and it will

start receiving the

events uh yeah oh yeah uh my bad uh it

should confirm to uh the subscriber

protocol so there should be some

constraint for the parameter right yeah

uh that we can do by adding a where

Clause um let me modify just just a

minute

sure where s will be

subscriber yeah and what about output

and failure what are those um those are

the associated types for defining that

what type of output is expected and what

type of failure is expected um my bad I

missed on mentioning them as an as

Associated types associated uh type this

will be of type output and see type this

will be a failure which should be an

error

yeah yeah I think yeah yeah actually

there are a couple of more other

modifications but yeah more or less this

looks good so let's move on and discuss

about

struck I find strs really interesting

why do you think that Swift uses truck

for in build types yeah I think that uh

one of the main reasons would be the

nature of structs that they are value

Type U this means that they are copied

when when assigned to a new variable or

or passed as an function argument now

this ensures that the data remains

unchanged when shared among different

parts of the code and for the

fundamental data types like integer

double or or Boolean or or any type for

that matter this value semantic

simplifies the code and reduces the risk

of unexpected behavior and on top of

that structs also add to the performance

so probably that would be the reason and

how do they add to the performance so

since instructs are stack allocated and

involve less overhead compared to the

Heap allocated classes U they are often

more efficient for small lightweight

data types so what is the overhead in

Heap allocation or using classes for

that

matter definitely classes add certain

overheads the first and foremost would

be the the memory one so the Heap

allocated class instances have have an

additional memory aage due to the

reference counting and and class

metadata pointers uh this is not the

case with structs uh then there's

reference counting because classes rely

on reference counting for the memory

management so this involves tracking of

how many references are pointing to an

instance and and that can introduce the

runtime

overhead uh further classes are mutable

by Nature so uh it requires a careful

management to ensure the thread safety

and that will introduce complexity and

potential performance imp impacts U on

top of that garbage collection is one of

the considerations so U the managing the

Heap allocated classes will definitely

introduce an overhead of garbage

collection Cycles which can potentially

impact the realtime

performance so if there are so many

downsides with classes why do we use

them so uh structs are by default the

choice and that is what Apple also

recommends but it is not like classes

shouldn't be used anywhere so wherever

we need subclassing or in is involved of

course classes are needed uh UI UI view

controller is one of the classic

examples uh next wherever we need The

Objective C interoperability classes are

needed because structs cannot interact

with the components written in Objective

C and one of the Practical use cases

that I see is wherever we need to

maintain the state uh when we want that

action at one point should reflect the

changes at other places essentially the

reference holding is needed so that is

where classes are are required since

classes are reference based it gives you

the provision of maintaining the states

but at the same time they can lead to

data inconsistency definitely what do

you think no to totally so data

inconsistency is indeed one of the

challenges with the class-based types

and this is because the same instance

can be accessed by multiple entities at

the same time now as far as multiple

reads are happening concurrently

probably it is fine but in case if

multiple rides are happening

concurrently it will lead to the data

inconsistency and those are hard to

debug and and even crashes at times

totally so how can you handle this yeah

so uh for handling this we need to make

sure that you know multiple readed right

operations are are being uh prevented

the concurrent ones and one of the easy

ways would be to use the actors uh but

and that is because actors provide us

this entire concurrency handling issues

out of the box but in case if we do not

have the Liberty to to use the actors

because of the the minimum Target

supported version or any other

limitation then we'll have to uh build

the solution of Our Own by using the

cues and the logs and those kind of

things you mentioned actors um do actors

support inheritance um My Bad actors do

not support inheritance I just proposed

that solution because uh because I

thought that we are considering the

reference based types which actors are

but but if we are considering uh The

Inheritance as well then of course

classes are the only type and then we'll

have to build that solution yeah that's

right so PA let me share you one code

snippet and uh would you please tell me

what is the issue with data

inconsistency here sure uh let me have a

look last product uh andet date

price

yeah right um

so yeah I think the the issue is with

the update price uh method here so um if

two callers for that method try to

update the price at the same time by

calling this method then it will lead to

the data inconsistency since it's a

class okay and how can we fix this U we

can handle this by adding a Serial queue

um can you make those changes yeah

sure

uh

for

yeah I think uh this this would work uh

can you please explain the changes here

name sure so uh the the price uh

property uh I changed it to private to

and and encapsulated and also added a

price excess CU which is a Serial

dispatch queue because cues are serial

by default then I added a get price

function to safely retrieve the

product's price synchronously U and this

this also ensures that only one thread

access the price at a time the update

price function that that updates the

price asynchronously within the price

exis Q uh that also makes it thread safe

so this ensures that the concurrent

rights do not lead to the data

inconsistencies okay so what will happen

if um first two threads try to update

the price at the same time and second

two threads try to read the price at the

same time right so uh first considering

the scenario where two threads are

trying to update the price at the same

time so in this the uh when two threads

attempt to update the price of the

product simultaneously uh the the serial

dispatch queue will ensure that only one

of the thread is allowed to modify the

price property at that time U the first

thread accesses the update price and it

will acquire a lock on the price exis

que it updates the price and then

releases the lock the second thread

attempting to the exess uh to access at

the same time simultaneously it will be

blocked until the lock is released by

the first thread so as a result the

concurrent updates will be serialized

and only one of the threads price

updates will be applied so this prevents

the data inconsistencies and it it

ensures that the price is updated by one

thread at a time now when two threads

try to read the price at the same time

so uh the the get price method the the

basically the price access Q is also

used to synchronize the access uh to the

price property uh the same way with the

right uh the first thread will call the

get price and will acquire the lock on

the price XIs Q it will read the price

and then release the lock the second

thread will be blocked until the lock is

not released by the first one reading

the price this serialization again

ensures that the concurrent reads are

not happening at the same time for the

inconsistencies and both the threads

receive the the correct value they won't

interfere with each other so in both the

cases this this dispatch que it

guarantees that access to the price

property is synchronized and serialized

uh which is preventing the data

inconsistency

here okay so you said that second thread

will be blocked until the lock is

released by the first thread right what

does it mean it will keep waiting or

will it be returned without any value or

previous value exactly what will

happen right so uh I meant that the

second thread will be temporarily halted

and prevent it from executing further

until it it can acquire the lock so when

the first thread enters a synchronized

block it it acquires the lock on the

serial dispatch queue uh which is our

price exess Q in this case and it

executes the code inside that block in

the case of a read operation the first

thread reads the price and then releases

the loog while the first thread is is in

the synchronized block the second thread

also attempts to enter the same

synchronized block uh and in in the case

of concurrent exis to the get price

method I'm referring to so however the

second thread cannot immediately

mediately enter the synchronized block

because the lock is already held by the

first thread U instead the second thread

is blocked or put into a waiting State a

temporary halted state it will not

proceed further until the lock is

released by the first thread so the

second thread does not return a value or

a previous value it waits for the lock

to be released and once the lock is

available it proceeds to read the

current value of the period of the of

the price and uh then it uh returns okay

and why are we reading the value in a

sync block but writing in async right so

the decision to read the value within a

sync block while writing it at an uh in

an a sync block is based on a tradeoff

between different requirements so uh

reading the value within a sync block

ensures that the value is read

atomically uh meaning that that no other

thread can exess or modify it

concurrently while the read operation is

in progress this way we also get a

guarantee that the value returned by the

get price method is is the most upd up

toate value at the moment of the read uh

which is essential when we want to

ensure the data consistency in a

multi-threaded

envirment uh now writing the value

within an async block means that the

right operation is performed in in the

background uh possibly on a different

thread so this allows the calling thread

uh to to continue its execution without

waiting for the right to complete so

using an asynchronous operation for

right can I mean it can help in

improving the responsiveness of the

calling thread and prevent it from

becoming blocked while the right

operation uh may take some time U let's

say if it depends on a network request

or something something similar to that

so the combination of synchronous read

and asynchronous rights ensures that the

concurrent reads do not interfere with

the rights and vice versa okay yeah got

it so what are the other ways through

which you could have handled this uh we

could have used dispat sopers or or or

operation cues for handling this uh and

even synchronized blocks would have

worked but since they internally used

Objective C which adds to the

performance overhead so that's not the

good choice but yeah we can use dispim

firstand locks uh can you show how will

you do it with this P Sima first

sure

yeah uh this this should

work okay so you have used deer hair can

you tell how it internally

Works um I'm not sure uh but but from

what I have seen maybe it internally

maintains a stack uh this is because

when when we write multiple defer blocks

the last one is executed the first um in

the Leo manner so when the control is

about to move out of the current scope

the execution uh blocks that are added

to that stack would be probably popped

uh so I think that it's stack but I'm

not sure yeah I think that would be the

idea um cool let's move on and discuss

about the UI sure uh can you tell me the

live cycle of a

view sure um so first the view is

initialized uh with in it with coder or

in it with frame whatever is applicable

that gets called then for laying out the

subviews and applying the constraints

the layout subview method is called uh

then the system calls draw or draw re if

if it if we have over uh overridden it

then will move to Window or did move to

Window uh when the view is added to the

super View and then the view update

methods like set needs layout set needs

display those are called uh that's the

cycle yeah and when is aw from Li called

U it is called right after the

initiation my bad I missed it because I

was only considering the programmatic

view creation flow u in that one the

aake from n is not called but I mean it

is only called when we initialize the

the view from nib or the story board

yeah so you mentioned about two methods

set needs layout and set needs display

what is the difference between two so uh

both of these methods serve for

different purpose uh set need layout it

indicates that the View's layout is is

invalid and needs to be updated so this

method marks the view as as basically a

dirty View and it triggers the layout

updates on The View which means that the

views layout sub views method will be

called uh in the next run Loop cycle U

we typically use set needs layout when

we uh when we need to adjust the

position or the size of the subv update

constraints or perform any layout

related changes uh while the set needs

display method meod it is called when

the content needs to be redrawn or the

or it needs to be updated so this method

marks the view as needing display and

and it triggers the views draw method or

Draw R if it has been overridden U to be

called on the next run Loop cycle and uh

this is typically used when we want to

update the visual content of the view

such as drawing of Graphics or or images

within the view like that okay uh can

you explain the event handling mechanism

in UI kit uh event handling mechanism as

in sorry I didn't get you yeah uh

particularly the flow of a touch event

from Hardware to the point where it

triggers an action in a UI control got

it got it sure so uh the process starts

with a hardware event triggered by a

users interaction such as say tapping

the screen this Hardware event is then

delivered to the topmost view in the

hierarchy uh which is typically a UI

window then the UI window performs the

hit testing for identifying the view

which intersects with the touch Point um

and then after this UI kit establishes a

UI responder chain and the view that

that responded to the hit test becomes

the initial first

responder uh within the responder chain

the initial first responder is is

expected to handle the event U and in

case if it doesn't it is passed on to

the to the next responder in the Chain

by calling the method next responder U

and this is where the gesture recognizer

also comes into the play since they are

capable of recognizing the the gestures

like tap swipe pinches and analyzing the

sequence of the events so on recognizing

a gesture uh they they trigger an

Associated action uh essentially a

selector and this is where we implement

the custom logic and in response to the

gesture recognizer basically the code

that that we write uh okay so let me

give you one scenario like you have two

view on top of each other and you want

the touch to be handled by The View

lower in the hierarchy m essentially you

want to pass the touch to a view which

is below the view receiving the touch

how can you do this got it so uh I mean

for this uh we'll have to intervene in

the process of the hit testing U as I

mentioned earlier that hit testing

decides that which view should respond

so for achieving this we can override

the method responsible for the hit

testing U I think it's it's Point

coincides with or or Point insides with

something like this and and from there

if we return false the touch would be

passed on to the view Below in the

hierarchy so that way we can achieve it

yeah this would do so let's just have

last question from Swift UI are you

comfortable with swift UI uh yeah I mean

although I haven't worked that much with

the Swift UI but I would like to attempt

okay so can you tell me the difference

between state property and binding

properties sure uh both state and

binding property are I mean both are the

property reper in Swift UI and state is

used for maintaining the state uh within

the same view so maybe I can explain you

with an example say U you have a toggle

uh now for maintaining the state of this

toggle you would use a state property

which will give uh you a kind of two-way

data binding but in contrast to this The

Binding property rapper is used when you

need to pass some data to other view but

we expect that the changes from that

view should should be reflected back to

the view who passed it a kind of parent

child relation sort of thing so in such

scenarios you pass a binding variable to

the child and the changes then are

reflected back to the parent okay so it

means I cannot pass the State Properties

to child views uh no no you can pass a

state property but uh but but then you

won't get the two-way binding because

when State properties are passed they

are passed as as a copy and the changes

made by the child won't be passed back

to the parent yeah that's correct so PA

I think we have discussed quite a bit

that's it from my side it was really

good discussion uh definitely da I mean

indeed it was a great discussion U thank

you thanks for your time

yeah so that was about the second round

in our interview experience series the

next round we'll be focusing on the

system design and if you think that this

went well hopefully that will get

scheduled very soon please stay tuned

for it and if you like our videos if you

like the content that we create you can

consider subscribing to Channel see you

in the next round till then Happy

Gooding