Hello! Samples for iOS use SwiftUI, but it’s only ...

# mvikotlin

[Skeptick]

Hello! Samples for iOS use SwiftUI, but it’s only for iOS 13+ and in most cases is not suitable for production.
I would like to see the most primitive example of use with ordinary UIViewController. More specifically, working with Lifecycle, subscription for state changes and sending events.
If I just copy LifecycleRegistryExt and LifecycleWrapper and do:

override func viewDidLoad() {
self.viewLifecycle = LifecycleRegistry()
self.controller?.controller.onViewCreated(...)
self.controller?.lifecycle.start()
}

override func viewDidAppear(_ animated: Bool) {
self.viewLifecycle?.resume()
}

override func viewDidDisappear(_ animated: Bool) {
self.viewLifecycle?.destroy()
}

deinit {
self.controller?.lifecycle.stop()
}

Would this be the right approach?

[aiidziis]

hey, I think that this would work better -
viewDidAppear -> resume
viewDidDisappear -> stop
deinit -> destroy

[aiidziis]

https://arkivanov.github.io/MVIKotlin/binding_and_lifecycle.html

[Skeptick]

There are different types of lifecycle :)
ViewLifecycle usually has a shorter lifespan (from experience on Android. I’m not very good on iOS).

[aiidziis]

there is a diagram for Lifecycle and you can map it to corresponding UIViewController events.

[aiidziis]

https://static.packt-cdn.com/products/9781783550814/graphics/0814OT_06_02.jpg▾

[Skeptick]

It looks like I did it right 🤔 Controller’s lifecycle coincides with the life cycle of the screen, ViewLifecycle with the life cycle of the view

[aiidziis]

deinit is called when object instance is deallocated.

[Skeptick]

Yes. viewDidUnload is deprecated, and I don’t know a more suitable method than deinit to signal that a screen no longer exists.

[aiidziis]

onStop should happen before onDestroy , because onStop signals that View is no longer visible, but onDestroy signals that View no longer exists.

[aiidziis]

in your case you are calling onDestroy in viewDidDisappear , but as you see in UIViewController lifecycle it can reappear.

[aiidziis]

so when it reappears you will call onResume and lifecycle will be messed up.

[Skeptick]

I was guided by an example https://github.com/arkivanov/MVIKotlin/blob/5a76ca6b8ad9c21949a7264ffced5f19430d47ce/sample/todo-app-ios/todo-app-ios/details/TodoDetailsParent.swift#L55

[aiidziis]

because you will have -> onStart -> onResume -> onDestroy -> onStop

[aiidziis]

hm, interesting then I would like to know why it is used like that. 😄

[Arkadii Ivanov]

Hello! With UIKit you can use just one single Lifecycle object for both controller and view. A similar (an MVI-ish approach, not MVIKotlin) sample can be found here: https://github.com/badoo/Reaktive/blob/master/sample-ios-app/sample-ios-app/ViewController.swift

So the mapping is as follows:
viewDidLoad -> onViewCreated
videWillAppear -> onStart
viewWillDisappear -> onStop
deinit -> onViewDestroy + onDestroy

This is because in swift UI view can be destroyed when moved to backstack onDesappear, but its Controller is not destroyed and will be reused later.
In UIKit there is no such a behaviour.

[Skeptick]

Thanks for the detailed answer 😊