Ribs: `Interactor` calls `Presentable` before view loads [iOS]

[sham3k]

There seems to be an issue where, if the interactor has to update its view in didBecomeActive, the view has not yet loaded when didBecomeActive is called, leading to a crash. Any workaround to wait for the view to load and then update UI?

[sbarow]

Do you have some example code for this? Can't say I have ever seen this before.

[kronik]

I usually use following pattern:

1. ViewController in viewDidLoad method calls listener?.didPrepareView
2. Interactor implements didPrepareView and starts loading data or interact with presenter

@sbarow is there any reason why didBecomeActive is called so early?

[sbarow]

@neakor any insights into this?

[neakor]

There are a couple of solutions for this.

1. Given that when and how to display the data the interactor passes to the view controller is view logic, the view controller should take the responsibility to store the data internally. It can then render this data when the appropriate view controller lifecycle is reached, such as viewDidAppear.
2. Instead of storing the data, the view controller could use lifecycle bound methods such as confineToView(events). Although I'm not sure if we open sourced this.

[sham3k]

@kronik Thanks. Am using something similar to listener?.didPrepareView before pushing anything to the view. Expected the tutorial to have something similar to this.

[neakor]

@sham3k does my reply above help clarifying this?

[sham3k]

@neakor I felt @kronik has a better solution. Also, I noticed RIBs is currently at version 0.9. Any timeline for the next version or is this prod-ready?

[neakor]

@sham3k it is production ready. This has been our architecture for the Uber app since almost 2 years ago. We are working on the next version to simplify the architecture and reducing boilerplate.

[lisacmer]

I feel like @kronik solution goes in conflict with the whole "business logic drives the app, not the view tree" thing. Considering this, seems like @neakor solution is better (it seems that this is the way this situation is handled in BasicScoreBoardViewController in tutorial) , but it doesn't solve a problem of routing submodule to subview before the main view did load. I was wondering if next version will solve this problem some way or another (maybe by forcing the view to load, which for me seems like an antipattern).

[metaine]

I wonder if this can be solved by making Presenter a ViewModel, updating VM from Interactor - and subscribing to Presenter (ViewModel) updates in ViewController when VC is actually ready. Or it is just against a RIBs/Clean Architecture way?

[metaine]

@neakor Could you please go into detail about lifecycle bound events and confineToView method?

For now, all my Presentable methods are writing to (ViewController's) reactive sequences, which are subscribed to in viewDidLoad(), effectively modifying UI at the point when the view is loaded and safe to operate. This is quite verbose, but... well... OK.

Things are getting tricky when there is a need to call not only Presentable but also ViewControllable methods. Like asking router to add child RIBs/subviews inside didBecomeActive(). Do we need a new reactive var (stored state) inside Presentable to add submodules when view is ready? Not nice (and feels like more MVVM/SwiftUI-ish way of building screen hierarchies).

Do we really need didLoadView() in PresentableListener protocol in order to call Presentable/ViewControllable methods from Interactor safely? Does it fit the RIBs control flow paradigm? (my guess it doesn't)

The problem of calling UI methods when the UI is not ready is the only unclear part of overall clean and beautiful framework.

[metaine]

I ended up with

func add(_ viewControllable: ViewControllable) {
        if isViewLoaded {
            internalAdd(viewControllable)
        } else {
            rx.viewDidLoad.single().subscribe(onNext: { [weak self, weak viewControllable] _ in
                guard let self = self, let viewControllable = viewControllable else { return }
                self.internalAdd(viewControllable)
            }).disposed(by: disposeBag)
        }
    }