Adobe AIR Development

[DachFlach]

Is the userDirectory available?

I know applicationStorageDirectory is.

If userDirectory is available, what would its path be?

[JRab]

hey dachflach,

according to File.userDirectory.nativePath the userDirectory refers to the /root directory. I dont know how that will hold up later down the road because it seems odd like an odd place to map it to. but for now thats where it stands. Also note when you perform the documentsDirectory or desktopDirectory it builds off of the /root directory. I also can confirm you can create and copy files into that directory in the simulator. But again i dont know how it will hold up in the real playbook. Hope that helps!

[DachFlach]

Thanks for the heads up on the potential problems down the road.

Isn't the applicationStorageDirectory also under the users folder structure as well..  ( appData/roaming on windows)?

Can anyone from RIM expand on this? ( no offense intended JRab, just looking for more info ).

Are the userDirectory, documentsDirectory and desktopDirectory considered unsafe?

Do they have a future?

My implementation is as such:

I create local Databases that hold users of an app and their details. These Users can then be added to a remote database to combine with other Users on other tablets.

Now, I can handle that from a DB stored in applicationStorageDirectory but I fear for loss of data upon reinstallation of the app  and  I believe the applicationStorageDirectory is harder for a User to navigate to.

I also store images and various other files with the AppDirectory I create within the userDirectory. This location is easy to find on desktop OS so I am hoping it is as well for this OS.

Any more elaboration welcome.

[peter9477]

If those folders point to "/root" now as JRab says, chances are the OS devs have crudely got all apps running as "root" for now, whereas in future possibly (I think probably) each app will get its own userid to protect apps and their data from each other. As for the fears you describe, I think applicationStorageDirectory is exactly what you are supposed to use here. For one thing it's supposed to be safe during upgrades (as the app data is installed into applicationDirectory). It's up to your own app to overwrite/initialize data in the app-storage folder if it's not already there. For another thing, the data you describe doesn't sound like something the user should be "navigating to" outside of your app (even assuming there is any standard way to "navigate" to a folder like that in the PB). See http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/filesystem/File.html for more background including some advice on which of those static properties to use for different situations.

[DachFlach]

I was hoping to be able to transfer files from a directory on the PB to a USB connected desktop or laptop.

Navigating ( from the desktop ) to the userDirectory would be easier than to the applicationStorageDirectory.

The files could be anything from text files to images to wav files.

A confirmation on using userDirectory files now and in the future would still be nice.

Personally, I do not need to have multiple Users..  so is Root such a bad thing?

[peter9477]

I'm not aware of any information published yet as to the locations within the PB filesystem of either userDirectory or applicationStorageDirectory, so I can't really say whether it would be "easier" to navigate there using an attached PC. I wouldn't make any assumptions about where those are based on knowledge of Windows (or Mac), however, so I can well imagine it might be the other way around - easier to find the app folder. As for "multiple users", I'm not referring to multiple people using the PB, but having different applications install under different automatically-generated userids. QNX is a Posix system, so it can be configured so an app running with one userid cannot access the data of a different app running under another userid, if they choose to do things that way. Given the BB focus on security and the enterprise I'm guessing they'll do something like that. As for your immediate needs, since the devs aren't saying quite yet, just make some sort of global variable that you point to userDirectory for now, and if that's not available later you can easily change it to be one of the other standard places, and your whole app will be affected at once.

[jtegen]

Probably already know this, but in case for newbies.  Dont hardcode path names.  Leverage the File standard directories every time.  If the implementation for one changes from /root, then nothing in your application will change.  If they do change where physically a directory exists, the OS upgrade will certainly move relatvent files.

As to USB connection to the PB from a desktop to transfer files.  Nothing has been said that currently exists.  Assume that it would since BB does that will cell phones, but currently nothing has been officially mentioned about interoperability between PB and desktop yet (obviously if some knows more, please correct me).

[DachFlach]

"just make some sort of global variable that you point to userDirectory for now"

Isn't userDirectory that itself?  Or do you mean bring in a remote path name or hard code one in the app ( read previous post ).

What I planned to do was use  userDirectory as the root for the app folder where the files and other folders would be created inside of. Leveraging the FILE standard directories as mentioned.

"If they do change where physically a directory exists, the OS upgrade will certainly move relatvent files."

That statement seems promising. Any files created before an OS change would be moved to the appropriate new location. Is there any reason to believe this would not be so?

Another reason to store files in userDirectory ( or documentsDirectory, desktopDirectory )  is so that files can be shared across applications. For example, if a suite of tools ( each an individual app ) have reason to utilize files created from other apps, this can be done by storing them in those folders. And from what I am gathering, might not be achievable by using the applicationStorgaeDirectory.

Any thoughts on that?

Dach

[peter9477]

---

DachFlach wrote:

"just make some sort of global variable that you point to userDirectory for now"

Isn't userDirectory that itself?  Or do you mean bring in a remote path name or hard code one in the app ( read previous post ).

What I meant was, instead of possibly sprinkling File.userDirectory around your code, you could define something like a "myAppDirectory = File.userDirectory" at startup in one place, and use myAppDirectory everywhere else. Then at a later time, if improved docs say "userDirectory will be null on PB, use applicationStorageDirectory" you have only one change to make. The thing is, there are probably hundreds of RIM and QNX devs working very hard trying to resolve all these things before launch, and none of us can say for sure what will happen between now and then with all these little details. Be agile, plan for numerous small changes.

DachFlach wrote:

Another reason to store files in userDirectory ( or documentsDirectory, desktopDirectory )  is so that files can be shared across applications. For example, if a suite of tools ( each an individual app ) have reason to utilize files created from other apps, this can be done by storing them in those folders. And from what I am gathering, might not be achievable by using the applicationStorgaeDirectory.

As your final paragraph, I agree that's the purpose of userDirectory.  Your description of the data involved, however, seemed to fit more closely with the purpose of applicationStorageDirectory as it sounded like the application's data rather than the user's data, even if it involves data about the user.  You know best how it will be used, so if you understand the distinction between those two things, I'm sure you'll pick the best thing based on what we know now.  And do what I suggest above and you won't be slowed down if the final setup is not what you expected.

(Edited to better show who actually wrote what. Sorry about that.)

[jtegen]

I read "hard coded" to something like "/root/myfile.db" (bad).  Your suggestion of referencing user data from a File native path sounds good.

File.applicationStorageDirectory is typically for application specific things that the user would not interact or even know about like preferences.  If an application updates, it may replace/update files in that location upon first run, so keeping users out of this directory would be important.

If you're storing data with SQLite, it is a good practice to maintain a version of the file as it relates to your schema.  I've added "info" table that maintains 1 record of information about the schema, so if the shema changes, then your application has the knowledge to update older versions of the file.