Thanks for the answer, but you’re missing the point. I have trouble in this:
for file in lfs.dir(Spath) do if file ~= "." and file ~= ".." then table.insert(socketArray, file) end end
There is just no such directory for lfs.dir().
You may be running into the fact that system.ResourceDirectory isn’t a real thing on Android. See:
https://docs.coronalabs.com/api/library/system/pathForFile.html
And read the “Android File Restrictions” section.
Rob
I could be wrong because I’ve never done it the way you’re doing, but I don’t think you can use “system.pathForFile()” with an arbitrary folder as the target. I think it expects an actual file, which you haven’t specified in your “Spath” assignment.
Brent
But somehow widget.newButton() can use files, which contains in another directory, but still inside system.ResourceDirectory. Is widget image uploader works by another way, or I’m doing something wrong with lfs?
I think you’re wrong, because Corona documentation (https://docs.coronalabs.com/api/library/system/pathForFile.html) says, that it can be file, or path to directory, so my solution is fine. I guess so, at least.
Hmmmm… all indications so far seem to point to Rob’s advice about the Android file restrictions in the Resource directory, especially since it appears that you’re looking for PNG files and “.png” is one of the restricted types.
Probably the easiest way to confirm this is to drop a text file like “test.txt” into that folder and then call this in an actual Android build:
[lua]
Spath = system.pathForFile(“images/sockets/sockets/test.txt”)
print( Spath )
[/lua]
If that works, then try it with a PNG file which also exists in the folder, for example:
[lua]
Spath = system.pathForFile(“images/sockets/sockets/a1.png”)
print( Spath )
[/lua]
If the first case works and the second doesn’t, it’s likely a file type issue on Android specifically in the Resource directory when using file/IO-based calls like “system.pathForFile()”, since .txt is not a restricted type but .png is.
Best regards,
Brent
Tested out. BOTH WORKS! It finds and prints on screen path to txt and png. But lfs doesn’t see it! I’m clearly confused and still think, that problem is in lfs.
Thx
Do you have a simple test I can try? Like the most basic possible code sample you can create? I can try it on an Android device to see what happens. Email is brent (at) coronalabs (dot) com.
Brent
I did sent you yesterday simple test, what do you say?
I haven’t tested it yet. Can you actually send me the Lua code and not the built .apk? Thanks.
Sent.
Thx
OK, I tested it and I’m getting the same basic results. This is what Rob and I suspected: an issue with Android not having a technical “Resources” directory and thus there’s limited file I/O access on Android with the file types listed in the docs. Corona display.* APIs gain access to these (it’s a pretty fundamental need) but trying to use LFS has limits on Android when trying to traverse the Resources directory.
Fortunately, there are potential solutions:
-
When the app starts, you could copy all of the image files from the Resources directory to the Documents directory. There’s an example of how to do that here. But, I can’t highly recommend that because you’ll end up duplicating potentially many image files and the app size will grow. That leads me to idea #2…
-
Maintain a simple SQLite database or JSON file with the image files you’re bundling inside your “sockets” directory. Since you’ll be shipping those images with the app, you’ll always have a predictable list which you can maintain, and since Resources is read-only, it will never change after the app is built/installed. With that SQLite/JSON, forget using LFS entirely and just loop through or search the list for the names and then display them using “display.newImage()” or whatever.
I know it’s not ideal, but hopefully this helps somewhat.
Brent
Big thanks for your time, I probably will use your second solution with JSON file, but can you explain to me, why there simply isn’t such a function which will parse folders, in case you have API permission?
Great thanks
You can also store the list of file names in a lua table inside the module where you need it. It will save you a little more overhead of not having to open a file and read the data in.
As far as why there isn’t a simple function, because Google made Android APK’s a zip file and they don’t unzip it to the file system, rather they expect the app to extract the files that it needs on the fly. I guess its their way of keeping the app size a bit smaller. LFS needs a file system to work on and there simply isn’t one for the APK’s resources.
Rob
Man, it is tough adapting my code for Android. The only way to find out what’s not working is to run on device, since the simulator won’t throw errors where an Android would.
I wish (!!!) Corona would figure a way to simulate LFS on Android. This sucks.
Have you tried using “Live Builds”?
Question: What about some code that built directory files in each directory in simulator, then a patch to LFS? That would simulate a lot of LFS, wouldn’t it? Is that a crazy little chunk o’ code to come up with? That would allow us to check for any file we wanted (that we created), etc.
Have you tried live builds? Its lets you edit your Lua code and just like the simulator updates, once on start a live build based on-device build it will update just like the simulator does except you get live device testing without having to constantly re-install to the device every build.
See: https://coronalabs.com/blog/2016/12/02/sneak-peek-corona-live-builds/
This can really make your device required testing a glorious experience.
Rob
Rob, I did get the live builds working, it is much easier to work with. However, once I compiled the app not as a live build, it failed again. I suspect live builds is giving me different results to the live app, esp. when it comes to trying to read the list of directories in a directory.
I actually dumped my old fixes when live build starting showing results…then discovered I’ll have to recreate them! Argh!
The results below show (to me) that the Live Build reads subdirectories using LFS, while the non-Live Build does not.
Live Build Results:
Oct 11 12:27:56.167 d) Checking for built-in books in _user/books
builtInOtherShelvesPath = _user/books
Yes, found the doc_path, checking for files
Oct 11 12:27:56.167 Check . inside _user/books
Check … inside _user/books
Check .DS_Store inside _user/books
Check books.txt inside _user/books
Check point-lobos-ecosystem inside _user/books
OK, now check _user/books/point-lobos-ecosystem
isShelfItem(): Does this file exist? _user/books/point-lobos-ecosystem/item.json
Oct 11 12:27:56.167 yes _user/books/point-lobos-ecosystem/item.json
Oct 11 12:27:56.168 Found a shelf item! _user/books/point-lobos-ecosystem
Build & Download Results:
10-11 10:30:05.413 24671 24687 I Corona : d) Checking for built-in books in /data/user/0/com.mimetic.dgross.photobook/files/coronaResources/_user/books
10-11 10:30:05.413 24671 24687 I Corona : builtInOtherShelvesPath = _user/books
10-11 10:30:05.413 24671 24687 I Corona : Yes, found the doc_path, checking for files
10-11 10:30:05.413 24671 24687 I Corona : Check . inside _user/books
10-11 10:30:05.414 24671 24687 I Corona : Check … inside _user/books
10-11 10:30:05.414 24671 24687 I Corona : Check books.txt inside _user/books
Indeed. Live Builds file structure have some differences compared to regular build. Live build assets are not compiled as they would be in regular build - this may simply not be possible sometimes. I will take a look if there something we can do to make behavior more similar.
Man, it is tough adapting my code for Android. The only way to find out what’s not working is to run on device, since the simulator won’t throw errors where an Android would.
I wish (!!!) Corona would figure a way to simulate LFS on Android. This sucks.