New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We need bug 263 fixed from JxCore #7

Open
yaronyg opened this Issue Jun 16, 2015 · 10 comments

Comments

Projects
None yet
4 participants
@yaronyg
Member

yaronyg commented Jun 16, 2015

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

This comment has been minimized.

Show comment
Hide comment
@obastemur

obastemur Jun 16, 2015

Member

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

Member

obastemur commented Jun 16, 2015

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

@obastemur obastemur closed this Jun 16, 2015

@obastemur obastemur removed the ready label Jun 16, 2015

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jun 16, 2015

Member

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.

Member

yaronyg commented Jun 16, 2015

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 yaronyg reopened this Jun 16, 2015

@obastemur

This comment has been minimized.

Show comment
Hide comment
@obastemur

obastemur Jun 17, 2015

Member

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

Member

obastemur commented Jun 17, 2015

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

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jun 18, 2015

Member

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.

Member

yaronyg commented Jun 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@obastemur

obastemur Jun 18, 2015

Member

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.

Member

obastemur commented Jun 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jun 22, 2015

Member

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.

Member

yaronyg commented Jun 22, 2015

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 yaronyg added the 1 - Backlog label Nov 18, 2015

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jan 5, 2016

Member

Is this bug resolved by Mobile.getDocumentsPath?

Member

yaronyg commented Jan 5, 2016

Is this bug resolved by Mobile.getDocumentsPath?

@deadlyfingers

This comment has been minimized.

Show comment
Hide comment
@deadlyfingers

deadlyfingers Jan 7, 2016

Member

@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.

Member

deadlyfingers commented Jan 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@vjrantal

vjrantal Jan 7, 2016

Member

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

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.

Member

vjrantal commented Jan 7, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@vjrantal

vjrantal Jan 7, 2016

Member

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

Member

vjrantal commented Jan 7, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment