MVP Pattern Without History Mechanism?

[Abdullah]

Hi,

  Is any Impact Implementing MVP Pattern Without History Mechanism?

[Rogelio Flores]

I don't see any, but also don't see any reason why you wouldn't want to have history support in your app.

[Abdullah]

Because of History Mechanism,When Switching from one Screen to other screen i need to pass some data to that Screen that i am unable to achieve using History Mechanism.Will it possible to pass the data?Is there any example code?

[Greg]

When passing the state of the screen in the url you shouldn't embed whole data in it. Instead you should pass some references to it like ids etc. The screen you want to display should use that references to fetch the actual data (from LocalStorage / IndexedDB / Server)

[Ümit Seren]

This is an anti-pattern.

You should make sure that all screens that can be navigated to by the user are stateless in the sense that all the state can be derived from the URL. 

The big advantage is that the screen can be bookmarked users can navigate to it directly.

If you are concerned about redundant backend calls encapsulate the backend calls in a seperate (singleton class) that handles caching. This will also reducate the logic in your Presenters because you don't have to check the URL parameters against the already fetched data.