Magellan 1.x Why yet another navigation library?

There are already other libraries that rest on the exact same ideas as Magellan. Why create another one?

The first reason is that when Magellan was started, those libraries weren't available yet. The second is that Magellan focuses first and foremost on simplicity.

Magellan only has 2 classes you absolutely need to know about: Screen and Navigator.

In Screens you only need to implement createView(), and for Navigator you only need to know about goTo(). Screens only have two events: onShow() and onHide().

That's it! No need to worry about persisting state, scopes, controllers, or transactions.

But to achieve the simplicity we want, we are forced to make tradeoffs. The two main tradeoffs with this library are:

• Screens are not destroyed on rotation, or even when you navigate to the next Screen. Therefore you need to be careful about not storing big objects in them, or leaking the context or the views.
• We don't restore the state if the process dies (you can still manually implement it if you really need to, but you probably don't).

For this last one, we think that the added complexity of dealing with serialization is not worth the small benefit of not losing your state if the process dies. In fact, it can even be a bad user experience to come back to an app days later and be landed in a random page instead of the home. And more importantly, the default way of creating an app should definitely not be to force you to serialize everything.