Explaining the AndContinue methods for Windows Phone 8.1 SDK
The Windows Phone 8.1 SDK introduces some new operations that end in “AndContinue”. These API’s have a different workflow than their Windows Store App counterparts that end in “Async”. First of all, why do we have the AndContinue methods in the first place? The short answer is that some Windows Phone devices only have 512MB of memory. For lower memory phones the application only gets 150MB of memory. The API’s that became AndContinue API’s, consume a lot of memory, so the choice was made to not penalize the calling application and run the operations in a separate process. Since it is in a separate process the calling application gets moved to the background. This means the data from the operation needs to be transferred to the process in the background, as well as take into consideration that the background application may be terminated while the operation is being carried out.
The following table contains a list of the different AndContinue methods.
| Task | Method to Call | Event Argument Type |
| Pick a file to open | PickSingleFileAndContinue | FileOpenPickerContinuationEventArgs |
| Pick multiple files to open | PickMultipleFilesAndContinue | FileOpenPickerContinuationEventArgs |
| Pick a location to save a file | PickSaveFileAndContinue | FileSavePickerContinuationEventArgs |
| Pick a folder | PickFolderAndContinue | FolderPickerContinuationEventArgs |
| Connect to an online identity provider | AuthenticateAndContinue | WebAuthenticationBrokerContinuationEventArgs |
When one of the above AndContinue methods is invoked, the application will be put in the background. It will be notified by a callback when the application is activated. The callbacks used for this is different for Windows Phone XAML and Silverlight 8.1 applications. The following sections will describe the differences.
Silverlight 8.1 Applications
When an AndContinue operation is invoked in a Silverlight 8.1 application a callback is made into the PhoneApplicationService.ContractActivated event. If you are migrating an existing application to Silverlight 8.1, then you need to subscribe to this event during application initialization. The following code illustrates how to subscribe to the event and a sample definition for it.
PhoneApplicationService.Current.ContractActivated += Application_ContractActivated;
private void Application_ContractActivated(object sender, Windows.ApplicationModel.Activation.IActivatedEventArgs e)
{
}
When creating a new Silverlight 8.1 application from within Visual Studio 2013 this event is already subscribed to in the App.xaml.cs file. In both cases the IActivatedEventArgs passed to the callback function will contain the appropriate type, as indicated in the above table, when returning from the specific method.
Since the application is moved to the background, it should also maintain its state. It should save and restore state in the PhoneApplicationService.Deactivated and PhoneApplicationService.Activated events respectively.
There is a good walkthrough on how to use the PickSingleFileAndContinue API which illustrates this workflow. Calling the other API’s will work in a similar manner except to change the Event Argument to the appropriate type.
Continue your Windows Phone Silverlight 8.1 app after calling a file picker
Windows Phone XAML Applications
When an AndContinue operation is invoked, from a Windows Phone XAML application, a callback is made to the Application.OnActivated event. The IActivatedEventArgs passed to the callback function will contain the appropriate type, as indicated in the above table, when returning from the specific method. This is made easier for Windows Phone XAML applications via a helper class ContinuationManager. The details of how to call PickSingleFileAndContinue and the helper class are included in the following articles:
How to continue your Windows Phone Store app after calling an AndContinue method
I hope that this blog helps clarify how to use the new AndContinue API’s available in Windows Phone 8.1 SDK. Until next time, have fun coding!
Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.
- Bret Bentzinger(Microsoft) @awehellyeah
Comments
Anonymous
February 20, 2015
"PhoneApplicationService.Current" have not "ContractActivated" member. Visual Studio 2013, Windows Phone 8.1, Visual Basic.Anonymous
February 26, 2015
Add "AddHandler PhoneApplicationService.Current.ContractActivated, AddressOf Application_ContractActivated" into "InitializePhoneApplication()", and "xmlns:srs ="clr-namespace:System.Runtime;assembly=System.Runtime">" into "App.xaml". With these additions will work in VB.Anonymous
January 26, 2016
While I absolutely understand the need to handle devices that have limited memory, I am not at all aligned with this design choice for a several reasons. This design means means that it is almost impossible to leverage the FileOpenPicker in any class library as it requires full interaction with the application object (think PCL type libraries that are used between phone and desktop applications). It also means that ALL application state MUST be saved for the app to resume correct -- again this can be a non trivial thing that should be limited to happening only when critical.