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.
Note
Subscribing to the Completed
event causes the event to be raised.
To understand this further, consider the following code:
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).
Best Practice
When subscribing to the Completed
event of a chooser, declare the chooser at the class level and subscribe to the event within the class constructor.
3.144.21.190