We need bug 263 fixed from JxCore

[yaronyg]

jxcore/jxcore#263

We need this for the postcard app so that we can store our DB in a permanent safe location on both Android and iOS

[obastemur]

That is already implemented (as mentioned from emails) os.tmpdir

[obastemur]

That is already implemented (as mentioned from emails) os.tmpdir

[yaronyg]

But tmpdir's functionality is explicitly to provide a location where temporary files are to be kept. Temporary as in "the OS can delete them if it needs space". That is not the semantic we need.

What we need is a 'permanentdir'. That is, a location where the application can store data secure in the knowledge that the only way the data can be deleted is if the app is uninstalled or the app deletes it itself.

In Android this is the difference between getCacheDir() and getExternalFilesDir(). In fact you can argue that there should really be three APIs. One for temporary files (getCacheDir), one for app private files (getExternalFilesDir) and one for shared files (getExternalStoragePublicDirectory). But for right now we just need app private.

[yaronyg]

But tmpdir's functionality is explicitly to provide a location where temporary files are to be kept. Temporary as in "the OS can delete them if it needs space". That is not the semantic we need.

What we need is a 'permanentdir'. That is, a location where the application can store data secure in the knowledge that the only way the data can be deleted is if the app is uninstalled or the app deletes it itself.

In Android this is the difference between getCacheDir() and getExternalFilesDir(). In fact you can argue that there should really be three APIs. One for temporary files (getCacheDir), one for app private files (getExternalFilesDir) and one for shared files (getExternalStoragePublicDirectory). But for right now we just need app private.

[obastemur]

maybe JXcore needs a new internal submodule named 'mobile' and provide all these stuff there ?

[obastemur]

maybe JXcore needs a new internal submodule named 'mobile' and provide all these stuff there ?

[yaronyg]

I don't think I would call it 'mobile'. We are going to face similar issues when we build apps on JXCore on the desktop. How about 'app'? Anyone building an app on mobile or desktop is going to have to deal with this.

[yaronyg]

I don't think I would call it 'mobile'. We are going to face similar issues when we build apps on JXCore on the desktop. How about 'app'? Anyone building an app on mobile or desktop is going to have to deal with this.

[obastemur]

Anyone building an app on mobile or desktop is going to have to deal with this.

Makes sense. However on desktop, the application is able to use USER's home folder. for such stuff. This is kind of cross platform on desktop. Mobile side is a mess.

[obastemur]

Anyone building an app on mobile or desktop is going to have to deal with this.

Makes sense. However on desktop, the application is able to use USER's home folder. for such stuff. This is kind of cross platform on desktop. Mobile side is a mess.

[yaronyg]

But even there do we want people writing apps to have to figure out if their app is on PC or mobile? In other words, someone should be able to write code using JXCore that "just works". If they ask for a place to persistently store user specific data the JXCore defined API should give them an answer. If they are on the desktop that can be the user's home directory and if on mobile it can be whatever its appropriate. But the point is that the developer doesn't care if their code is being run on the desktop or mobile or in the cloud. They just call the JXCore provided API and get the right place to put information.

[yaronyg]

But even there do we want people writing apps to have to figure out if their app is on PC or mobile? In other words, someone should be able to write code using JXCore that "just works". If they ask for a place to persistently store user specific data the JXCore defined API should give them an answer. If they are on the desktop that can be the user's home directory and if on mobile it can be whatever its appropriate. But the point is that the developer doesn't care if their code is being run on the desktop or mobile or in the cloud. They just call the JXCore provided API and get the right place to put information.

[yaronyg]

Is this bug resolved by Mobile.getDocumentsPath?

[yaronyg]

Is this bug resolved by Mobile.getDocumentsPath?

[deadlyfingers]

@yaronyg yes Mobile.getDocumentsPath works for mobile (iOS and Android).

However when running localhost on (Mac) desktop we are stilling saving to "/var/folders/x1/jpw2brwx4zl3bgd7753bvf8r0000gn/T/" but we should probably be using ~/Library/Application\ Support/org.thaliproject if we want to be sandbox ready on Mac also.

[deadlyfingers]

@yaronyg yes Mobile.getDocumentsPath works for mobile (iOS and Android).

However when running localhost on (Mac) desktop we are stilling saving to "/var/folders/x1/jpw2brwx4zl3bgd7753bvf8r0000gn/T/" but we should probably be using ~/Library/Application\ Support/org.thaliproject if we want to be sandbox ready on Mac also.

[vjrantal]

I had a bit similar issue and I solved it like this

Thali_CordovaPlugin/test/www/jxcore/lib/MobileUsingWifi.js

Line 146 in 506d75f

callback(null, testUtils.tmpDirectory());

(look at the implementation in testUtils how it is done). This allows running multiple independent instances of the app on the same machine. However, in your case, you might not want to auto-clean the folder after the app exists, which is something I had to do since I didn't want to persist data between test runs.

Overall, I'd suggest we close this issue and do remaining work elsewhere.

[vjrantal]

I had a bit similar issue and I solved it like this

Thali_CordovaPlugin/test/www/jxcore/lib/MobileUsingWifi.js

Line 146 in 506d75f

callback(null, testUtils.tmpDirectory());

(look at the implementation in testUtils how it is done). This allows running multiple independent instances of the app on the same machine. However, in your case, you might not want to auto-clean the folder after the app exists, which is something I had to do since I didn't want to persist data between test runs.

Overall, I'd suggest we close this issue and do remaining work elsewhere.

[vjrantal]

And just realized that my issue in above comment was very different from this one since it doesn't relate to sandboxing requirements 😃

[vjrantal]

And just realized that my issue in above comment was very different from this one since it doesn't relate to sandboxing requirements 😃