Jun 12, 2007 at 4:59 PM
There are two ways you could add async to this library.

The task approach, or the library wide approach.

1) Library wide

Facebook.Components.FacebookService f = new ... ()

f.LoginComplete += new LoginCompleteHandler(...)

f.Login('joe', 'secret', Context) // or f.Login('joe', 'secret')

2) Task based

Facebook.Components.FacebookService f = new ... ()

LoginTask task = f.Login('joe', 'secret')

task.Complete += new LoginCompleteHander(...)
task.Begin(context) // or task.Begin()

i've used both and i find option 1 to be easier to program with and implement. But i found option 2 to be incredibly powerful and safe. The guy who made the request is the only one to be notified of it. (huge ++++)
Jun 12, 2007 at 5:02 PM
More info about option 2:

you can pend tasks to a task list and have a task manager who coordinates between them. Since there is a common interface of IAsyncTask you can show a nice gui with all your pending tasks and optionally cancel them.

I would like this library to offer async because i dont want to have to use a background worker thread.

private void report_progress ( .. )
private void do_work( object sender, doworkeventargs e)
private void work_completed( ... )

it's very verbose and requires a ton of typing
Jun 12, 2007 at 7:02 PM
This is a good discussion.

We talked a lot about adding async support into the library. But, ultimately decided not to. Primarily because our target was to make programming against the API easy.

If there is a need for adding async, I think it won't be too tough. But, I would want to do it completely through a separate set of calls. So, the average users of the toolkit would not need to understand delegates and event handlers.

Does anyone else have thoughts about the importance of supporting async calls.

One other thing. It is possible for you to handle this completely in your app, by using a BackgroundWorker for the calls to the api. We tried this out at one point in our sample and it worked fine. (Although, not sure this solution would be valid for a canvas app)
Jun 12, 2007 at 8:16 PM
BackgroundWorkers are for long processing commands, not long waiting ones.

You are correct that technically a client who needs async can use a bgworker.

I understand that this is sponsored by coding4fun, and so i understand your primary goal is approachability.

It would be nice to have the same API as if this were a webservice.