Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

Updating the Windows and Windows Phone Applications with the new Azure Mobile Service Entities

In my previous post I extended the Azure Mobile Service to include two entities, RealEstateProperty and Inspection. I’m now going to return to the Windows platform projects (ie Windows and Windows Phone) and update them to use these new entities.Rather than duplicate the entity definition I’m going to reuse the entity definition I created previously. Unfortunately, the base class of the two entities is a class called EntityData which is specific to Azure Mobile Service SDK for the full .NET Framework (ie to power the .NET backend services). This means we can simply move these entities into a class library, or better still a PCL, and reference it. Instead we’ll need to make the base class conditional on where the entities are being used – this is a great use for a Shared Project.

We already have a Shared Project which is used to share common code between the Windows platform projects. One option would be to simply reference this project from the service project but this would mean we couldn’t include any shared XAML or Windows platform specific code. Instead I’m going to create a new Shared Project which will be used to contain the entities that are going to be shared across both the Windows platform projects and the service project. To do this I need to download and install the Shared Project Reference Manager which extends Visual Studio to allow for the easy creation and referencing of Shared Projects. After installing the extension I simply add a new project as I would any other project type – right-click the solution node in Solution Explorer and select Add –> New Project. Select the Shared Project and give it a name, in this case will keep it inline with the other Shared Project by naming it RealEstateInspector.Shared.Entities.

image

With the Shared Project created, I need to add a reference to the Shared Project to both Windows platform projects and the service project – right-click the References node under the project and select Add Shared Project Reference. The two Windows platform projects should have both shared projects selected, whilst the service project should only reference the new Shared Project.

image

Next I need to move my entities out of the service project and into the shared project. I’ll also take this opportunity to change the base class, which as you’ll see will allow us to provide a different base class implementation depending on whether the entities are being compiled into the windows platform projects or the service project.

public class RealEstateProperty : BaseEntityData
{
    public string Address { get; set; }

    public virtual ICollection<Inspection> Inspections { get; set; }
}

public class Inspection : BaseEntityData
{
    public string InspectedBy { get; set; }

    public string RealEstatePropertyId { get; set; }
    public RealEstateProperty RealEstateProperty { get; set; }

}

The BaseEntityData class looks like this:

#if SERVICE
using Microsoft.WindowsAzure.Mobile.Service;
#endif

namespace RealEstateInspector.Shared.Entities
{
    public class BaseEntityData
#if SERVICE
       : EntityData{}
#else
    {
        public string Id { get; set; }
    }
#endif
}

You’ll notice that the BaseEntityData makes use of a compilation symbol to firstly control the base class (ie use the EntityData class if SERVICE is defined) and secondly whether the Id property is defined. The SERVICE symbol isn’t a predefined symbol so I’ll need to define that in my service project. I could have switched the logic to use one of the existing symbols, such as WINDOWS_APP but then if we ever extend this to other platforms, I’d have to modify the logic. It seems better to simply add a SERVICE symbol to the service project. Double-click the Properties node under the service project in Solution Explorer and then open the Build tab. Make sure you select All Configurations before adding SERVICE to the compilation symbols.

image

If I now go to the MainPage.Shared.cs (which I created in an earlier post) where we wrote the initial logic to query the TodoItems from the Mobile Service, I can update the code to instead use either, or both, the new entities we’ve defined:

protected async override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);

    var items = await MobileService.GetTable<Inspection>().ToListAsync();
    Debug.WriteLine(items!=null);
}

Whilst I’ve refactored the service code, there’s no reason to publish the new version since we haven’t modified the structure of the entities. However, there should be no harm in doing so if you’d like to keep the service up to date.

Pingbacks and trackbacks (1)+

Comments are closed
Windows Phone 7 Beta: Go Back…. No I mean the other Back

Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

Windows Phone 7 Beta: Go Back…. No I mean the other Back

Having spent quite a bit of time working with Windows Phone 7 on both a real device and the emulator I’ve come to the conclusion that the Back button is awesome! Now when I pick up a lesser device, that for example only has a home key, I get frustrated that I can’t go back to the application I was just in, or cancel an action that I didn’t mean.

This said, there are some times when the behavior of the Back button gets in the way. The most frustrating of these is Internet Explorer. The Back button handles two different types of Back-stacks: Firstly there is the application back-stack. This is the stack of applications that have been opened. For example if you open App1, followed by App2, App3 and App4, you’ll have a back-stack that consists of Start | App1 | App2 | App3 | Start | App4 (note that the Start appears twice in the list, once immediately before the last application on the stack, and then again at the beginning of the stack). As you press the Back button you will navigate back through the stack, progressively closing the applications, so starting at App4 you would see the Start, App3, App2, App1 and then Start again.

The second type of Back-stack is within the individual applications, and by default is made up of the pages that have been navigated to in that instance of the application. I say by default because the Back button is the one hardware button that an application developer can intercept and handle within the application. This means that the application can maintain a completely custom Back-stack. For example, within Internet Explorer, rather than opening/closing pages, the Back-stack consists of the websites that have been navigated to. As you can guess, pressing the Back button within Internet Explorer is like pressing the Back button on any desktop browser, it takes you back through the browsing history.

Ok, so by now you might be able to see where my frustration lies…. Let’s combine these two Back-stacks and replace App3 with Internet Explorer, and let’s say that I was browsing for a couple of minutes and have visited three websites. The total Back-stack looks like this:

Start | App1 | App2 | IE (site1) | IE (site2) | IE (site3) | Start | App4

As you can see, the longer I spend browsing in IE, the larger the Back-stack is going to be, which is a royal pain if you want to empty the Back-stack, or you want to go back to App1 or App2.

So by now you might be thinking “quit your whinging, you can just press the Start button and then click on App1 or App2.” But here is the issue with that – because we have a “Consistent Start” experience, whenever we click on an application from the Start it will always relaunch the application as if it wasn’t already running. This means that if the application was previously in the background (or Tombstoned) it will be terminated and restarted. Alternatively, clicking Back to get back to a running application will return the application to the foreground in the state it was in (relaunching if Tombstoned but automatically navigating to the correct page etc).

Is there a work around for this? In Internet Explorer, there is – you can open a new tab, and then clicking the Back button will take you to the previous application. For other applications, there currently isn’t a general solution to get around this issue.

Could there be a work around in future versions? Well if you look at the iphone 4 model where you can double-tap the home key to bring up the list of running applications, this could easily be applied to Windows Phone 7. You could get a list of applications that are suspended/tombstoned and be able to select one to bring to the foreground. The interesting thing there is what this means for the Back-stack – does the selected application move to the front of the Back-stack (immediate thoughts would be yes, but what about if you open the CameraCaptureTask and then try to bring the calling application to the foreground?). I definitely think having the ability to swap between running applications is a must for v.next.

Comments (2) -

  • Sam Judson

    8/16/2010 3:15:12 AM |

    This is a good point and something I had wondered about myself.

  • Bubba

    8/16/2010 1:13:07 PM |

    Does this mean that you can use the back button in, let's say, a game to actually give you a physical button to utlize for on screen commands (i.e. 'fire' in a shooter)?

Pingbacks and trackbacks (5)+

Comments are closed