Thanks. I'll give that a try.
Chris
On Sep 10, 2012, at 9:19 AM, John Dixon wrote:
>
>
> Chris...
>
> Have a read of 'file Attributes' on page 23 of the iOS release notes... If I
> understand this correctly, you can happily save your 'stuff' in the
> 'documents' folder and using the 'ipho
Chris...
Have a read of 'file Attributes' on page 23 of the iOS release notes... If I
understand this correctly, you can happily save your 'stuff' in the 'documents'
folder and using the 'iphoneDoNotBackUpFile' function set a flag as to whether
things should be backed up to icloud/itunes or n
FlexibleLearning wrote:
For those who have gone before those who have gone before...
What sort of files does Apple allow to be downloaded? 'text' only files?
Defined by type of file (video, pdf etc)? Is there such a list?
I think I have established that 'executable' files will be rejected (i.e
For those who have gone before those who have gone before...
What sort of files does Apple allow to be downloaded? 'text' only files?
Defined by type of file (video, pdf etc)? Is there such a list?
I think I have established that 'executable' files will be rejected (i.e.
stack files) which is a
You may just set the attribute of a folder and not bother with individual files.
According to apple:
Starting in iOS 5.0.1 a new “do not back up” file attribute has been introduced
allowing developers to clearly specify which files should be backed up, which
files are local caches only and subj
On 7/25/12 9:12 PM, ddas wrote:
They will notice and they will reject your app.
The only way around is to set the extended attribute of your folder
in the documents folder to "do not back up."
The engine lets us do it by file, which would be fine for my purposes.
Just out of curiosity, does a
It's in the engine now.
On 26/07/2012, at 12:12 PM, ddas wrote:
> They will notice and they will reject your app.
>
> The only way around is to set the extended attribute of your folder in the
> documents folder to "do not back up."
> I brought up this issue in December. However it seems like
They will notice and they will reject your app.
The only way around is to set the extended attribute of your folder in the
documents folder to "do not back up."
I brought up this issue in December. However it seems like the prob has been
recently solved by mergext.
http://mergext.com/home/merg
Thanks for all the suggestions everyone. If the cache is unlikely to get
erased very often then I think the simplest thing is to just use that.
BTW, Chipp, I wasn't too worried about the file storage not working, I
was concerned that Apple would reject the app for storing data in
Documents if
Hi Jacque,
I'm storing everything in documents-- in fact I have my own "cache" folder
in there as well. Because of my workflow, constantly updating via DropBox,
I tend not to 'include' files outside a single stack, and I use the stack
to SpitOut on OpenStack different resources, such as template d
I use the cache folder, the assumption being that is fairly unlikely that it
will be cleared.
Terry...
On 26/07/2012, at 05:35 AM, Monte Goulding wrote:
> Hmm... Do you mean backed up as in iTunes/iCloud? That would appear to be
> unnecessary. I think cache is only cleared in low storage situa
Jacque,
I'm storing an SQLite db in the documents folder so the Android and iOS code
is the same. The db is static until an update. The update will replace the
entire db with new data. There is also 2 other dbs in the doc folder. One db
hold the registration info and the other is notes the user ca
Hmm... Do you mean backed up as in iTunes/iCloud? That would appear to be
unnecessary. I think cache is only cleared in low storage situations so it
might be appropriate from the users perspective. Otherwise I'd go with
documents folder with the do not backup property set.
Cheers
--
M E R Goul
13 matches
Mail list logo
