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

Does getDocumentsPath return app only storage? #42

Open
yaronyg opened this Issue Jul 21, 2015 · 8 comments

Comments

Projects
None yet
5 participants
@yaronyg
Member

yaronyg commented Jul 21, 2015

In Android there is an idea of storage that just belongs to an app and "general storage" that any app with local read permissions can get to. I don't know if iOS has a similar feature.

Does getDocumentsPath return app specific storage or general storage? This matters in our case because we are storing private keys and we need to make sure they aren't in general storage.

@obastemur

This comment has been minimized.

Show comment
Hide comment
@obastemur

obastemur Jul 22, 2015

Member

iOS part is app/user specific that other apps/users has no access.

Member

obastemur commented Jul 22, 2015

iOS part is app/user specific that other apps/users has no access.

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jul 22, 2015

Member

What about Android?

Also it would be really good to call these issues out in your documentation so that programmers understand what they are getting when they call this function.

Member

yaronyg commented Jul 22, 2015

What about Android?

Also it would be really good to call these issues out in your documentation so that programmers understand what they are getting when they call this function.

@obastemur

This comment has been minimized.

Show comment
Hide comment
@obastemur

obastemur Jul 22, 2015

Member

Android also returns app specific path but the level of isolation is questionable comparing to iOS.

Member

obastemur commented Jul 22, 2015

Android also returns app specific path but the level of isolation is questionable comparing to iOS.

@plika

This comment has been minimized.

Show comment
Hide comment
@plika

plika Jul 22, 2015

@yaronyg docs are updated. Thanks

plika commented Jul 22, 2015

@yaronyg docs are updated. Thanks

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jul 23, 2015

Member

@plika and @obastemur thanks for the clarification but as I explain in jxcore/jxcore-cordova#52 I think the behavior still isn't quite right.

Member

yaronyg commented Jul 23, 2015

@plika and @obastemur thanks for the clarification but as I explain in jxcore/jxcore-cordova#52 I think the behavior still isn't quite right.

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Jul 14, 2016

Member

We need to fix this for iOS as well. We need the ability to pick the right directory on iOS so that we can choose if we want a location that is backed up or not. So we need an API that is iOS aware.

Member

yaronyg commented Jul 14, 2016

We need to fix this for iOS as well. We need the ability to pick the right directory on iOS so that we can choose if we want a location that is backed up or not. So we need an API that is iOS aware.

@mohlsen

This comment has been minimized.

Show comment
Hide comment
@mohlsen

mohlsen Jul 14, 2016

Member

The problem we had for iOS with Mobile.getDocumentsPath was that it returned the /Documents directory. While Mobile.getDocumentsPath makes sense for that, we didn't want to put the pouchdb files in that location (it's meant for user files, not app created files). What we really wanted was to store the db files in the /Library location. So what we did was add this workaround for iOS (psuedo code)

if (ios) {
  path.resolve(os.tmpdir(), '..', 'Library');
} else {
  Mobile.getDocumentsPath(...)
}

Ideally, JXCore-cordova would keep Mobile.getDocumentsPath, and add Mobile.getAppStorage path or something. On Android, it would likely point to the same location as Mobile.getDocumentsPath (although there may be a better stop in newer versions).

As an added bonus while we are in this code, it would be beneficial to expose the cache directory too. For android, the cache dir = the temp dir, but on iOS, there is a specific location for this. So adding Mobile.getCachePath would be nice. We did this by manually building it, which is not a good thing. path.resolve(os.tmpdir(), '..', 'Library/Caches'). We could create a new issue for this if we want.

Here are Apple's docs on file locations.

Member

mohlsen commented Jul 14, 2016

The problem we had for iOS with Mobile.getDocumentsPath was that it returned the /Documents directory. While Mobile.getDocumentsPath makes sense for that, we didn't want to put the pouchdb files in that location (it's meant for user files, not app created files). What we really wanted was to store the db files in the /Library location. So what we did was add this workaround for iOS (psuedo code)

if (ios) {
  path.resolve(os.tmpdir(), '..', 'Library');
} else {
  Mobile.getDocumentsPath(...)
}

Ideally, JXCore-cordova would keep Mobile.getDocumentsPath, and add Mobile.getAppStorage path or something. On Android, it would likely point to the same location as Mobile.getDocumentsPath (although there may be a better stop in newer versions).

As an added bonus while we are in this code, it would be beneficial to expose the cache directory too. For android, the cache dir = the temp dir, but on iOS, there is a specific location for this. So adding Mobile.getCachePath would be nice. We did this by manually building it, which is not a good thing. path.resolve(os.tmpdir(), '..', 'Library/Caches'). We could create a new issue for this if we want.

Here are Apple's docs on file locations.

@yaronyg yaronyg added this to the V1 milestone Aug 3, 2016

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Sep 26, 2016

Member

Note that we don't actually choose where pouchDB goes. Whomever is calling Thali does. So while we should follow up on this to give good advice it is not a blocker for now. So off to icebox it goes.

Member

yaronyg commented Sep 26, 2016

Note that we don't actually choose where pouchDB goes. Whomever is calling Thali does. So while we should follow up on this to give good advice it is not a blocker for now. So off to icebox it goes.

@yaronyg yaronyg removed the 1 - Backlog label Oct 6, 2016

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