that is amazing, and eerily familiar
i'd like to know more about uploading files to a phone. that's an unusual twist.The uploading is working fine - no problem with that.
Thanks enormously. You have given me exactly what I was missing in my understanding.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.
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.
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.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
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.
File.Size()
doesn't work on DirAssets files. Bonus!Yes, I have a habit of finding these outlier situations.
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.
13) screen cap from updated (newly compiled) apk shows file not file.
I will repeat your process here.
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 will no doubt bump into another conundrum soon
The device just executes a cutdown shell version of the app that mainly contains UI code to interact with the user.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?