Rename Router.exit() about cicerone

[Edward608]

I think exit is fairly good for the context of a presenter. As when a presenter calling exit, it means the current presentation is over and the presenter needs to be destroyed. While back somehow means the presenter is still persist and doing its job.

[terrakok]

No. It will broke backward compatibility. Something difficult for new adept - it is normal 😃

[Jeevuz]

Backward what? Find/replace at the same time you change the library version.

[Jeevuz]

And it's not difficult - It's confusing. Nobody likes to be confused and it's not good for the library.

Let's do some poll in the chat?

[terrakok]

Poll - it's not good way.
Exit command for screen presenter is more native method than back because it local logic.
I want to leave it as is. For now.

[Jeevuz]

I think you only one who think in this way, this why I think poll is the good way.
And it is as it is now already. I think this issue should be reopened and marked as discussion for other people to express their opinion.

[terrakok]

Look,
exit - it command will be destroy presenter. Presenter calls router.exit() and ready for destroing.
back - it command is very similar on exit but may be confuse 'cause not return back on previous screen after replace. Do you understand?

[Jeevuz]

Yep, but... we have backTo method too. But the presenter will not be persisted in any way in this case. So we have both cases with different "feelings" here. And this is what makes me a little unhappy with that.
Also, we have not paired methods names. I would prefer to see enter/exit, navigate/back... You get the idea.

[Jeevuz]

Looks like I'm the only one who wants this change ;)
So, I close this discussion. It had enough time.

[RandGor]

I like how calling
router.exit()
twice for some reason will back (BACK whole app but it is not about to close the one determined presenter) app twice.
That's interesting because it is not possible to exit fragment and open another one:

1. If you call router.exit before something - it will close current fragment without fulfilling next line of code with opening something other.
2. If you call router.exit after opening another fragment - good Lord, it will close opened fragment.

I don't think that's what all we want, this problem is my headache for current week...