Bug 6596 - ALAssetsLibrary "loses" instance members of ALAsset or ALAssetsGroup
Summary: ALAssetsLibrary "loses" instance members of ALAsset or ALAssetsGroup
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 5.2
Hardware: Macintosh Other
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-08-18 08:02 UTC by Armin Sander
Modified: 2012-09-10 09:52 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

AssetsLibraray Test Project to reproduce the problem described. (11.98 KB, application/x-zip-compressed)
2012-08-18 08:02 UTC, Armin Sander
AssetsLibraryTest ... fixed error handling and removed NSAutoReleasePool (12.01 KB, application/x-zip-compressed)
2012-08-22 01:17 UTC, Armin Sander

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Armin Sander 2012-08-18 08:02:25 UTC
Created attachment 2374 [details]
AssetsLibraray Test Project to reproduce the problem described.


The test project attached tries to copy an image to the "saved photos" album and also creates a new album and places it there. But somehow either the group or the asset instances - which both are fine after their creation - seem to "lose" their members. They turn into nulls or throw an exception when they are being accessed.

The project is a standard template. I've added the file "PhotoExportService.cs" and the "EmptyImage.png". 

The "PhotoExportService" is called from the AppDelegate.cs file and it throws either a null pointer exception at line 86 or an exception at line 90, which indicate that either ALAsset or ALAssetsGroup is invalid.

I suspect that this is a monontouch related problem. The problem appears with 5.2.13 and the latest 5.3 release.

There is also a related forum post that describes a similar problem:


Comment 1 Sebastien Pouliot 2012-08-21 21:48:28 UTC
I get:

2012-08-21 21:44:52.114 AssetsLibraryTest[87029:1507] Success

when executing this in the latest (not yet released version of) MonoTouch.

* Does the problem occurs every time it's executed ?

* Which version of iOS are you using ?

* Does it happen on the simulator ? on devices ? or on both ?
Comment 2 Armin Sander 2012-08-22 01:17:49 UTC
Created attachment 2387 [details]
AssetsLibraryTest ... fixed error handling and removed NSAutoReleasePool
Comment 3 Armin Sander 2012-08-22 01:20:21 UTC
thank you for looking into it!!

* happens always
* Simulator: 5.1, Device: 5.1.1
* both.
Comment 6 Armin Sander 2012-09-09 14:18:52 UTC
Taking into account all I know so far, I've changed the implementation so that it works quite well on iOS5.1+:


Some remarks:

- The group passed to the callback of AddAssetsGroupAlbum() is considered unstable. The callback just indicates that the group was added. The group's NSUrl is then collected in another call to Enumerate().
- The resolvement from "stable" NSUrl instances to "unstable" asset objects (either ALAsset or ALAssetsGroup) is delayed until ALAssetsGroup.AddAsset() needs to be called. The asset resolvement is done in the class AssetCollector, which also tracks the library change notification. If the library is changed while gathering the instances, the resolvement is retried until all of them are resolved and it is safe to call a library method that uses them.
Comment 7 Sebastien Pouliot 2012-09-10 09:52:31 UTC
Thanks for your confirmation and feedback. That might prove very useful for others!