New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interactor
calls Presentable
before view loads [iOS]
#222
Comments
Do you have some example code for this? Can't say I have ever seen this before. |
I usually use following pattern:
@sbarow is there any reason why didBecomeActive is called so early? |
@neakor any insights into this? |
There are a couple of solutions for this.
|
@kronik Thanks. Am using something similar to |
@sham3k does my reply above help clarifying this? |
@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. |
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). |
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? |
@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. |
I ended up with
|
@metaine |
This one is called from Router. Once Interactor asks Router to add a new child RIB, that RIB is created inside some Router public method by calling [child-RIB-Builder].build(). A (child)ViewControllable (returned as a field of resulting ViewableRouting) then added to Router's ViewControllable. This is very common flow. BTW. Not sure if
might be enough |
There seems to be an issue where, if the
interactor
has to update its view indidBecomeActive
, the view has not yet loaded whendidBecomeActive
is called, leading to a crash. Any workaround to wait for the view to load and then update UI?The text was updated successfully, but these errors were encountered: