Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
Contributor
Posts: 10
Registered: ‎01-25-2011
My Device: Not Specified

Saving large files

Hi all,

 

I just had a quick question regarding saving large files to the device.

As far as I can tell: small amounts of data (like app config stuff) should use saved to local shared objects,

and if this dataset grows the sqllite api should be used; larger files like images that are only a couple of hundred KB (I'm guessing as to the exact size restriction) should be saved in applicatonStorageDirectory, but larger files should not be stored in applicationStorageDirectory, according to this article from the guys at Adobe.

 

My question is what to use if there are very large files (100+ mb) that need saving on the playbook.  

Highlighted
Developer
Posts: 350
Registered: ‎01-21-2011
My Device: Curve 8900 (Personal) / Bold 9650 (Work)
My Carrier: Regional

Re: Saving large files

You could use the fileReference.save function. Here's a tutorial that helped me. Though I will say in the Desktop test, it lets me choose where to save etc... but on the current 0.9.2 simulator it does not, just lets me give a name and click Save.  I'm assuming this is a limitiation of the existing simulator.

 

Hope this helps!

Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Saving large files

 


cyangreen wrote:

...  larger files like images that are only a couple of hundred KB ... should be saved in applicatonStorageDirectory, but larger files should not be stored in applicationStorageDirectory, according to this article from the guys at Adobe.

 

My question is what to use if there are very large files (100+ mb) that need saving on the playbook.


 

Actually the choice of where to save should not really be based on the size of the data, but rather the type of data.  If it's config stuff, yes, flash.net.SharedObject is pretty good, simple, etc.  I can't imagine app config stuff ever getting big enough to warrant moving to flash.data (the SQLite stuff).  That's more for tabular data, database-style stuff, where you have perhaps hundreds of records with many columns, sort of like having one or more sheets in a spreadsheet, likely interrelated.  It's more about the structure of the data here, not the size (though SQLite is likely overkill for, say, three records...).

 

For basic files, like images, the choice of where to save is based on whether the data is "local" to your application, and in effect "owned" by the app instead of by the user.  A photo, for example, is probably the user's photo whether your app generated it or not, unless for some reason you really don't want the user to be able to get that file out of your app and use it elsewhere.

 

Also, I wouldn't necessarily follow non-PlayBook AIR tips to the letter, as in the article you mention, though it would be pretty rude of you to have your app cache a 100MB file in applicationStorageDirectory, since the user has no way to get it out of there unless you provide a clear way to do it, and even then he/she has to remember that it's there... it can't be seen from outside of your app.  (I would expect the system to provide some sort of view or API to let us at least list which apps are installed, and how much local data they have.)

 

See this thread on the app sandbox filesystem layout for more, and please read the full thread and not just Elena's original post.  Also note the comments about the "tmp" folder, which would be appropriate for "cached" data, as the system would be allowed to delete it at will.  For non-cached data, if it's 100MB almost certainly you want the user to have full control over it, and put it in the userDirectory or a related one.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!