Internal Workings of the ChooserBase.Completed Event

When subscription to the ChooserBase.Completed event occurs, the location of the subscription, in particular the class name and method name, is used as an identifier for the event subscription. This information is serialized to your app’s transient state, allowing it to survive application termination. When the system application associated with the chooser completes, your app is restarted, and the OS signals that a chooser has completed by invoking a static method. When the event subscription occurs again in your class, the subscription identifier is re-created and compared with the list of subscription identifiers for that chooser. If there is a match, the event handler in your class is called.

To understand this further, consider the following code:

Click here to view code image

readonly SaveEmailAddressTask saveEmailAddressTask
    = new SaveEmailAddressTask();

public SomeViewModel()
{
    /* Step 2. */
    saveEmailAddressTask.Completed += saveEmailAddressTask_Completed;
    /* Step 4. */
    Debug.WriteLine("Constructor.");
}

public void ShowLauncher()
{
    /* Step 1. */
    saveEmailAddressTask.Show();
}

void saveEmailAddressTask_Completed(object sender, TaskEventArgs e)
{
    /* Step 3. */
    Debug.WriteLine("Task Completed.");
}

Subscription to the SaveEmailAddressTask.Completed event is performed in the viewmodel’s constructor. When the Show method of the saveEmailAddressTask is called (step 1) the user app is deactivated. Presuming that the app is tombstoned, when the system app completes and the user app is restarted and activated, the viewmodel’s constructor is called again (step 2). When the event subscription occurs this time, however, the Completed event is raised and the event handler is called (step 3). When the event handler returns, the code in the constructor resumes (step 4).