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:Asynchronous Programming For Windows Phone 8
R2d2rigo - Article theme
This is an interesting topic to write about, but you can't use it to compete in the current contest; only entries about new, Windows Phone 8 specific features are allowed.And the Portable Libraries section should be reworded, since they were already available prior to VS2012, as a way to share code between Windows, WP7 and Xbox.
23:36, 5 December 2012 (EET)
CadErik -Thanks for feedback. I think asynchronous programming is sort of specific to windows phone 8. Unlike the full .net stack, you have no other way to write network calls - there are no synchronous versions of the I/O methods.
03:58, 6 December 2012 (EET)
Hamishwillee - Not an expert but ....
Let me prefix this by "I am not a WP or .NET expert".
Reviewing the literature await is new to Windows Phone 8 and from my understanding of articles like this one the value of await et al is to vastly simplify asynchronous programming by encapsulating much of the creation and daisy-chaining of asynchronous operations/call back boilerplate code.
So my take on this is that asynchronous programming (even for these APIs) always existed (since you can run synchronous operations in another thread), but what you cover here makes them much easier to write.
If I am correct that makes that makes this a valid "new feature" and hence valid competition entry. I do believe though that there are libraries that emulate the functionality for WP7 and these should be mentioned.
I would remove the concentration on visual studio 2012 and refer to these as .Net or platform features - from a user perspective on this wiki this is "new stuff I can use in WP8", and "hey, I can backport to WP7" so that is what I'd focus on - perhaps a title "Improved asynchronous programming in Windows Phone 8" or similar. I would also do something comparative showing the difference in way this programming using both methods so you can show the improvements.
I haven't reviewed this in detail, so apologies if I misunderstand. Note also that I am not the final judge - who might take a different view.
R2d2rigo - is my position reasonable?
08:01, 6 December 2012 (EET)
R2d2rigo -Well, looking that async/await is a new core feature of WP8 even already being available in W8, I'd consider it valid then. But as Hamishwillee says, I'd focus more the article in how this improves the programming model of WP8, and how projects like Microsoft.Bcl tries to backport this functionality to WP7.
16:19, 6 December 2012 (EET)
Hamishwillee - R2d2rigo - thanks!
CadErik, R2d2rigo then summarised my view quite well in previous comment. I think this would be a very useful article if well done. http://labs.vectorform.com/2012/02/asynchronous-ui-development-in-winrt-silverlight-windows-phone-wpf-with-asyncawait-keywords-of-c-5-0/ is a good start on the topic but I'm sure it could be done even better and with your examples.
R2d2rigo, thanks for your advice/guidance.
01:23, 7 December 2012 (EET)
CadErik - Updated articleHamishwillee - R2d2rigo, thanks alot for your feedback and references. I updated the article with references to the other articles and another section. Is the focus better?
06:50, 7 December 2012 (EET)
Hamishwillee - Yes
Yes, I think the focus is much better. I'm still don't completely understand how this works from this article, but that is perhaps a limitation in me. The judges are experts and will be able to assess this better.
I think the problem for me is that waiting is a blocking operation, so if you use one of these in a UI thread it looks like you'd be blocking the UI. It might not be the case - I'm envisaging the case where async operation is called if called in a button click handler - does the handler not then complete if await is called in a function in it? Or maybe I'm overcomplicating this - you just wouldn't wait ... but then how would you signal the UI it needs to update with a new property value. Too much Symbian C++ in my past
I would also add links to "official" documentation on await/async.
There is a missing placeholder here: "You can learn more about it on … and …"
07:56, 13 December 2012 (EET)
Hamish,Thanks for the great feedback! I added a diagram, does this answer your question? The handler will complete using a callback, but the code calling the handler will be able to continue its execution right after it sees the await.
07:20, 16 December 2012 (EET)
Hamishwillee - Thanks, the diagram helps
I did a lot more research and I believe I "get" it now. Essentially await is blocking, but only in the current function - from the perspective of the calling function life continues on until it too is forced to await something. I'm not completely comfortable with all the implications, but it is cool. More reading for me.
I think that "What is asynchronous Programming?" section is probably a little unclear, probably because that title doesn't really match the content - which is about two different forms of asynchronous programming (with callbacks and using the new methods). Then there is some feel of repetition in the next section. Too late for the competition, but this section should probably follow a logical flow showing "synchronous programming is easy because the logical flow is easy to follow", "asynchronous programming used to be hard, because you had all these callbacks, and never new when they would be called and how to daisy chain them", "now asynchronous programming is much easier, because you can write async programming like sync programming - within a function the code will appear to wait synchronously, but within the context of the rest of your code it is as though the function did complete - and you only wait where you "really" need the value.
this would then combine with parts of the next section.
Anyway, something for you to think about. The diagram you added does help.
07:16, 19 December 2012 (EET)
CadErik -This was a more ambitious article than I originally thought! Great feedback again! I incorporated couple comments as minor edits.
19:51, 19 December 2012 (EET)
Hamishwillee - Yes it is
When I get my head around this, and after my holidays, I may try tidy the introduction further myself. Sometimes it helps to be ignorant :-0
02:24, 20 December 2012 (EET)