On Sep 9, 2012, at 1:39 PM, Stephan Steiner <[email protected]> wrote:
> As it almost seems to good to be true, I cannot help but wonder - am I
> risking anything using the approach you outlined?
Not that I'm aware of.
Note that since February this approach has been simplified via two additional
facilities:
Android.App.Application.SynchronizationContext:
//
http://androidapi.xamarin.com/?link=P:Android.App.Application.SynchronizationContext
Application.SynchronizationContext.Post (x => { /* your
callback */ }, null);
System.Threading.SynchronizationContext.Current:
Requires 4.2.3 or later
http://androidapi.xamarin.com/?link=P%3aSystem.Threading.SynchronizationContext.Current
SynchronizationContext.Current is slightly more complicated, as it's only
non-null on the Main (UI) thread, not on any other threads (unless/until
SynchronizationContext.SetSynchronizationContext() is invoked; this is the same
behavior as WPF).
This shouldn't matter too much, though, as if you're using
SynchronizationContext.Current you'll also (probably) be using the Task
Parallel Library:
// From the UI thread:
Task.Factory.StartNew(() => /* action... *)
.ContinueWith (task => /* ... */,
TaskScheduler.FromCurrentSynchronizationContext ());
The TaskScheduler.FromCurrentSynchronizationContext() is done on the UI thread,
and thus should cause the `ContinueWith` delegate to have the appropriate
SynchronizationContext.Current value while the action is executing.
This is slightly more complicated, but should also be more consistent (and thus
portable) with existing .NET code.
- Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
