Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Talk:Awaiting event handlers in Windows Phone 8

From Wiki
Jump to: navigation, search


Hamishwillee - What does this add over ...

Hi Bálint

Thanks for contributing.

This would appear to me to be wrong/incomplete, but since I'm not an expert I recommend you please check out Bringing async/await to the Contacts service. In essence, an implementation of an asynchronous function should return a Task item immediately that the caller can await on, and then update this task with the result when it completes. Your example returns void, so there isn't any way to get the translated result back. It appears to forget about cancellation and setting the error if one can occur too.

Having a timeout value is interesting (you say this is recommended, where?) but only if this translates to errors though standard Task interface.

Lastly, I don't think this makes anything simpler - how do I use the asynchronous function you've created generically.

I could be wrong of course, can you please check out the other article. If yours does not add anything over this one, I think this should be removed.



hamishwillee (talk) 05:11, 19 August 2013 (EEST)

Vineet.jain - Async programming for WP8 already described

An article covering the whole Async programming architecture in WP8 is here already :

vineet.jain (talk) 07:42, 19 August 2013 (EEST)

which obviously described the things in details which you have tried to explain here.

Hamishwillee - Not completely Vineet

That article covers some aspects of asynchronous programming, but didn't cover conversion from old style to new style in great detail. However Bringing async/await to the Contacts service does.

hamishwillee (talk) 09:11, 19 August 2013 (EEST)

Paulo.morgado - Cleaver, but it can be improved

Hi Bálint,

I see that you followed the standard practice of using a thread synchronization primitive (a SemaphoreSlim in this case – I wonder why you didn’t choose a ManualResetEvent) to synchronously block while the asynchronous operation is not completed.

The only change you made was to use the TAP (Task-based Asynchronous Pattern) API method to block that, if you are in the UI thread, will return control to the message pump and resume upon lock release.

Like Hamish mentioned, you are expecting a response from the execution of your translation operation but are not getting it directly from there.

My [Bringing async/await to the Contacts service article] that Hamish mentioned has a (or a few) cleaner way to convert an EAP (Event-based Asynchronous Pattern) API into a TAP API. It will even allow a cleaner way to consume the library.

Also as Hamish mentioned, void returning async methods are to be avoided at all cost because if the async throws an exception that is not caught it might result in terminating the execution of the application. They should be used only when the contract is out of you control like event handlers or overriding a non Task returning method. Library code should always expose Task returning methods for the caller to be able to inspect the result (good or bad).

I agree that you should put a timeout in this kind of operations (network). But your code is not canceling the network operation. It’s just abandoning it. And by abandoning it, you’ll end up with a null eventArgs.

I don’t know if you intended to reuse instances of this class, but if you were, you’re up for some problems. Because you didn’t cancel the event subscription, you might run into a race condition where eventArgs is overridden by a previously abandoned call in a not abandoned operation or get the value of the previous operation in case of abandonig.

The easiest way to add a TAP API to your Translate class would be to use the new TAP methods of the WebClient class like the OpenReadTaskAsync method.

The WebClient class even supports cancellation but has no TAP way of doing it. You would have to it yourself – Task Cancellation.

However, if you’d like to opt for a more modern API, I would recommend you to use the HttpClient class that you can find in the Microsoft HTTP Client Libraries NuGet package. Let me know If you want help with it.

paulo.morgado (talk) 05:07, 20 August 2013 (EEST)

Molbal - Thanks for the replies


Thanks for all the replies - I looked around here in the wiki for articles like these, but I could not find them (obviously my fault, I searched for a wrong term or I overlooked the articles).

I checked the articles you linked and now I know why is there definitely room for improvement here - apologies for the incomplete article, I'll tag it draft to mark it.

Thanks again for all the help,


molbal (talk) 12:17, 27 August 2013 (EEST)

Paulo.morgado - This is a learning place...

Hi Balint,

Don't underestimate the power of sharing what you know. Someone will learn from it.

Your heart was in the right place and you did well with what you knew at the time and it's still a valid article if you're using semaphores and want to await on them.

The TaskCompletionSource acts as a semaphore with a value and it's better suited for use with Tasks and {{Icode|async}-await.


paulo.morgado (talk) 16:27, 27 August 2013 (EEST)

Hamishwillee - That would be me

Someone will learn from it.

I learned quite a lot from the fact is wasn't quite right - maybe not the article itself, but the discussion it has raised has been very useful.

Looking forward to seeing your fixes!

hamishwillee (talk) 07:31, 28 August 2013 (EEST)

Molbal - Great article

If someone, I learned quite a lot ;) Thanks for the help :)

molbal (talk) 08:51, 28 August 2013 (EEST)

Hamishwillee - And I should add

Bálint, you're a star for sharing what you know with us. Its easier and less risky to keep information to yourself, but shows a lot less community spirit. So thanks very much.

hamishwillee (talk) 03:39, 29 August 2013 (EEST)

Hamishwillee - This is still in draft

Plan to update so we can make it live, or is the feeling that the delivered information is in some of the other articles?

hamishwillee (talk) 05:28, 11 September 2013 (EEST)

BuildNokia - were you planning to keep working on this article?

Hi Balint,

I'm sorting through the draft articles and noticed that this is not yet finished. Were you planning to continue working on it?


BuildNokia (talk) 01:25, 13 June 2014 (EEST)


Was this page helpful?

Your feedback about this content is important. Let us know what you think.


Thank you!

We appreciate your feedback.