Believe it or not, Adobe has not made anything about this, and there are no plans to do so, either, so we have to rely in a third party (not developed by Adobe) native extension to set this attribute:

http://www.jampot.ie/ane/ane-ios-data-storage-set-donotbackup-attribut e-for-ios5-native-extension/

I think this should be natively implemented, since it's a requirement from Apple, not optional, maybe in the form of an attribute change method. If you agree, please vote here: https://bugbase.adobe.com/index.cfm?event=bug&id=3104319

Thanks for your reply. The problem is with data you never want purged such as files stored for offline viewing. Users do not want offline files to be automatically removed without any prior notice, even in low space conditions, because they want to access that content while there's no connection. That's the reason to use the DoNotBackup native API.

However, the article you link talks about "Application Support Directory" and says it's never purged under low memory conditions. This is the first time I hear about such a directory. The iOS Data Storage Guidelines never mention this:

https://developer.apple.com/icloud/documentation/data-storage/

So what's this directory and how do we access it?

Reading the document at the above link, it specifically says:

In iOS 5.0.1 and later, put support files in the <Application_Home>/Library/Application Support directory and apply thecom.apple.MobileBackup extended attribute to them. This attribute prevents the files from being backed up to iTunes or iCloud.

I don't see how Adobe considers this a solution. As I read this, it seems to imply you still need to mark the files or subfolder with the DoNotBackUp attribute.

Please correct me if I'm wrong.

I only know of one Native Extension for this (Jampot), but it doesn't have any documentation other than a silent YouTube video showing you only how to install the ANE.

Is there any other info you can provide regarding how we can set the DoNotBackUp flag for AIR for iOS?

Thanks.

Yeah, I checked it out. They talk about why we need it and what the ANE does, but there are no clear, specific instructions on how to implement it within a project. (And the sample file is a Flex project that I can't open in Flash CS6.)

Any chance one of you guys at Adobe could put together a tutorial for us noobs?

Thanks! Seems simple enough.

Pardon my ignorance, but does this flag need to be set each time the app is launched? Also, how do you test it out to see if it worked?

(In my case, I want to include a folder bundled within the app and marked "DoNotBackUp" which I can add downloaded media files and folders into. Not sure if I'm way off base on this...)

Hi,

Varun Bhatia wrote:

 

I am not aware of a way to check whether this ane worked or now. But you can compare the permissions of a backed up folder with a non backed up folder and caches folder.

But the application itself can't do this itself, correct? So if there's no way to check if "donotbackup" flag is true or not, then how do we avoid this method from being run each launch?

Thanks so much for helping me understand this concept!

Hi,

So here is how I understand this.

Based on the different articles on the web, the jampot extension sets the file attribute "com.apple.MobileBackup" to flag files and folders that you want to be excluded for backup. But for IOS 5.1 and above, you have to now set the "NSURLIsExcludedFromBackupKey" instead. We can still use the jampot extension but Apple is saying that the "com.apple.MobileBackup" way of doing things will soon be depreciated.

So is there another extension that works for IOS 5.1 and above as required by Apple?

Thanks!

FWIW, they did not respond to the first wave of these issues when com.apple.MobileBackup was the "correct" solution, so I doubt they would hurry to respond to the 2nd wave.  Having said that, our "sole option" is not being depricated.  The extension from jampot can be modified, although not easily, to use the new 5.1 Do Not Backup method.  I don't have the source with me, but I will look over it tonight and post a few lines that can be changed to use the 5.1 method.  We have done this, we have apps using it on the store.  The only caveat is we do not use the 5.0.1 and 5.1 method in tandem, so the app must be marked 5.1 required.

What I'm saying is that com.apple.MobileBackup is not our sole option, although it is being depricated.  This method is not an Adobe developed solution, neither would be a modified version of the jampot extension.  Their official response has been, as you say, to use the cache folder, which is completely and totally not an option for many applications.

The modified jampot extension would require changes to the native objective-c code before compiling.  I'll try to get more details or possibly a binary linked later.

Thanks for reporting in, LA.

That's exactly what I was afraid was going to happen!

(Wish I could help with a solution, but I'm still learning the ropes, so-to-speak.)

Alright, again I must emphasize that this is not an easy thing to get going, at least it wasn't for me.  However, I have a 5.1+ solution made building on the jampot extension available here:

http://www.jampot.ie/ane/ane-ios-data-storage-set-donotbackup-attribut e-for-ios5-native-extension/

Replacing the ANE file in the zip provided by jampot with the one linked below should then cause calls to that extension to follow the new 5.1 method.

http://bit.ly/QbeVCg

The extension documentation has more info on how to use it, but for a quick start, we use something like:

if (flash.system.Capabilities.version.substr(0,3).toUpperCase() == "IOS")

{

     var noBackupSetter : MobileBackup = new MobileBackup();

     var result:Boolean = noBackupSetter.doNotBackup(DataStorage.filePrivate.nativePath);

}

This will set the entire File.applicationStorageDirectory to DoNotBackup.  Files that are saved within the directory will obey the DoNotBackup rule for the containing folder.

Make sure you have the MobileBackup class from the files provided by jampot in your project and that you have included the native extension in your project and packaging.  If you have trouble with any of that, please reference the jampot link above, with the exception of using the 2nd link's ANE file.

Two important notes--

First, I have only had success compiling my project using this ANE on a Mac against Air 3.3 with the project pointed directly to my iOS 5.1 SDK folder, found at

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform /Developer/SDKs/iPhoneOS5.1.sdk .  (I am using Xcode version 4.4.1, I do not know if this sdk is available in later versions, but it may be possible to find an upload of someone's copy on the web)

Second, the code the modified ANE uses requires iOS 5.1.  If you submit an app that uses this ANE and it is installed by a pre-5.1 device, the app will immediately crash.  To keep your app from being installed on pre-5.1 devices, modify your AppName-app.xml file in the root of your project to set the MinimumOSVersion like so:

    <iPhone>

        <InfoAdditions><![CDATA[

                              <key>UIDeviceFamily</key>

                              <array>

                                        <string>1</string>

                                        <string>2</string>

                              </array>

                              <key>MinimumOSVersion</key>

                              <string>5.1</string>

                    ]]></InfoAdditions>

        <requestedDisplayResolution>high</requestedDisplayResolution>

    </iPhone>

I'm sorry I don't have access to the changes I made to source at this time, but I will post again when I can to include the specific changes made.  There really was not much change to the objective-c code.  The hard part was getting the ANE built and working with Flash Builder.

I'm sorry, I never could get it to work in Windows.  I can tell you this... the reason why I need Mac is because it requires iOS 5.1 SDK to compile in Flash Builder.  I believe Air 3.4 include iOS 5.1 support.  It may be possible to use this ANE in Windows compiled against Air 3.4.  However, my app has other issues with Air 3.4, so I do not use it.  I would try compiling against a Flex sdk folder with Air 3.4 or maybe Air 3.5 beta overlayed and see if you get better results.

I spent the better part of a day wrestling with the command line compiler to pass the platform-sdk folder, etc etc. on Windows, but I never had any luck.  This was all before the Air 3.4 release, so give that a go.

Hi,

Sorry for the noobish question... How were you able to check that the old jampot ane was not working on IOS 6?

I tried using it on our project and I just used the boolean return value to check if it was working or not. Using it on the Application Storage directory always shows false but after placing the files into the Private Documents directory it would then return as true. Is the boolean return value the proper way to test if it is working?

Thanks!

If it is showing "No Data", then yes, your app is not sending anything to iCloud at this time.  When we did our testing on 5.1, I believe we had data still being sent even when using the previous jampot extension.  Either way, keep in mind that the functionality it uses is now deprecated, which means that Apple may not continue to support that function in future releases of iOS.  Also, Apple has stated that the new method is required for apps that target iOS 5.1.  I take that to mean that using the com.Apple.MobileBackup method only would potentially be cause for an app rejection, but I do not know for certain that would happen.

"iOS 5.1 introduces a new API to mark files or directories that should not be backed up. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKey attribute.

Apps running on iOS 5.1 and later must use the newer attributes and not add the com.apple.MobileBackup extended attribute directly, as previously documented. The com.apple.MobileBackup extended attribute is deprecated and support for it may be removed in a future release."

http://developer.apple.com/library/ios/#releasenotes/General/RN-iOSSDK -5_1/_index.html

Did you not read my posts?

Yes, I have multiple apps on the store at this time using the modified ANE.  If you have the Jampot ANE working, it should be as simple as dropping the modified ANE file into the location you have the Jampot ANE stored.

is there any solution new?

i tried all of them, but not work. why don't adobe work about it?

i make ios application with flash cs6 air but apple reject me becouse of "do not back up". i spent a lot of time for make this app. please help.

how can we use preventBackup, to make File.documentsDirectory to make do not back up?

can u give example?