Android File I/O is Wonky

[danzeeeman]

I'm able to sometimes save files and sometime open files. I really don't like the hacky zip file approach that was taken to adding resources to the app. We should restructure this part of ofxAndroid.

[danoli3]

Have experienced some issues with File I/O, however isolated to when building with OSX for a specific project.

Would love if we could get Poco::Zip working with Android.

[bilderbuchi]

@openframeworks/android, any input?

[HalfdanJ]

I've been playing with changing it from our hacky zip solution that stores the files in /res/raw, to instead copy the files to /assets/data. This folder gets automatically copied recursively, and i've then made some java code that copies all the files from assets to the current directory, just like the unzipping does currently.

HalfdanJ@ede20f7

I'm using it personally right now in my projects, and it works very well. The build time is faster, the apk size is the same (since the apk is a zip folder anyway), and I can easily temporarily ignore an asset so it doesn't get copied every time I build (very very useful for large assets, since they are already on the device anyway)

[julapy]

@HalfdanJ wow that sounds awesome... its very similar to the way it is done on iOS using the rsync command.

im not qualified enough to review the code but it sounds like a great improvement.

cc @arturoc - worth a PR?

[arturoc]

yes i've used this before, i believe there's even an ndk api that allows to access the assets in their original location so there wouldn't be any need for copying them or any extra code in the java side. I think all we would need is to wrap that api in ofToDataPath.

I want to merge first @talavi's refactor but would be great to look into this

[danzeeeman]

should we just switch over to OBB files? They are made for shipping large
assets to APKs.

http://developer.android.com/google/play/expansion-files.html

On Fri, Nov 20, 2015 at 9:36 AM, arturo notifications@github.com wrote:

yes i've used this before, i believe there's even an ndk api that allows
to access the assets in their original location so there wouldn't be any
need for copying them or any extra code in the java side. I think all we
would need is to wrap that api in ofToDataPath.

I want to merge first @talavi's refactor but would be great to look into
this

—
Reply to this email directly or view it on GitHub
#2995 (comment)
.

[HalfdanJ]

Interesting with the OBB. Seems like the 'proper' way to go. Only, it seems like it becomes harder to share an APK file, since then it will also have a OBB file that manually has to be put the right place (unless its downloaded from play store), so its an annoying way to go if all thats in the OBB is a font or simple texture. The right might be a combination with different gradle tasks for packaging the data folder in different ways depending on the situation?

[arturoc]

this is the assets api in c

https://developer.android.com/ndk/reference/group___asset.html

i didn't remember that it had special functions to read files... so it wouldn't be as easy as wrapping it in ofToDataPath but it would allow to copy from c++ instead of from java

[HalfdanJ]

@arturoc i'm not sure if its a benefit to move the file copying to c++. Its a very os specific task, and the java code has more helpers for doing it correctly. Do you see other benefits in the c++ solution?

[arturoc]

no not really, whatever is easier. i thought the c++ api would give you a path were the assets were stored but all it gives is some functions to use similar to the c api for reading plain files but not fully compatible, so if it's easier to get right in java i guess better to do it there.

the only possible advantage would be if we want to have a native activity at some point with no java at all. i think @tallavi has a native activity example in his refactor branch, not sure how he's solved this

[danzeeeman]

Look at the Tango C examples. They have a good way of accessing files via
the C Api.

On Wednesday, November 25, 2015, arturo notifications@github.com wrote:

no not really, whatever is easier. i thought the c++ api would give you a
path were the assets were stored but all it gives is some functions to use
similar to the c api for reading plain files but not fully compatible, so
if it's easier to get right in java i guess better to do it there.

the only possible advantage would be if we want to have a native activity
at some point with no java at all. i think @tallavi
https://github.com/tallavi has a native activity example in his
refactor branch, not sure how he's solved this

—
Reply to this email directly or view it on GitHub
#2995 (comment)
.

Sent from Gmail Mobile #autocorrect

[arturoc]

the problem with the c api is that sometimes we don't have control over loading files like in ofImage and it would require wrapping it in ofFile... which would be too much so copying the files is probably the best solution

[tallavi]

My native activity example in my life cycle branch is to demonstrate java only activities (without OF), not c++ only activities. I'm not sure I even understand the meaning of c++ only activities (from Android's perspective).

And yeah, the solution by @danthemellowman sounds awesome, and it would be very nice if it could happen AFTER the life cycle stuff is merged, as it touches the exact same places. :-)

[arturoc]

ah, ok, we should change it's name then since a NativeActivity in android is a type of activity that has only native (c/c++) code: https://developer.android.com/reference/android/app/NativeActivity.html

[tallavi]

Yeah, how would you call it?

The word native is ambiguous. Some people use the word native for the c++ part as opposed to the java, but I usually use it for the java part (as opposed for an openGL UI or web based UI).