[Mobile] Cached GPS and/or Event Data

[mikelambert]

When we open the app, it does a GPS lookup for lat/long (takes a second or so), then uses that to do a reverse geocode to get an address/city (takes another second), then uses that to do a DanceDeets API search for data (which is another few seconds).

A few things can be improved here on loading the "list of events", making everything much faster to load on app startup.

• We can initiate a request to the DD API with lat/long as the location= parameter, at the same time we do the address/city geocode to get the city, and parallelize the two. And then display the city in the search box when it's found, and the event list in the result set once it's returned.

• We can show the cached City / EventList-json immediately, while all the processing is going on in the background and reloading the dataset from the server. Sometimes you open the app in a subway without an internet connection (or without a sim card internationally, while you're on wifi), so it'd be nice to have accessto your last-seen data.

• If we do #2, I worry there might be "jumps" in the result set as you are scrolling-down and about-to-click, which is unfortunate. I don't have great ideas for this....a few ideas:

-- We could look at the current scrolled item, and re-scroll to that item in the new dataset (if it still exists). -- We could do some "are we online?" check at the very beginning. If we are not online (or the search results fail), we show the cached data. If we are online, we show-nothing, and then show the downloaded data as soon as it arrives. -- Open to other ideas here if you got them?

The code is in mobile/js/events/list.js code and starts in the initialize() function flow.

[mikelambert]

You can probably use AsyncStorage to store stuff locally.

The app uses redux (another technology you'll probably need to learn for the react-native world), so in theory we could probably just use redux-persist as well, and persist our entire app state to disk. It's appealing, and might even be the best option to keep the code size and complexity down.

I mostly worry that if the internal app state gets corrupted for some reason...an app restart won't actually clear the app state, and so it may be impossible to recover from bad app bugs. :( I believe it's possible to only rehydrate certain reducers (according to this), so it might be possible to restrict our state-rehydration to just the search and searchHeader keys (which is basically the search state) and simplify things without too much danger.

[trisrael]

I like the idea of using redux-persist to get the fastest implementation + simplicity. I'll try this route first looking for major gotchas that come up, for instance the size limit of storage.

As the online/cached behavior.. Normally, there is some global navigation notifier that could work for either offline or data being fetched, so the user knows that something is happening. Normally I am used to just a persistent flash message or some static area with an icon denoting what is occurring.

I will look around for some designs, but mostly I'll have to play a bit first to have a better idea about suggestions.