Coursera: Programming Mobile Applications for Android Handheld Systems: Part 1 - My take

There is no argument that Coursera is one of the largest online education providers in the world. I recently completed the part 1 of the Android course and thought I would share some of my experience.

Not for the faint hearted

Yes, if you are looking for a basic overview of the Android system, then this may not be the best place to start. I would recommend looking at the official documentation on the subject from Google itself. In fact I spend more time reading the official documentation during the course than the course material.

Format

I would say the format of the delivery is pretty good. I really felt like being at University when listening to Dr. Porter (the instructor). His use of language is fantastic and very easy to follow.

The lectures are added to the course home page every week followed by assignments which are graded through an automatic grader. The assignments comes with very clear instructions. Generally the assignments are submitted in a form a zip file with requisite files in certain folders. Be very very careful with names as the automatic grader will reject if there are any special characters in the folder names.

The final project is peer reviewed.  As a part of the review process you are asked to review others work as well. (Here is my screencast that was part of the submission.)

Quality 

I think the material is pretty good. You are expected invest about 4/5 hours a week on the material. However I think you would need to invest more time if you are really interested in learning the platform. I started the course not simply to "pass" a course, but to learn. Therefore spend more time reading questions in StackOverflow and official Google documentation than the lecture material.

Final words

There are alternative courses offered by Udacity too. Once you start on the Android journey, I would recommend looking at other courses simply to enhance and solidify your knowledge.

Score

My score is 4/5.

Working with CallContext in WCF (with a twist)

In my previous post I discussed a bit about CallContext and how it can be used with WCF. In this post I will attempt to describe an issue I encountered and a possible workaround.

Issue

The CallContext looks pretty convincing when it comes to storing "state" of a WCF service on a per-request basis. This "state" flows through the local call context and very beneficial for async-await methods.

What I did notice is that under load (I mean with 10 requests per seconds), the content in the CallContext is shared. Which is pretty Bad.

Tool

In order to reproduce this issue, we need to use JMeter (or any load testing framework). JMeter is a tool that is used for load testing a web application.The documentation of JMeter may be bit scratchy, but is it worth the effort.


Reproducing the issue

We will need to add the following code to a WCF service. (Code is checked in here, and I will extract parts to explain the issue.)


Ideally we should never see "(GetPaymentDetails) CallContext already has..." message as this will shown only when there is something already in the CallContext.

Reflecting on the results

Normally Threads in the .NET framework is polled. This would mean same Thread will be used to execute multiple requests. After a request is complete, the Thread returns to the Thread pool.

So what seem to be happening is that the CallContext state is returned with the Thread to the Thread pool. When the same Thread is reused to process another request, it is quite possible that the state is still preserved in the Thread itself.

This could be a bug or expected behaviour of the CallContext.

What if we reset the CallContext at the end of the request? The CallContext reset is through a call to CallContext.Clear method. This may work. However in the scenario where multiple async-await method are used, we cannot be 100% sure that context is cleared across all the the Threads used to process the request.

Normally in .NET 4.5 CallContext uses "copy-on-write" behaviour. (more on this is here.) So although we reset in one Thread it is not propagated across all the Thread that we used to process a particular request. Therefore resetting it "at the end" of a request is not quite correct.

Workaround

The workaround is to introduce a "MessageInspector". At the beginning of the request we can reset the CallContext with a call to CallContext.Clear. This way we make sure the CallContext is cleared for the request.


Given the shortcomings of CallContext, I am not sure whether there is any other solution that may  work consistently .

Working with CallContext in WCF

The CallContext class is provided by the .NET Framework to "track" the logical execution of a request. It is sort of a property bag that is carried through the execution path.

Why CallContext is quite useful in WCF?

Prior to .NET 4 (most specifically async-await) paradigm, WCF methods were sort of synchronous. I use "synchronous" is a very loose terms to suggest that no explicit Threads were created by the developer to process a request.

However with the introduction of async-await pattern and Task Parallel Library (TPL), developing asynchonous code has become quite easy.

The issue really is that WCF was never designed (or at least visioned) to handle async-await in a graceful manner. Normally WCF use OperationContext to store extensions that can be used later in the application. The OperationContext hold state in thread local store which will never play happy with async-await. There are dozens of questions in StackOverflow around this matter.

There are few ways to design a WCF service that leverage the power of async-await.

• We can discount OperationContext completely and pass the any data items around.
• We can store the data points in a backing store and read when required. We may need to pass around a references, this may be acceptable. 
• We could consider CallContext to store request specific information and read it whenever required. 

The data stored in CallContext is maintained across threads (as by definition CallContext is per logical execution context). In theory CallContext could be considered as a replacement to OperationContext. We can continue using async-await without having to worry about the limitations in the framework (in this case WCF). 

Example

The following code is a simple wrapper over the CallContext.

A word of caution about what you should store.

• Generally it is advised that you should only consider storing immutable objects in CallContext. There is an excellent post here that explains the pros and cons.

An operation can use the CallContext wrapper in this fashion.

Summary

There is no double that CallContext is a very strong candidate for maintaining per-request data in WCF. Here is another post around CallContext from Winterllect. However there is a twist of CallContext that we need to be very careful about. I will write up my findings in the next post.