I'm quite sure this is near the same thing that I've described here: https://bugzilla.xamarin.com/show_bug.cgi?id=16208
But I want to make sure I'm not loosing something...
What I do is trying to process a large amount of FBGraphUsers in a background thread instantiated using NSThread.InvokeInBackground(). What is the purpose? We know Facebook API calls should be made from UI thread, so that's okay for me, the delegates with prepared FBGraphObjects are also called in UI thread - and that's okay too. But then I need to process those FBGraphObjects somehow and I don't want to block the UI anymore, so the decision is to make some background worker thread and push FBGraphObjects to worker's queue as they received (I make a lot of simultaneous requests!).
Here's a little example of what I do:
FBRequestConnection.StartWithGraphPath("/<userid>/?fields=...", (conn, result, error) => {
var fbo = new FBGraphObject(result.Handle);
EnqueueBackgroundWorkerAction( () => {
ParseSomehow( fbo );
});
});
EnqueueBackgroundWorkerAction() takes an action and puts it into worker's queue, after the worker have finished it's current task (more likely another ParseSomehow(), but maybe something else), it will invoke this action.
This means actually I don't put the FBGraphObjects into some collection or like this, the object's reference is stored 'somewhere there' behind the mechanisms that allows delegates to use variables from outside it's scope...
And all works pretty nice in 70-90% of the time, but other 10-30% are the thing making me crazy right now because I still can't find a workaround. In those 'rare' cases the c-sharp FBGraphObject objects are okay, they are not lost, reference is not null, but what should be inside is totally lost. To understand what I mean, please see the attached screenshot.
As we see there, NSObject was not disposed (?), but it's native handle is 0. I double-checked that I always receive an FBGraphObject with non-zero native handle, but then, while traversing into ParseSomehow() method, it is lost somewhere...
So the question is: am I doing something wrong? Should I care about some Auto Release Pools inside my background thread? Should I handle multithreading with NSObjects in a special manner? I even tried to Retain() my poor FBGraphObjects, it won't help...
Sorry for a long message, but I'm trying to describe the exact problem at once.
ps. Forgot to say, the similar things happens when I decompose FBGraphObjects and take some child FBGraphObjects using ObjectForKey() method. So I get some child object (for example, school) and then trying to extract the things from it, and again from time to time I'm getting nothing while it actually was there (I see it in my debug logs, every received with StartWithGraphPath() FBGraphObject is printed to console). So it happens not only between the threads, but inside the background thread itself! As I remember, that wasn't happening when all worked in UI thread... But that's not the thing I would like to do.