MAIN-960 ⁃ Reduce loading time for 'Fetching Data' Screen to promptly show login screen

[sync-by-unito[bot]]

﹍Overview:﹍ The lodges have reported the “Fetching Data“ preloader takes long to display the login screen. The understanding of the “Fetching Data“ screen, is to pull all the necessary updates to data before logging in (i.e user list, updated names lists and maps), and to sync any data that has been stored once connectivity has been re-established.

The understanding is that once there is internet connectivity available, the data will pulled and pushed to the server, therefore the app should work offline as well. For example, if there is no internet connection, a user should still be able to log in and create sightings (which should be saved locally), and once there is connectivity the sightings should be pushed to Amplify. When I tested this, I disconnected my tablet from the internet, created sightings and saved. I then connected to the internet again (“Fetching data“ screen was not displayed), went back to Amplify to check if data was saved, and they were not. This was on version 3.1.3

﹍Task:﹍ The “Fetching Data“ preloader is to pull all the necessary updates to the user list, updated names list and maps. Therefore, when it does this in the beginning of starting up the app, it only needs to happen once:

• If there is a difference in these lists, and the users device needs to updated.
• If there are any unsaved sightings that have not been synced to the server. Currently sightings, are not being saved after working offline, and connection has been restored again. This is the highest priority as the app is supposed to have offline capabilities, to best replicate the internet connectivity limitations in the filed.

https://pantheracorporation.atlassian.net/browse/MAIN-987 should limit how long the Fetching Data Screen shows for because it shouldn’t have that much to pull down. The maps are proving to be more difficult to keep local ( https://pantheracorporation.atlassian.net/browse/MAIN-988 ), but this will only take a long time the very first time the app is started (after installation), bur should be quick anytime after that. Hopefully finishing these two tasks will decrease the time of the Fetching Data Screen anyways.

Attached is voice notes from the lodges, giving a description of the issue they faced. [^AUD-20240309-WA0022.opus] [^PTT-20240309-WA0014.opus] These audios can be played via VLC Media Player

┆Issue is synchronized with this Jira Task by Unito ┆Attachments: AUD-20240309-WA0022.opus | PTT-20240309-WA0014.opus

[sync-by-unito[bot]]

➤ Isaiah Lekay commented:

Irshaad Parker Melvin Ollewagen Clément Gianfermi

[sync-by-unito[bot]]

➤ Shannon Dubay commented:

As discussed in our last Panthera-Neoxia synch meeting: We have been receiving a significant amount of negative feedback from the stakeholder regarding this issue. Some feedback is recorded below, perhaps it may help in replicating the issue: ”The fetching data screen took 5 full minutes to load while connected to my fast, uncapped home wifi. This is way too long - once you limit internet speed it takes hours on site. The internet speed is much slower… And this must be accommodated in the app design. I have a phone full of messages saying that the new ‘fetching data’ screen never goes away. Not for hours and hours, if at all. One lodge said they opened it this morning, went on a 4 hour game drive and it is still turning upon their return. Another lodge says the same thing.” ”Some of the lodges can't be bothered anymore and are just waiting to hear when it will be fixed and working.”

[sync-by-unito[bot]]

➤ celian.noel commented:

Hello Shannon,

Thanks for the details we understand thats it is a critical issue and we will try to find a proper as soon as possible for the lodges. We are currently pursuing further investigations to reduce datastore syncing time. It seems that at launch datastore needs to set up and replicate all data in local which is quite time consuming (especially with poor internet). Unfortunately, it seems really difficult to reduce this syncing time cause most data need to be loads at least once to be able to use the app (like users data) and the orange screen. We are trying different option to reduce the data to download at first launch to reduce the time for the first launch. And once first launch is done and data are set up we are testing a new way to sync only latest data. Developing and testing all these scenarios might take us few more days. So if the urgence of this issue can’t wait for those days, we thought about proposing you a rollback of the yellow screen issue. It wont fix the precedent sync issue but at least will allow user that previously had downloaded the users and individuals to use the app and preform sighting without the latest datas. Otherwise, we added a skip this step button on the yellow screen that should work the same with user that previously downloaded the datas and that do not require a roll back.

Feel free to let us know if you want a rollback of that feature and we will be updating you with latest discovery regarding that feature in the comments of this ticket.

[sync-by-unito[bot]]

➤ Shannon Dubay commented:

Thanks for the feedback here, and the call yesterday celian.noel . We have created a new task https://pantheracorporation.atlassian.net/browse/MAIN-974 ( https://pantheracorporation.atlassian.net/browse/MAIN-974|smart-link ) for the new direction we discussed yesterday. This new task should be the priority, and will most likely resolve this task as well. Thanks for your hard work on this!!

[sync-by-unito[bot]]

➤ Shannon Dubay commented:

Melvin Ollewagen Irshaad Parker Isaiah Lekay - perhaps we need to update this task description under the “Task” section of the description?

[sync-by-unito[bot]]

➤ Melvin Ollewagen commented:

data will be stored locally and the updated list pushed on every save to an s3 bucket via rest so we can investigate whats happening when pushing data, we will need to investigate further what happens when data is being pushed via amplify, so far we havent encountered any issues as a result of limiting the amount of data being pulled, if amplify is still giving issues then we will stop using amplify altogether and start populating dynamodb using rest calls instead limiting the amount of data needed to upload and having local backups as a fail safe