New update: User data loss
Seems like my app upgraded today after I just spent a long weekend offline. Noticed that the interface elements look different.
The bigger issue I noticed was all of my user data has been completely blown away. Should have backed it up if I thought it was important I guess. The option to backup is in there. Little late for me to find it.
Was just looking at my data last night and thinking I should screenshot how off budget I was. Guess it will suffice to say I blew the budget this month.
Might want to roll back if it hasn't completely deployed. Becoming a developer made me a much more forgiving consumer of software a long time ago. However, with this type of situation even I am just going to look for a new app. Though I do have to admin it is partial user error on my part, could have backed up. That's a stretch though, bit of self-victim blaming.
-
Official comment
Thanks for using ATracker!We have several users reporting this issue.They got their data back after killing the app and restart it again.We think it is caused by slow database structure upgrade process. But we are still checking the code.If it still does not work after restarting the app, please let us know.Sorry for the inconvenience!Best Regards,JianComment actions -
We think it might be something wrong in the old version that cause the data issue actually.
ATracker for Android has two set of data storage, It will store data in database as well as in temporary cache to improve the performance.
We have re-read the code on when the default task is added and we found it only add the default task if the initial database creation is failed. So it might be the case that the storage on database is never used and your data is just stored in the cache.
So every time you have a system update, ATracker checks whether there is default task in the database, as it does not find the data there, it recreates it. That explains why the default task is recreated and why it is not a common case.
We have also checked the code on why the database failed to get created, but we have not found any clue on it yet. It might be related to some security setting on the device that blocks the app to create file.
Can you do a data backup in ATracker->Settings and send it to support@wonderapps.se? We can check whether there is actual data in it or just default task or empty.
Thanks!
-
From what you're saying it sounds like my data only ever existed in the cache. Which surprises me I haven't lost it yet, but I never explicitly tried to wipe app cache from the storage settings so I guess it should have been expected that it stuck around.
At this point I've had to reinstall the app. Probably no surprise the db file was empty only containing the schema. I've never messed around with sqlite before but made an educational guess that's what the back up was and installed an editor. Wasn't sure exactly what I was looking for at first but entries started populating after starting the default task. No historical task though, just ones I started up today.
Not sure about a potential permissions issue blocking db init. I was able to create the backup file, no questions. Though that may have been permissions granted on reinstall the app may have not had it before. I installed the app with Android 9 and it was recently updated to 10
In retrospective, I'm not sure the complexity of caching was worth it, given the types of issues associated. From a user standpoint I wouldn't call the app performant. Also "performant time budgeting app" wasn't really part of my search criteria. It would often take multiple seconds to load anyway. Particularly after Android put it into whatever the sleep life cycle is. 1st world problem sure, I'm just pointing it out more than saying I care. Its not trying to load up chunky media assets or maps like in an app like gaiagps where I would more expect that type of slow down. Gaia sometime starts up faster than this app on the same phone. I'm not mobile dev though, what do I know. Maybe a cache solves a more technical issue, than performance. If the db was local I would have just made it the source of truth. I'm sure storage read speeds are different on cheaper devices so maybe it was worth it.
-
Yes, the caching is mainly for the slow devices and for user with many data point and want to do report covering long duration.
We have done some load test with that 2 years ago. If user intensively use the app and everything load from database directly without caching, it will take about 5-6 seconds for a monthly report.
Unlike iOS device, Android device speed can differ a lot. Some cheap device is really slow in fetching data from database, although calculating part is fast enough.
Please sign in to leave a comment.
Comments
5 comments