-
Notifications
You must be signed in to change notification settings - Fork 100
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
Starting AppCoordinator again #3
Comments
Hi @cojoj. Thank you so much for the feedback! I'll describe the approach we are using in our apps. We manage the auth state in some singleton service class AppCoordinator: BaseCoordinator<Void> {
override func start() -> Observable<Void> {
showAuth()
// The app coordinator will never finish
return .never()
}
// Recursive auth function that will restart the AuthCoorinator after completion.
private func showAuth() {
let authCoordinator = AuthCoordinator(window: window, container: container)
return coordinate(to: authCoordinator)
.subscribe(onNext: { [weak self] in
self?.window?.rootViewController = nil
self?.showAuth()
})
.disposed(by: disposeBag)
}
}
class AuthCoordinator: BaseCoordinator<Void> {
override func start() -> Observable<Void> {
// Present Auth ViewController and stuff
// ...
let authService: AuthService = try! container.resolve()
// Auth Coordinator observes `didLogout` property and finishes only when user has logged out
return authService.didLogout.take(1)
}
} Personally, I don't like that approach too much, because of the shared Hope this answers your question, let me know if you have any problems with it. |
Ok, I see... I guess we somehow swim in the same pool with this. What I did so far is skip this recursive thing (though I completely skipped final class AppCoordinator: BaseCoordinator<Void> {
// MARK: Private properties
private let router: Router
init(router: Router) {
self.router = router
}
override func start() -> Observable<Void> {
return runAuthFlow()
}
// MARK: Private methods
private func runAuthFlow() -> Observable<Void> {
let coordinator = AuthFlowCoordinator(router: router)
return coordinate(to: coordinator)
}
} And of course, One thing that really bothers me is that every Also, one more question (not really related, but...), have you implemented this Coordinator pattern without RxSwift? FRP is great for this stuff, but having something like this as a 3rd party dependency with support for regular code and FRP would be a great thing! Coordination is always a big PITA in bigger and not linear iOS projects and having library supporting this stuff would be awesome! |
How about, we use |
@arthur-here did you find a better solution for this problem? I'm also facing the same issue, and my solution is very similar to yours. I'm also not happy with this approach :( |
I created this project as an example, to make easier to reach to a solution for this problem. It describes two common scenarios in which the Coordinators with Rx seems to have some flaws. Have anyone here already found some satisfactory solution for those problems? |
Thanks for the idea and implementation, this is a great resource on how to crate a nice, maintainable and also very flexible all architecture!
I’m struggling right now with “sign out” functionality in our application. I have two coordinators:
AuthCoordinator
AndMainCoordinator
. In myAppCoordinator
I start withAuthCoordinator
Which later can redirect me toMainCoordinator
, if authorization succeeds. The problem is that one of theViewControllers
In myMainCoordinator
Has “sign out” button which shouldstart
AppCoordinator
From scratch. I have no clue how to achieve this, because I want to avoid so deep dependencies between different coordinators etc.Do you have some sort of solution for this kind of behavior?
The text was updated successfully, but these errors were encountered: