TinyDB after uninstall of an APP

Just a short question:

Will entries in TinyDB be deleted after uninstall of the App?

I am asking because on firstrun of an app I am setting a tag “firstrun” with the tag “DONE”, in order that some files will be downloaded on firstrun of an app.

I just noticed, that after uninstall and installtion again, the tag is still “DONE”

you should test this using the apk file rather than the companion app
Taifun


Trying to push the limits! Snippets, Tutorials and Extensions from Pura Vida Apps by Taifun.

Thanks Taifun,

I am already testing with the apk and not with the companion app!!

Heres a screenshot of the corresponding blocks:

and where exactly do you store some value for the tag firstrun?
Taifun

Here:

Note that on newer versions of Android, Google automatically backs up all app data, so even if you uninstall and reinstall an app with TinyDB, it’s possible that Android will restore the database from the app backup.

2 Likes

Thats strange…

I have the problems on a Samsung Galaxy Tab device with Android 8.1.0

On my Google Pixel smartphone I dont get this problem (Android 10)

On a Galaxy Tab 4 with Android 5.0.2 there are also no problems

EDIT:

I just noticed that if I set the TinyDB Tag of the Value to " " (empty) in the Companion App and the recompile and try to install, I have no problems.

Could it be, that the Companion App uses the same Database than an App and that, when closing the companion App, the Database will not be emptied?

EDIT2:

Ok, it does not work as said above sorry…

Yes, this is how it works. The TinyDB is app-wide. The app is the companion (not your project), and therefore you can query for entries in the companion's TinyDB that are from a different project. One way to get around this is to use the Namespace property on TinyDB, which stores the key-value pairs into a different TinyDB than the main one.

Ok, I made a few tests as I am absolutely sure that everything worked a few days ago with this Tablet (Samsung Galaxy Tab A 10.1 with Android 8.1.0)

I think the problem is the API level part of the app and the resulting Permission part.

I tested the App now with a few devices (Google Pixel with Android 10, Samsung Galaxy Smartphone with Android 8.0, Galaxy Tab 4 with Android 5.0.2) and the Only device where I discover the problem with not working “firstrun” is the Android 8.1.0 Galaxy Tab A

A few days ago there was a firmware Update for this device, maybe it has to do with this…

BUT, i tested an older apk on this device which was backed up in September 2019 and with this apk it is working (nothing changed in this part since then)…

Hi, this is exacylt the issue i am having i need to restest on the real phone clean and every time i install again after an uninstall android must be restoring the tinydb which is really annoying. Is there a way to clear the backups

Tony

@LostElements I am not sure what you are saying is going wrong.

Here are some possible solutions:
.

  • when you re-install the app, the ‘new’ app might include a
    clearall

Block in the Screen1.Initialize ,

  • Versionize your app . When you uninstall, then install a subsequent version give your latest creation of the app a new Version number.

version

Try these and you might get the performance you desire.

Regards,
Steve

1 Like

Hi, Both of those option are very good but dont actually do what i need and are already implemented. What i wanted to do was a totally clean install as per a first time use as i have found that for some reason on first load the DB is not populated properly but if i then do a clear all and use the same code block to reload its perfect. I could put a clear all if version hasnt changed i guess

Tony

Also note that if you previously used your “real phone” for development (companion) then there will be a directory /AppInventor/ and private directories containing assets and tinydb data. You need to remove these (do this will Clear All when in companion for tinydb) to ensure a “fresh install”.

Hi, i have never used the companion app, just downloaded the apk/sideload and this was on other trial phones as well. Its a little frustrating that unistall seems to leave things around and i have to figure out why on first ever install the DB is not populated correctly maybe some delay in creation but without a real clean install i cannot debug

Tony

You could try this:

Completely un- install your Problem App using the device Settings;

  • Go to the device’s Android Settings.
  • Select Apps
  • Find the name of the app you installed. Select it.
  • Then select UNINSTALL
  • NOW, re-install your problem app as if it were a brand new app.

Check the apps download folder; make sure there is not other copies of your install apk.
For instance, if present, delete myProblemApp.apk, myProblemApp(2).apk, myProblemApp(3).apk if they exist using your device’s File app…

What happens?

1 Like

ok will give it a go, there are about 30 of my apk in the directory but i would not have thought that would stop the DB being removed.

Tony

I’m not convinced that any of these suggestions will work. I think your best bet might be to use one of the APK editor tools to add the right flags to disable backup of your apps data:

https://developer.android.com/guide/topics/data/autobackup

The downside of course is that if your users lose their device or it is otherwise incapacitated then they will lose any data related to your app.

3 Likes

thanks will take a look at this, its only really needed during debugging to figure out why the db is not populating on first run after that it dosent matter if already there

tony

Just had another thought, when an app is loaded for the first time, is there any delay needed to allow the first creation of the tinydb. I am starting the app then dumping data into the tinydb from csv files. maybe something is not ready and once done once its ok.

Tony

TinyDB is backed by Android’s SharedPreferences object. As soon as you write something to it, that tag, value pair is persisted to storage. This is done synchronously so as soon as you read it back it will be available. File access is asynchronous, however, so if you’re trying to read content in Screen1.Initialize but you’re populating it in a File.GotText callback, that won’t work because Screen1.Initialize is always the first event to run (no events can run if the screen isn’t initialized, except the Initialize event).