Logical deletion and asynchronous processing of Windows phone

Have you ever written an application that, when it is about to be done, wish you had never written this application? It is this intuition that makes you feel that the architecture is not very good. Simple changes seem to be out of reach, or at least take much longer. Then there is the bug. Oh, there's bug!. You are an upright programmer. How do you write something with so many bugs?

Does it sound familiar? Well, when I wrote my first Windows Phone app for NPR Listener that's the case. NPR Listener communicates with the National Public Radio Service (npr.org/api/index.php) to get a list of available news stories for its radio programs, and then lets users listen to these news stories on Windows Phone devices. When I started writing, I did a lot of Silverlight development and was very satisfied with the porting of knowledge and skills to Windows Phone. Soon I finished the first version and submitted it to the marketplace certification process. That time I was thinking, "Oh, this is very simple." But then I failed the certification. The failure is the case:

Step 1: Run your application.

Step 2: Press the Start button to enter the home page of the phone.

Step 3: Press the Back button to return to your application.

When you press the Back button, your application should recover normally, and ideally, you should let the user return to the screen when you exit your application. In my case, the tester navigates to the National public Broadcast program (such as "All Things Considered"), clicks into any of the latest reports, and then presses the Start button to enter the main screen of the device. When the tester presses the Back button to return to my application, the application resumes, but it is full of nullreferenceexceptions. This is not a good thing.

Now let me tell you something about how I design a XAML based application. As far as I'm concerned, it's all Model-view-viewmodel mode, and my goal is to do a near-crazy separation between the XAML page and the application logic. If there's any code in the Codebehinds (*.xaml.cs) of my page, there's a good reason to do it. This is largely due to my almost perverse need for unit testing. Unit testing is critical because it helps to know when an application is effective, and more importantly, it makes it easier to refactor the code and change how the application works.

So if I'm so passionate about unit testing, why do I get these nullreferenceexceptions? The problem is that I write a Windows Phone application just like a Silverlight application. Of course, Windows Phone is Silverlight, but the life cycle of Windows Phone applications is completely different from the life cycle of Silverlight applications. In Silverlight, the user opens the application, interacts until it finishes, and then closes the application. Instead, in Windows Phone, the user opens the application, uses the application, and then jumps back and forth between the application and the operating system or any other application. His users leave your application and the application is deactivated or "tombstone". When your application is logically deleted, it is no longer running, but the application's navigation "Back stack"-pages in the application in order of access-is still available on the device.

You may notice that on Windows Phone devices, you can navigate through multiple applications, and then repeatedly press the back button to move backwards in these applications in reverse order. This is the navigation back stack at work, and every time you go into a different application, that application is reactivated from the persisted tombstone data. When your application will be tombstone, the application receives a notification from the operating system that it will be deactivated and should save its application state for later reactivation. Figure 1 shows some simple code for activating and deactivating an application in App.xaml.cs.

Figure 1 Implementation of simple logical deletion in App.xaml.cs

             //Code to execute application was deactivated (Sent to Backgro und).
             //This code won't execute when the application is closing.
             private void application_deactivated (object sender, Deactivatedevent Args e)
   {
     //Tombstone your application.
          & nbsp  idictionary<string, object> statecollection =
        PhoneApplicationService.Current.State;
     statecollection.add ("Value_1", "the VALUE");
  &NBSP;}
   //Code to execute when the application is activated
   //(brought to foreground).
&N Bsp            //This code won't execute when the application is the launched.
            &NBSP;PRIVate void application_activated (object sender, Activatedeventargs e)
   {
     //Un-tomb Stone your application.
             idictionary<string, object> statecollection =
       PhoneApplicationService.Current.State;
     var value = statecollection["Value_1"];
   }