Android Question DirAssets - I must be missing something - Please help

[AlexOfOz]

Sorry for another silly newbie question, but I must be misunderstanding something.

I'm working on a program that uploads files to the phone. My understanding is that the only place we can upload to, which is apparently automatic, is to DirAssets.

The uploading is working fine - no problem with that. But now I'm wanting to delete files from the program and my understanding is that DirAssets is read only. So now old, previous files, which have been removed from the program are still showing up in DirAssets and making the program unworkable.

What am I not understanding? Ideally I would prefer to create new folders that I am 100% in control of and read and write to those, but I can't see anything that tells me how to do that.

Please help.

Alex

 

[drgottjr]

i understood the question a little differently. my take was that op wants to update files that began their miserable lives in dirassets.
in addition, what i found curious was:

The uploading is working fine - no problem with that.

i'd like to know more about uploading files to a phone. that's an unusual twist.

anyway, based on my understanding:

you can't "load" anything to dirassets. it's not actually
part of the device's file system. technically, that makes
it "read only". you populate it at compile time. it's built into
your apk. it's always there until you remove the files or replace
them when you re-build the project with new assets.

where you can load (or save) files is in dirinternal or
(better) in safedirexternaldefault (see runtime permissions).

so, how to reconcile the old and the new? the usual way
is to copy the files from dirassets to dirinternal or
(better) safedirexternaldefault. from that point on, any
updates to those files will be saved in dirinternal or
(better) safedirexternaldefault and overwrite what was
there. if no such file was there, any new uploads will
simply be saved as new files.

what to do about dirassets? basically nothing. when your
app is launched, the first thing it needs to do is to check for the
existence of one of the files you have in dirassets. if that
file does not exist in dirinternal, it means that the files
in dirassets were never copied to dirinternal. you copy them.
from that point on, every time the user launches your app,
the test will be true, so no copying is done. after you have
copied the files from dirassets, the app should never
refer to them in that location; always by their new home in
dirinternal or safedirexternaldefault. if you do not
test but blindly copy the files to dirinternal, those files will
overwrite whatever new versions there may already be in
dirinternal. this will happen every time a user launches your
app.

if your files will never change or if can only be changed
by updating the app, then everything can stay in dirassets,
and you can safely refer to dirassets.

once you allow for user downloads, then the downloads
can only go into writeable folders. if you put files in
dirassets at compile time and those files can be updated, then
you need to copy them from dirassets to somewhere else.
but such a copy is only done once!

another option would be not to put any files that are subject
to change in dirassets. have the user download changeable
files the first time the app is used and save them to dirinternal
or safedirexternaldefault.

 

[AlexOfOz]

i understood the question a little differently. my take was that op wants to update files that began their miserable lives in dirassets.
in addition, what i found curious was:

i'd like to know more about uploading files to a phone. that's an unusual twist.

anyway, based on my understanding:

you can't "load" anything to dirassets. it's not actually
part of the device's file system. technically, that makes
it "read only". you populate it at compile time. it's built into
your apk. it's always there until you remove the files or replace
them when you re-build the project with new assets.

where you can load (or save) files is in dirinternal or
(better) in safedirexternaldefault (see runtime permissions).

so, how to reconcile the old and the new? the usual way
is to copy the files from dirassets to dirinternal or
(better) safedirexternaldefault. from that point on, any
updates to those files will be saved in dirinternal or
(better) safedirexternaldefault and overwrite what was
there. if no such file was there, any new uploads will
simply be saved as new files.

what to do about dirassets? basically nothing. when your
app is launched, the first thing it needs to do is to check for the
existence of one of the files you have in dirassets. if that
file does not exist in dirinternal, it means that the files
in dirassets were never copied to dirinternal. you copy them.
from that point on, every time the user launches your app,
the test will be true, so no copying is done. after you have
copied the files from dirassets, the app should never
refer to them in that location; always by their new home in
dirinternal or safedirexternaldefault. if you do not
test but blindly copy the files to dirinternal, those files will
overwrite whatever new versions there may already be in
dirinternal. this will happen every time a user launches your
app.

if your files will never change or if can only be changed
by updating the app, then everything can stay in dirassets,
and you can safely refer to dirassets.

once you allow for user downloads, then the downloads
can only go into writeable folders. if you put files in
dirassets at compile time and those files can be updated, then
you need to copy them from dirassets to somewhere else.
but such a copy is only done once!

another option would be not to put any files that are subject
to change in dirassets. have the user download changeable
files the first time the app is used and save them to dirinternal
or safedirexternaldefault.

Thanks enormously. You have given me exactly what I was missing in my understanding.

When I say loading the files, that's just my way of saying that the files associated with my program, predominately jpg and m4a, magically appear in DirAssets. But as that was I could understand from the help, my way of describing it is that when I execute my program initially from the laptop, it "loads" the files to DirAssets on the phone.

Now that I have the information you have provided, I'll start learning about that. Another door will open to me that will let me bump into the next wall. ;-)

Thank-you

 

[emexes]

But now I'm wanting to delete files from the program and my understanding is that DirAssets is read only. So now old, previous files, which have been removed from the program are still showing up in DirAssets and making the program unworkable.

Well, that's intriguing. You might be right - files in DirAssets are not removed*, even after they're removed from the IDE Files Manager tab, and the app is recompiled etc and the new APK uploaded to the phone.

If I deleted the app, and then uploaded it again (ie this time a fresh install, not an update) then the removed files were finally not present in the phone DirAssets folder.

Glad I checked.



* as in: remain present

 

[AlexOfOz]

Well, that's intriguing. You might be right - files in DirAssets are not removed*, even after they're removed from the IDE Files Manager tab, and the app is recompiled etc and the new APK uploaded to the phone.

If I deleted the app, and then uploaded it again (ie this time a fresh install, not an update) then the removed files were finally not present in the phone DirAssets folder.

Glad I checked.



* as in: remain present

Yes, I have a habit of finding these outlier situations. And yes, I have discovered the only way to clear DirAssets is to uninstall the program, then execute again.

I'm now playing with DirInternal and it is looking much more user friendly.

 

[emexes]

files in DirAssets are not removed*, even after they're removed from the IDE Files Manager tab, and the app is recompiled etc and the new APK uploaded to the phone.

Righto, even though it doesn't remove files from DirAssets on the phone that are no longer in the IDE Files Manager tab,
it does overwrite old files on the phone with new files contained in the uploaded updated APK.

So, if you can't rely on your users to delete the app and reinstall again, the next-best solution is to set the files that are no longer required to be zero bytes long, or maybe a short flag like the word "deleted" (or "wtf?"). The files will still be in DirAssets, but at least they won't be clogging up your APK file so much.

I also just learned that File.Size() doesn't work on DirAssets files. Bonus!

 

[emexes]

Yes, I have a habit of finding these outlier situations.

 

[AlexOfOz]

Yep, you are rapidly learning all the traps that I've learned over the last few days. This became a problem for me this morning - I'm the only user / this is just for fun and learning - when I wanted to replace an existing file. The files begin with a number and special character, such as 1@, which dictates how they are managed further in the program. As I was replacing an existing file with a new one, but both names started with 1@, my program was getting confused as it was finding both.

Grinding of teeth.

 

[drgottjr]

Yes, I have a habit of finding these outlier situations. And yes, I have discovered the only way to clear DirAssets is to uninstall the program, then execute again.

I'm now playing with DirInternal and it is looking much more user friendly.

so, i have a problem with these conclusions (maybe i'm missing the point
here, but i feel obligated to defend b4a in this matter.) the files are removed
from dirassets (via the ide). they are not hidden in the apk, and they do not
stay somewhere within the phone after the app is updated.

attached please find a sequence of events. i couldn't zip them all
because the archive is too large. oddly, if i upload them one at a time,
all is good ...

1) image is not present in project
2) project deployed to device and run. failure to find image confirmed.
3) as double proof, apk shows no "assets" folder.
4) image is added to files tab in ide
5) project deployed to device and run successfully.
6) apk shows presence of assets folder
7) assets folder shows presence of image
8) image is deleted from files tab via ide
9) files tab in ide shows no image
10) files folder in project shows no residual image left behind.
11) project (without image) is deployed to device and run.
12) apk show no assets folder.
13) screen cap from updated (newly compiled) apk shows file not file.

nothing was left behind after removal from files tab via ide. file is
not listed in files tab, it is removed from assets folder, it does not
appear in updated apk and it is not found when app is run.

 

[emexes]

so, i have a problem with these conclusions (maybe i'm missing the point
here, but i feel obligated to defend b4a in this matter.) the files are removed
from dirassets (via the ide). they are not hidden in the apk, and they do not
stay somewhere within the phone after the app is updated.

I admire your faith I was surprised too when I tested it and found the file was still present in File.DirAssets of the Android device, and I'm looking forward to replicating your process to see if the result changes.

13) screen cap from updated (newly compiled) apk shows file not file.

Well, that's super-interesting my experience was:

- nothing was left behind after removal from files tab via ide
true (if we're talking about the project's files folder on the IDE computer, although the original final still exists elsewhere on the same computer)

- file is not listed in files tab
true

- it is removed from assets folder
from the files directory on the IDE computer: true
from the assets folder on the Android phone: false, ie the file is still there

- it does not appear in updated apk
I don't know, but probably not, since it is no longer in either the project's files folder, or the files tab

- and it is not found when app is run
false - the file is still in File.DirAssets, with same size as before

 

[emexes]

Hmm, your test looks good. Maybe there is some obscure option in B4A about whether to delete old files from File.DirAssets when updating.

My assumption was that the update process would delete the entire File.DirAssets and replace it with a fresh copy from the APK.

I will repeat your process here.

I like that the classes.dex and resources.arsc files stay the same, with and without tilt.jpg in the APK.

 

[AlexOfOz]

Hello, I need to stress that I am not attacking B4A. I love B4* and don't have a single problem with it.

The purpose of my post was to mention the situation that you are now confirming for yourselves - I'm IT for 40+ years and understand how stuff works - and to maybe be told that I had misunderstood something and was doing it the wrong way. As it turns out, because I approach things from a first principle perspective, and like to understand how things work, and I'm an outlier with how I approach things, I've identified a situation that has always been there but has not been clearly recognised by others.

Since my first post on this subject, I have learned about DirInternal and how to copy from DirAssets. So my problem has been solved, thanks to this forum and I appreciate it greatly.

I will no doubt bump into another conundrum soon and will be asking a similar question of those who are more knowledge than me.

 

[emexes]

I will repeat your process here.

Lol I am a third of the way through, added tilt.jpg to files tab, run the app, image displays on phone, but when I look inside the APK... wtf?... no assets folder, let alone the image file... I am so confused.

I'm going to have to continue this tonight. Currently doing a search of all drives on this computer to see if there is another APK with today's date.

 

[emexes]

1) image is not present in project
2) project deployed to device and run. failure to find image confirmed.
3) as double proof, apk shows no "assets" folder.
4) image is added to files tab in ide
5) project deployed to device and run successfully.
6) apk shows presence of assets folder
7) assets folder shows presence of image
8) image is deleted from files tab via ide
9) files tab in ide shows no image
10) files folder in project shows no residual image left behind.
11) project (without image) is deployed to device and run.
12) apk show no assets folder.
13) screen cap from updated (newly compiled) apk shows file not file.

I think I might be on to something.

Compile as Debug mode = image not in APK
Compile as Release mode = image in APK

Although, question-wise, this might be jumping from the frying pan into the fire, because now I'm wondering:

How the heck did the tilt.jpg travel from the PC to the phone in Debug mode, if it wasn't in the the APK?

I will no doubt bump into another conundrum soon

@AlexOfOz could you please check if the "sticky files in File.DirAssets" issue on your setup goes away when compile in Release mode?

 

[AlexOfOz]

I'll try that in 12 hours, but experience so far tells me that anything different adds to what is already there. A more definite answer in 12 hours

 

[agraham]

I don't know the full details but Debug mode uses a virtual assets folder instead of embedding the files in the apk. Most of the code in Debug mode is executed on the PC and not on the device. The device just executes a cutdown shell version of the app that mainly contains UI code to interact with the user.

Deployment of assets / virtual_assets concept?

Hi , i have a B4A application with lots of html , js , images in my [Files] folder of my project. and during deployment , i compiled the project under compilation mode "Release" + "Default" , then connected using B4A bridge , so after compiled , it will installed but when open , it will have...

www.b4x.com

You can apparently force normal assets behaviour by the IDE attribute
#DebuggerForceStandardAssets: True
But this is only necessary for libraries that try to load files from DirAssets, otherwise it should not be needed.

what #DebuggerForceStandardAssets means?

hi everyone, does anyone know what #DebuggerForceStandardAssets: True means & what it really does?? when should I use it?

www.b4x.com

 

[emexes]

The device just executes a cutdown shell version of the app that mainly contains UI code to interact with the user.

Well, I didn't see that coming.

 

[drgottjr]

one of my favorite sources for bedtime reading is core.jar from b4a's core libraries. in it you can see referenes to the
virtual assets folder and how access to dirassets is governed by whether or not the virtual assets folder exists (which it would
in debug mode)

 

[AlexOfOz]

As promised, after replacing 2 of the files, adding a new one and deleting an existing one, I have compiled with DEBUG. Sadly there is no discernible pattern. Just focussing on the one that I deleted, that still exists in DirAssets, and because I copy the contents file by file, it also exists in DirInternal.

NOTE - I did not restart my phone, or uninstall the program from the phone, which are vital aspects of this investigation.

After compiling with RELEASE, that same file is now gone from DirAssets, which appears to have been entirely rebuilt. The deleted file is still showing in DirInternal, so is a sticky file in DirInternal, but not DirAssets.

My expectation is that if I uninstalled the program from the phone, then compiled again with RELEASE, DirInternal would be blown away and rebuilt from scratch. I'll do that later to check.

 

[emexes]

@AlexOfOz could you please check if the "sticky files in File.DirAssets" issue on your setup goes away when compile in Release mode?

After compiling with RELEASE, that same file is now gone from DirAssets, which appears to have been entirely rebuilt.

Well, that was a humdinger.