iOS Developer Mock Interview | Tech Round (Round-2)
Summary
TLDR本期视频是关于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
📝 技术面试经验分享
本段落介绍了一个iOS技术面试经验分享系列视频的第二轮,重点讨论iOS开发相关的技术问题。面试者首先被问及iOS应用的不同状态及其在应用生命周期中出现的时间。接着讨论了当电话来电时应用的状态变化,以及操作系统可能在后台自动结束应用的情况。此外,还探讨了如何在应用进入后台时保存状态信息,以确保用户在重新打开应用时能够回到之前的阅读位置。
🔧 iOS委托模式和替代方案
这一段深入探讨了iOS中的委托模式,包括其工作原理和何时使用。委托模式是一种设计模式,用于在对象之间建立通信和数据传递。讨论了使用协议来实现委托模式,并比较了委托、通知和闭包等替代方案。还讨论了结合框架的使用,以及如何处理异步和事件驱动的代码。最后,面试者分享了他们在使用Combine框架时遇到的一些挑战。
🏗️ Swift结构体和类的应用
本段落讨论了Swift中结构体和类的不同用途。结构体是值类型,适合用于小型、轻量级的数据类型,因为它们在赋值或作为函数参数传递时会被复制,从而确保数据不变性。类则是引用类型,适合用于需要继承或与Objective-C组件交互的场景。讨论了使用类可能导致的数据不一致性问题,以及如何通过使用串行队列来解决并发读写操作导致的问题。
🔄 处理并发和数据不一致性
在这一段中,讨论了如何处理类可能导致的数据不一致性问题。提出了使用串行队列来同步对共享资源的访问,确保并发读写操作不会同时发生,从而避免数据不一致性。通过修改代码示例,展示了如何使用串行队列来安全地更新和读取资源。此外,还讨论了其他可能的解决方案,如使用Grand Central Dispatch(GCD)和操作队列。
📚 Swift UI和事件处理
本段落转向对Swift UI的讨论,特别是状态属性和绑定属性的区别。状态属性用于在同一视图内维护状态,而绑定属性用于在视图之间传递数据,并确保子视图的更改能够反映回父视图。此外,还探讨了UIView的生命周期,包括初始化、布局、绘制和事件处理。最后,讨论了如何通过自定义hit测试来改变触摸事件的处理方式。
🎥 总结与展望
这是视频脚本的最后一段,总结了整个技术面试经验分享的第二轮,并预告了下一轮将专注于系统设计。鼓励观众订阅频道以获取后续内容,并感谢观众的参与和支持。
Mindmap
Keywords
💡iOS开发
💡应用状态
💡生命周期
💡委托模式
💡Combine框架
💡结构体和类
💡数据一致性
💡事件处理
💡SwiftUI
💡视图层级
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
5.0 / 5 (0 votes)