Open saved state for events

[liveHarshit]

Describe the feature you'd like
Open saved state for events while navigating using navigation drawer.

Would you like to work on the issue?

• Other: Open for all

Parent Issue: #1139

[AnEnigmaticBug]

@liveHarshit can you please elaborate this a bit more?

[liveHarshit]

While navigation to other section (using bottom navigation) from events fragment, after returning back, events are loading again. It should not happen.

[AnEnigmaticBug]

Can I work on this?

[liveHarshit]

Please, go ahead.

[AnEnigmaticBug]

Ok. Thank you :)

[iamareebjamal]

@AnEnigmaticBug Please take this up on priority

[AnEnigmaticBug]

Ok @iamareebjamal

[AnEnigmaticBug]

I need to discuss what caching strategy should I use for this. I've the following strategies in mind:

• Always use the database. Get new data only if either:

  1. No data exists.
  2. User has pulled to refresh.

• Always use the database but send a request in background every time it is accessed.

• Keep a singleton which holds whether the events data has been retrieved in this session or not. If it has been retrieved, use the database. Otherwise, use the database and send a request in background.

[AnEnigmaticBug]

I'll begin working on this ASAP once I get to know which one of these strategies is preferred by you.

[liveHarshit]

@AnEnigmaticBug What if we load fragment from the back stack?

[AnEnigmaticBug]

@liveHarshit that came to my mind too. But I've a (possibly misplaced) concern regarding that solution. If we solve this problem using back stack:

1. We may have to 'fight' with the default way Navigation component works which will make it difficult to follow the code and increase chances of future errors.
2. This problem is not isolated to the events screen. As referenced by Bottom Navigation issues #1139 , it also occurs in at least the tickets screen. To solve this problem for both events and tickets screen, we'll have to keep both EventsFragment and TicketsFragment alive/in the back stack at all times which doesn't make sense. As more and more screens need their contents to be saved, this issue will only increase.
3. If we use a single way consistently throughout the app, it will be easier to understand and modify in future.

[AnEnigmaticBug]

@iamareebjamal which caching strategy do you prefer?

[iamareebjamal]

I don't think that there needs to be such a contrived strategy for this simple task, bottom nav view should have several fragments open simultaneously

When navigating across the nav view, the fragments should remain in memory and not be replaced, and hence, onCreateView should not be called on each navigation

This is a standard behaviour of bottom nav view naive implementation without any hacks or tricks