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

 

[AlexOfOz]

Quite frankly emexes, I can't see any rhyme or reason to how all of this works. As I do a ListFiles of both DirAssets and DirInternal, I can see that even the format of the file listing changes.

I'm not for a moment saying that there's something wrong with the B4* process, just that the results appear flexible and tracking it all and coding based on past experience may fail due to changes in the Directory. I'm currently facing that situation right now, where I have to adjust my coding for the first file in DirInternal, because the leading characters in a ListFiles now have differences compared to previously. Yes, I have uninstalled and compiled again.

I'll keep plodding along and post a note for anything of significance that I might find.

 

[emexes]

Yes, I have uninstalled and compiled again.

Are you calling me predictable?!?! ?

 

[emexes]

I have to adjust my coding for the first file in DirInternal, because the leading characters in a ListFiles now have differences compared to previously.

Do you have an example of that? Is it just an upper/lower-case difference? Are the files also in a different order?

I agree that's not what you'd expect in an ideal world but, as a programmer firned of mine used to say several times a day: yeah, you get that* sometimes.

Presumably having some file-systems case-sensitive and some not, isn't helping. But hey, if you code to handle both cases, then it will probably be more robust and cross-platformable too. ?


* you get that as in that happens, not get as in understand

 

[AlexOfOz]

Do you have an example of that? Is it just an upper/lower-case difference? Are the files also in a different order?

I agree that's not what you'd expect in an ideal world but, as a programmer firned of mine used to say several times a day: yeah, you get that* sometimes.

Presumably having some file-systems case-sensitive and some not, isn't helping. But hey, if you code to handle both cases, then it will probably be more robust and cross-platformable too. ?


* you get that as in that happens, not get as in understand

Yep, I'm learning new stuff every minute that I play with this. I have already started coding for exceptions, which of course leads me to think of other ways I might not have to do so in the future.

Oh, and the differences are related to the leading characters in the DirInternal. Back in the good ol'days - 48 hours ago - the leading characters included a "[" immediately before the first file. Now, after blowing it all away and uninstalling and re installing the program, that square bracket isn't there any more. I'm not going to surmise anything, because there are too many moving parts in this picture, but I do now know that I need to code in such a way that it's going to find the first file regardless of the meta coding of DirInternal.

As for duplicates and files that no longer exist showing up in DirAssets, my thoughts are that until you uninstall the program and/or restart your phone, the DirAssets is accumulative, meaning it just keeps accepting what the latest compile sends to it, probably replacing identically name files.

Finally, as for DEBUG performing differently to RELEASE, that became perfectly clear due to the time required before the program started running. The files I'm dealing with, both jpg and m4a, are quite large, so they take time to download etc. I have the benefit of a calm time between starting the compile and the program being ready to run, and the calm time is different between DEBUG and RELEASE.

Finally, finally, my next focus is going to be how to enable the program to stay alive and ready for action, even after the home screen has gone to sleep. I'm now digging into ACTIVITY_RESUME and ACTIVITY_PAUSE to learn stuff.

 

[emexes]

Back in the good ol'days - 48 hours ago -

?

the leading characters included a "[" immediately before the first file.

That sounds more like a presentation/formatting issue, where a List has been cast (converted) into a String.

edit: although I thought it was Array that acquired square brackets and commas when converted to String, and that List just showed up as an Object memory address or id number.

'Log expects String, so the supplied List is automagically converted into a (single and probably long) string
Log(File.FileList)   
Log("BEFORE " & File.FileList & " AFTER")

'cf Logging List elements one-by-one
Dim TempList As List = File.FileList
For I = 0 to TempList.Size - 1
    Log(I & Tab & TempList.Get(I))
Next

 

[emexes]

Quite frankly emexes, I can't see any rhyme or reason to how all of this works.

After a bit more playing around this morning and swapping back and forth between Debug and Release modes... I am coming around to your perspective. ?

Still, better too many files than too few.

 

[emexes]

It seems we are on a path already travelled:

https://www.b4x.com/android/forum/threads/file-listfiles-file-assets-in-debug.134465/

 

[AlexOfOz]

It seems we are on a path already travelled:

https://www.b4x.com/android/forum/threads/file-listfiles-file-assets-in-debug.134465/

Wow, that is amazing, and eerily familiar. I've been doing a ListFiles of DirAssets, but into a flat string file, then scanning that to pick out the real files I want, then copying them across to DirInternal.
Thanks for finding that thread.

 

[emexes]

that is amazing, and eerily familiar

I think I discovered an extra bonus this morning: files from a different project appeared in Debug mode File.DirAssets. That certainly imparted upward movement to my eyebrows. I'll have another go this evening of finding where the files are actually stored. They don't seem to be in the Debug mode APK which suggests they're not on the Android device. Also both projects were using the same default #ApplicationLabel: B4A Example

And for months I've been having heaps of instances of missing and repeated Log lines = I'm starting to wonder if that might be related. Hmm, it just occurred to me that that started around the time that we changed ISP and got a new router and had to install a wifi repeater for some older devices to work (for some reason, they don't see the new router), so maybe there are some duplicated/echoed packets bouncing around... ? but on the other hand web browsing and downloading is working great, so... then again, B4A Bridge is probably using UDP rather than TCP so...

And somehow I didn't see this yesterday:

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.

in which the key nuance might be that "should not" <> "is not" ? (but likewise: "can apparently" <> "can" ?)