Subscribe: Nick Randolph's .NET Travels
Added By: Feedage Forager Feedage Grade A rated
Language: English
application  back button  back  buildit lifecycle  buildit  button  lifecycle  page  public  state  states  windows   
Rate this Feed
Rating: 3 starRating: 3 starRating: 3 starRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Nick Randolph's .NET Travels

Nick Randolph's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....Join me as I explore the world of cool devices, neat technology and uber geeks. I spend most of my time talking about Microsoft related technologies such as the .NET Framework, SQ


Building a Mulit-Tenant Rich Client (UWP) that Connects via an Azure AD Protected WebAPI Through to an External Service

Thu, 20 Oct 2016 06:56:09 +0600

Wow, that title is a mouthful. Just reading that makes you think that this is some weird edge case that you’d never have to deal with but this is actually quite a common scenario. Let me give you the scenario we were trying to get to work: - The user of the rich client application (I’ll use a UWP application but could be an iOS, Android, WPF, or in fact an external web site) needs to retrieve some information from their Office365 account. The required information isn’t currently available via the Graph API, so it requires the use of the Exchange Web Service (EWS) library, which is really only usable in applications written using the full .NET Framework (ie no PCL support). This means any calls to Exchange have to be proxied via a service (ie Web API) interface. Routing external calls via a service proxy is often a good practice as it makes the client application less fragile, making it possible to change the interactions with the external service without having to push out new versions of the application. - Access to the WebAPI is protected using Azure AD. The credentials presented to the Web API will need to include appropriate permissions to connect through to Exchange using the EWS library. - The user will need to sign into the rich client application. Their credentials will be used to access the Web API, and subsequently Exchange. - Any user, from any tenant, should be able to sign into the rich client application and for information to be retrieved from their Exchange (ie Office 365) instance. In other words both the rich client and Web API need to be multi-tenanted. Single Tenanted I’ll start by walking through creating a single tenanted version of what we’re after. For this, I’m going to borrow the basic getting started instructions from Danny Strockis’ post ( Creating the Applications Let’s start by creating a new solution, Exchange Contacts, with a Universal Windows Platform (UWP) application, call it ExchangeContactsClient. Next we’ll create a new ASP.NET Web Application project, call it ExchangeContactsWeb For the moment I’m not going to setup either Authentication or hosting in Azure Next I need to add the Active Directory Authentication Library (ADAL) NuGet package to both the WebAPI and UWP projects To make it easy to debug and step through the interaction between the UWP application and the WebAPI I recommend setting Visual Studio up to start both projects when you press F5 to run. To do this, right-click the solution and select Set Startup Projects I’d also suggest at this point running the solution to firstly make sure both applications are able to be run (ie that they were created correctly by Visual Studio) – I had to upgrade the Microsoft.NETCore.UniversalWindowsPlatform NuGet package in order for the UWP project to run. You also need to retrieve the localhost URL of the WebAPI that will be used later. Local WebAPI URL: http://localhost:8859/ Configuring Azure AD Before we continue developing the applications we’ll step over to Azure and configure the necessary applications in Azure Active Directory (Azure AD) – When you land on the Azure portal, make sure you’re working with the correct subscription – this is shown in the top right corner, under your profile information. In this case I’m going to be working with our Office 365 developer subscription (available for MSDN subscribers) called BTR Office Dev. This is associated with the Azure AD tenant. From the left side of the portal, select the Azure Active Directory node Followed by selecting App registrations – this will list any existing Azure AD applications your organisation has. You can think of an Azure AD application as a connector that allows your application to connect to Azure AD, so in order for both the UWP and WebAPI projects to connect to Azure AD I’ll need two new Azure AD applications Register the WebAPI application Click the Add button at[...]

Using BuildIt.States for Managing States

Sun, 18 Sep 2016 19:26:10 +0600

Almost every software development course at some point covers object orientated programming where the concept of encapsulation is drummed in. We’re taught to create classes that track state – a typical example is an Order that has a series of items, and then goes through various states as the order is processed. All this information is held within the Order object, including some basic functions such as calculating the total of the items being ordered. As the systems we work on grows in complexity, so does the complexity of the classes that are used to encapsulate aspects of the system. Unfortunately this often results in large, bloated classes, where it’s hard to make changes without fear of breaking other parts of the system. One common mistake that seems to creep in over time is that it becomes difficult to manage what state a class is in. This can result from either a lack of documentation about what states the class can be in, or the states themselves aren’t clearly defined. Take the Order example, the Order class may have properties such as OrderTimestamp and OrderId which are set when the Order is placed. If the Order is rejected, the OrderTimestamp may be reset, leaving the class is some weird state where it has an OrderId, yet no OrderTimestamp. This is one of the scenarios that BuildIt.States is designed to help with. Before we jump in, we need to set down a basic understanding of how we define states. States can appear in groups but within a group, there can only ever be one current state. For example in the Order scenario, there might be a group called TransactionStates, and the Order can only be in one of the states, Unprocessed, Processing, Processed, OrderRejected, at any given time. This leads me to the starting point of working with BuildIt.States: I’m going to define an enumeration that defines the states that my class can go between – you’ll notice this includes a Default (I often use Base instead) which BuildIt.States will use to determine if the state has been set or not. public enum MainStates{    Default,    One,    Two,    Three,    Four} The next thing we need is our class, in this case one that inherits from NotifyBase, and raises a PropertyChanged event when the CurrentState property changes. public class MainViewModel:NotifyBase{    private string currentState;     public string CurrentState    {        get { return currentState; }        set        {            currentState = value;            OnPropertyChanged();        }    }} Defining the states that this class can be in is as simple as adding a reference to the BuildIt.States NuGet package and then defining each of the states: public IStateManager StateManager { get; } = new StateManager(); public MainViewModel(){    StateManager        .Group()         .DefineState(MainStates.One)        .ChangePropertyValue(vm => CurrentState, "State One")         .DefineState(MainStates.Two)        .ChangePropertyValue(vm => CurrentState, "State Two")         .DefineState(MainStates.Three)        .ChangePropertyValue(vm => CurrentState, "State Three")         .DefineState(MainStates.Four)        .ChangePropertyValue(vm => CurrentState, "State Four"); } The notation for defining state groups and states is very fluid in nature and we’re always looking for ways to make defini[...]

Migrating BuildIt to .NETStandard

Sun, 18 Sep 2016 18:39:31 +0600

At the beginning of the year I blogged quite a bit about a set of libraries that we use at Built to Roam that are available either from NuGet ( or as source on GitHub ( These started a few years ago as an accumulation of helper functions for building, as the time Windows Phone applications. Since then the libraries have matured a bit and have evolved somewhat. The BuildIt.General library is still just a collection of helper method, whilst some, like BuildIt.Lifecycle, are more framework in nature. Over the coming weeks we’re investing a bit into tidying up these libraries, including:

  • Migrating any of the libraries that were targeting PCL profile 259 across to .NET Standard 1.0
  • Updating, where possible, all NuGet references
  • Setting up an automated build and release process, including support for publishing directly to NuGet
  • Rationalise the number of libraries on NuGet – namely where there are platform specific libraries, these will be combined in with the core library (eg BuildIt.General.UWP will get packaged with BuildIt.General and will be installed for UWP projects)
  • Add some additional packages
    • BuildIt.Media.UWP – This allows you to easily add Cortana voice commands for controlling media playback with the MediaElement control
    • BuildIt.Web.Config (this name may change) – This allows you to easily define application configuration values server side and have them flow to the client application

Right now, we’re going through and migrating the libraries to .NET Standard. This is a painful process as there are often NuGet references that don’t work with .NET Standard – we’re either removing these or deciding to wait on the package author to update. During this phase a lot of the packages will be marked as beta -  you should be able to start using these libraries but just be aware we haven’t completed the migration, so things may change over the coming weeks.


NetStandard, what is it and why do I care?

Sun, 11 Sep 2016 04:04:36 +0600

Over the past couple of years there hasn’t been a single project where at some point or another it hasn’t encountered NuGet pain – this is the pain associated with trying to upgrade packages, only to discover that you have to carefully select specific package versions due to incompatibilities, and then try and fight the nasty Visual Studio NuGet package manager interface to get them to install correctly. I’m no expert on topics like PCL Profiles, so I thought that I’d spend some time researching a bit more about what’s going on, and just why NuGet seems to fragile. This interest was also driven by the recent release of the .NET Platform Standard (ie NetStandard) and the fact that I need to migrate the BuildIt libraries we use, away from PCL Profiles (yay!) across to NetStandard.

As I said, I’m no guru on this, so rather than post third or fourth hand info. Here’s where I started: Oren Novotny’s post entitled Portable- is dead, long live NetStandard. Start there, and make sure you follow the links in his post as they provide some essential background reading on the topic.


Cryptic Build Failure in Release Mode for Universal Windows Platform Application

Wed, 23 Mar 2016 11:27:30 +0600

We’ve just managed to solve an issue that’s been plaguing us for a while when we attempt to do a Release build (either via the Store –> Create App Package, or just by setting the build configuration to Release) we were seeing an error message similar to: RHBIND : error RHB0011: Internal error: 'declModule == m_pLoaderModule' This error makes no sense, and there’s nothing at all helpful to go on from any of the usual logs etc. A quick search only returned two links, one of which was to a GitHub thread ( posted by Microsoft that talks about capturing a .NET Native Repro…. not quite what I was interested in. However, further down the post there’s a section entitled “Compilation Failure on Update 1” which lists almost exactly the error we were seeing. The section refers to a new feature called SharedLibrary but doesn’t really talk about how to turn it on or off. It does however link to another post Initially I didn’t think that there was anything relevant in the post, since it was entitled “What’s new for .NET and UWP in Win10 Tools 1.1” and starts off talking about app-locally and shared appx framework packages. It then talks about how to enable this feature….but in the other post it said that SharedLibrary was on by default…. Anyhow, instead of following this post and setting the UseDotNetNativeSharedAssemblyFrameworkPackage to true (ie enabling it), I figured I’d try setting it to false (ie true). For example the Release section of the UWP project file now looks like:   bin\x86\Release\  TRACE;NETFX_CORE;WINDOWS_UWP  true  ;2008  pdbonly  x86  false  prompt  true  truefalse Doing this fixed the Release build for this application and allows us to create a package ready for Store deployment. Hope this helps others. [...]

Updating BuildIt

Sun, 06 Mar 2016 19:03:00 +0600

It's been a while but I've just published an update to the BuildIt libraries with the aim to streamline the syntax for declaring states. For example, the following are the state declarations for the Flickr viewer sample application:
   .WhenChangedTo(vm => vm.Load())
   .OnDefaultCompleteWithData(vm => vm.SelectedPhoto)
         ((vm, d) => vm.Photo = d)


Triggering State Changes in BuildIt.States

Thu, 18 Feb 2016 08:12:19 +0600

The state management capability that BuildIt.Lifecycle uses is actually provided by a standalone library BuildIt.States which focusses on tracking states and allowing transitions between states. BuildIt.Lifecycle builds on this to adapt it to generating view models for specific states, along with the glue that connects states and transitions to the appropriate platform implementation (eg Pages and Navigation). The nice thing about the state management library being separate is that it can iterate independently. In this case, we’ve updated the library to include support for triggers. One of the new features added to the Universal Windows Platform (UWP) for Windows 10, are state triggers. Out of the box, UWP comes with an AdaptiveTrigger class which is used to trigger a state change once a minimum width or height (or both) have been reached by a Window. The way triggers work is that they evaluate a particular condition and once the condition has been met, the IsActive property is changed to true. Once all triggers for a particular state are set to IsActive, the framework changes the active visual state. We’ve adapted this concept to apply it to state management within the BuildIt.States library. Taking the FlickrViewer application that I discussed in my post, Building a Flickr Viewer App with BuildIt.Lifecycle, I’ll modify the MainViewModel to use triggers. Here you’ll see that in addition to adding triggers to the state definition, we’re also making use of an instance of the LoadingManager. A common scenario is to have states for when data is being loaded, and when it has been loaded. To handle this, the state management library includes a LoadingManager class which tracks which page/viewmodel state is used for both Loading and Loaded states. The nice artefact of using the LoadingManager is that the MainViewModel doesn’t explicitly need to indicate when it’s loading or not loading data. Instead it simply wraps the loading operation in a using statement. Behind the scenes this links to the LoadingTrigger instances used in the state declaration. public enum MainStates{    Base,    Loading,    Loaded} LoadingManager LoadingManager { get; } = new LoadingManager(){    LoadingState = MainStates.Loading,    LoadedState = MainStates.Loaded}; public MainViewModel(IFlickrService flickr){     StateManager        .Group()        .DefineState(MainStates.Loading)            .AddTrigger(new LoadingTrigger(LoadingManager) {ActiveValue = MainStates.Loading})        .DefineState(MainStates.Loaded)            .AddTrigger(new LoadingTrigger(LoadingManager) {ActiveValue = MainStates.Loaded});    Flickr = flickr;} public async Task Load(){     using (LoadingManager.Load())    {        var photos = await Flickr.LoadPhotos();        photos.DoForEach(Photos.Add);    }          } [...]

Building a Flickr Viewer App with BuildIt.Lifecycle

Tue, 16 Feb 2016 10:14:00 +0600

Last week at the Mobile .NET User Group I presented on the BuildIt.Lifecycle for the first time. The main motivation wasn’t to try and get people to start using it (although I’d definitely welcome feedback from anyone who does), it was really to try to get developers to start thinking differently about the way that they write applications. Instead of thinking of their application in terms of the apis that any one platform offer (and I treat XForms as just another platform, even though it sort of in-part aggregates iOS/Windows and Android) or in terms of raw navigation constructs (eg Activities/Intents, ViewControllers or Pages), but more in terms of states within their application. Applications are littered with states, whether they be the states of a button (Normal, Focussed, Pressed, ToggledOn etc) or visual states of a Page (a Windows concept but you can think of visual states as being the different layouts of any given page/view of your application). In fact if you think of your application as a whole you realise that you can map the entire navigation within your application as just a series of state transitions, with your pages/views being the states that the application can be in. This is indeed the foundation of BuildIt.Lifecycle. One other point I’ll make before jumping into building the Flickr Viewer application, which should demonstrate the core of the BuildIt.Lifecycle framework, is that most application frameworks, at least for mobile platforms, have been built around the notion of a single window or frame that houses the content that the user is currently looking at. As such most of the frameworks have some metaphor that maps to the application as a whole (often called the App or Application class), and is assumed to be a singleton. In exploring the use of states to model applications, it became evident that there are some platforms, such as Windows and Mac, where this assumption breaks down, and that in fact the framework needs an additional metaphor that maps to each window within an application. I’ve settled on Region for the timebeing, and there’s no surprises that there is a mapping between an instance of a Region in the framework to a Window presented at runtime. This should make more sense once we explore creating the application; alternatively there’s a post on working with Additional Windows using Regions with BuildIt.Lifecycle. Let me start by giving an example of visual states, just to warm up and get us all thinking about using states to represent an application, or parts of the application. I’m going to start by creating a new Universal Windows Platform project, based on the Blank App (Universal Windows) project template, called FlickrViewer. Next I’ll create another project, this time called FlickrViewer.Core, based on the Class Library (Portable) template, keeping the defaults in the Add Portable Class Library targets dialog. To complete the setup of the projects, I just need to add a reference from the FlickrViewer UWP project to the FlickrViewer.Core PCL project. The last reference I’m going to add initially is to the Microsoft.Net.Http and Newtonsoft.Json NuGet packages (Note that under the Install and Update Options the Dependency behaviour is set to Highest, and both packages are install into both projects).   I’m going to add the FlickrService class (and corresponding IFlickrService interface) that’s listed at the end of this article, which I’ll use to download content from the public flickr feed, to the PCL. This application is going to consist of two pages, the first will display a list of images retrieved from the Flickr public feed; the second page will display the details of the image selected from the first page. I’ll add another page at this point called DetailsPage.xaml, based on the Blank Page item template.Next, I’m going to switch across to Blend and cr[...]

Conditional Back Button Visibility with BuildIt.Lifecycle

Sat, 06 Feb 2016 04:12:13 +0600

In my post, Adding Back Button Support to Xamarin.Forms with BuildIt.Forms, I showed the basic support I’d added to BuildIt.Lifecycle to handle showing/hiding the back button depending on whether there were previous states. The back button visibility is actually more complex than that as there may be conditions on the current page (ie the current state/view model) that determine whether clicking back should be possible. To keep things simple I’m going to assume that if clicking back is possible, the back button will be shown, otherwise it will be hidden – this may not suit everyone as you may want to show the back button but have it disabled (personally I don’t like this, as it’s hard for the user to understand why the back button is disabled). I’ve just added support to the states and corresponding viewmodel management to detect if the current view model is in a blocked state.

There is an interface IIsAbleToBeBlocked that a view model can implement in order to both return an IsBlocked property and raise an event when it changes. This interface has also been added to the BaseViewModel class to make it easier for developers. For example this method can be used within a view model to toggle the visibility of the back button. If IsBlocked is true, the back button will be hidden.

public async void Run()
    for (int i = 0; i < 10; i++)
        IsBlocked = !IsBlocked;
        await Task.Delay(1000);

Note that the IsBlocked property works in conjunction with the HasHistory property on the state group (which maps to the back stack at a page level). If there is no history in the state group (ie at the first stage of the application – the first page of the application), then the back button won’t be shown, irrespective of the IsBlocked property.


Arriving or Leaving a ViewModel with BuildIt.Lifecycle

Wed, 03 Feb 2016 18:35:39 +0600

Often when arriving at a page/view it’s necessary to invoke some code in order to load data, or refresh the contents on the page. Of course, this needs to happen within the ViewModel. For BuildIt.Lifecycle, this is means implementing the IArrivingViewModelState interface which defines a single method, Arriving, which will get invoked when the user arrives at the page/view (and the corresponding viewmodel).

public async Task Arriving()
    await Task.Delay(2000);
    Name += ".... arrived ....";

Note that the method returns a Task, so you can do asynchronous code in order to retrieve data.

On the Windows platform the Universal Windows Platform has methods OnNavigatedTo, OnNavigatingFrom and OnNavigatedFrom which can be overridden in the code behind of a Page. These correspond to when a user arrives, is about to leave and has left a page. The Arriving method in BuildIt.Lifecycle maps to the OnNavigatedTo method. There are two more interfaces, IAboutToLeaveViewModelState and ILeavingViewModelState, which can be used to define methods AboutToLeave and Leaving. These methods map to the OnNavigatingFrom and OnNavigatedFrom methods.

One thing to note about the AboutToLeave method is that it has a CancelEventArgs as a parameter. The code in the AboutToLeave method can set the Cancel property on this parameter to true in order to cancel the navigation away from the page (note that this maps to cancelling the state change which drives the change in pages).

public async Task AboutToLeave(CancelEventArgs cancel)
    cancel.Cancel = true;


Adding Back Button Support to Xamarin.Forms with BuildIt.Forms

Sun, 31 Jan 2016 17:54:50 +0600

In my previous post I discussed the support I added for hardware and virtual back buttons in a Universal Windows Platform application (UWP) using BuildIt.Lifecycle. At an application level the back button (irrespective of whether it’s a hardware back button, such as on a phone, or a virtual back button, such as in desktop or tablet mode) is designed to return the user to the previous state of the application. In most cases this correlates to going to either the previous page in an application, or to the previous application, if the user is on the first page of the current application. Occasionally, there may be sub-states within a page, in which case the back button should be able to step back through those states, before causing the application to go back to the previous page.

This means that the back button should be applied at the highest level of the active window, which means passing it into StateManager of the region that correlates to the active window. In a UWP application, this is relatively straight forward as the application can subscribe to the BackRequested event, for example:

SystemNavigationManager.GetForCurrentView().BackRequested += BackRequested;

In the event handler, the StateManager for the region is queried to find out if a previous state exists. If it does, a call to GoBackToPreviousState is made.

Unfortunately Xamarin.Forms (XForms) doesn’t offer a global event for the back button. Instead it’s up to every page to override the OnBackButtonPressed method and return true if the back navigation should be cancelled. Having every page of the XForms application inherit from a custom base page isn’t an option I wanted to force upon users of this library. Luckily it’s not necessary to intercept the OnBackButtonPressed method on every page; it can instead be intercepted in the NavigationPage at the root of the application. By providing a CustomNavigationPage class, and requiring that it be used as the root of the application, it’s possible for the back button to be intercepted and applied to the active region.


Back Button Support in BuildIt.Lifecycle

Sun, 24 Jan 2016 05:10:00 +0600

Previously I’ve dealt with going back to previous pages based on user interaction on the current page (eg hitting a back button that triggers an “end of state” behaviour to go back to the previous page). However, another common scenario is for the user to press tha back button, either on their device (eg the Windows Phone hardware back button) or a virtual back button (eg the virtual button that’s available to Windows 10 UWP applications either in the task tray (running in tablet mode) or in the top navigation bar, when running in desktop mode). This wasn’t currently handled, so I’ve added handlers for both the hardware back button and the virtual back button to the UWP branch of BuildIt.Lifecycle. This work isn’t totally complete because at the moment it assumes that the decision as to whether the current page supports a back operation is determined only by the root level StateManager – this may not be the case if you have a view model that has business logic that determines whether the current page can be navigated way from.

This update also supports hiding and showing the virtual back button when a UWP application is run in desktop mode eg:

(image)  (image)


Book: Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform Your Business

Sat, 23 Jan 2016 19:12:00 +0600

If you’re interested in mobile strategies for line of business applications, you can’t go past this read, recently authored by Rob Tiffany. The book itself actually stems from a series of tweets Rob did a while ago. Each section starts with a tweet, followed by a more detailed discussion that both sets context and discusses current thought leadership in the area of mobile strategies for business applications.

One of the biggest takeaways, which actually couples the content of Rob’s book with my own thoughts on enterprise applications, is that businesses need to do more to move quicker in the modern technology enviornment. This means getting rid of antiquated processes, such as SOEs, in favour of more agile mechanisms such as Windows as a service. Applications are no different, old/legacy applications should be migrated, updated, rebuilt or retired in order to allow organisations to be more agile.

I also believe that applications within an organisation, whether they be mobile, desktop or web, should have a lifecycle in which they are created, maintained and then retired. If you aren’t maintaining, and ideally updating/improving, an application, you’d better look at retiring it. If you don’t, you’ll risk slowing your organisation down over time.


Fixing Back Behaviour and Navigation Button in Xamarin Forms with BuildIt.Lifecycle

Fri, 22 Jan 2016 12:57:36 +0600

There were two issues that I identified in my post, Using BuildIt.Lifecycle with Xamarin Forms, which were to do with the navigation between pages

1. The back operation actually did a forward navigation to a new page

2. The navigation button was always showing that there was a previous page, even if there wasn’t

The first issue was fixed with an update to the BuildIt.Lifecycle.XForms library which picks up on the IsNewState flag during state transition to determine whether to do a forward navigation (ie a PushAsync) or a backward navigation (ie a PopAsync).

The second issue was fixed by looking at the Navigation.NavigationStack and based on whether there were any entries in there, toggle whether the navigation bar is shown. The following would hide the navigation bar (it’s a static method on the NavigationPage class).

NavigationPage.SetHasNavigationBar(NavigationRoot, false);


Visual States in XForms with BuildIt.Lifecycle

Thu, 21 Jan 2016 09:53:20 +0600

When I created the layout for the AboutPage in my post, Using BuildIt.Lifecycle with Xamarin Forms, I cut out most of the elements to make it quicker to get something up and running. The irony is that fixing up the AboutPage to include a SplitView like pane was actually relatively quick, although there’s a bit of polish that needs to be added to make it look great. The following is the XAML for the AboutPage which includes two columns: the left column, initially hidden, includes the Close button which allows the user to navigate back to the home page of the app; the right column holds a couple of buttons that can switch states of the page between Expanded and Minimised. Note that there is another button that sits in the top left corner which will simply toggle between the states.                                

Using BuildIt.Lifecycle with Xamarin Forms

Wed, 20 Jan 2016 09:05:00 +0600

Leaving the Universal Windows Platform behind for a little bit I wanted to show that the BuildIt.Lifecycle framework can be used to drive a Xamarin Forms (XForms) application. The first step is to create a Xamarin Forms project. In this case I’ll select the Portable option. This will actually create four projects, one which is contains the actually application logic, including the XAML markup for the pages, and then three platform specific projects for iOS, Droid and Windows Phone. The platform specific projects are where any code required for device integration or custom UX goes for each platform. After creating the projects, the first thing to do is to upgrade the Xamarin.Forms NuGet reference to the latest version (v2.0.1.6495 at time of writing). The next thing to do is to add references to the BuildIt.Lifecycle NuGet packages including the Xamarin Forms specific package ( ). I had a few issues here because I initially had the dependency setting in the NuGet manager set to Lowest and it refused to install one of the dependencies (NuGet still isn’t clever enough some times to resolve everything properly). Switching this to Highest, which I think should be the default, fixed this issue. Of course, the core XForms project needs a reference to the SimpleStates.Core library which contains all my application, region and view model classes. At this point I realised I hadn’t set the PCL profile correctly on the project. Updating this turned out to be a bit of a mission as Visual Studio insisted the project had to be switched to NuGet v3, which you can’t do with any packages installed (according to the error message). So I had to uninstall all the NuGet packages (in the correct order) one at a time, and then update the targets as per the Change Targets dialog for the project. Now that the projects have all the references I need, it’s time to wire up the application. To do this I need to initialise the BuildIt.Lifecycle application, and I need a XForms page that maps to each of the pages (ie my states) in the application. Creating the pages is the easiest thing as they all come straight from the Forms Xaml Page template (no changing of base page required!!). The image shows me creating the MainPage but I also added a SettingsPage, AboutPage and LandingPage into the Pages folder in my XForms PCL project. Hooking up the BuildIt.Lifecycle framework was also relatively easy. In the App.cs, I simply replace the in-code page that’s created when you create the new project with the following: public class App : Application{    public App()    {        LifecycleHelper.RegisterView().ForState(AppStates.Home);        LifecycleHelper.RegisterView().ForState(AppStates.Settings);        LifecycleHelper.RegisterView().ForState(AppStates.About);         LifecycleHelper.RegisterView().ForState(AdditionalStates.Landing);         MainPage = new NavigationPage();        StartApplication();    }     private async void StartApplication()    {        var core = new SimpleStatesApplication();        var wm = new WindowManager(MainPage as NavigationPage, core);        await core.Startup(builder =>    &nbs[...]

Windows Hello (Beta) on Lumia 950 XL

Tue, 19 Jan 2016 08:44:41 +0600

Yesterday, after my Lumia 950 XL arrived, I noted that one of the two features I was going to try was Windows Hello. I want to start by saying that I now have this on both my Surface Book and the Lumia 950XL, and I’ve been using it on the former for quite some time now. Windows Hello on the Surface Book absolutely rocks – it’s not as instant sign on as say the Touch ID sign in capability on the iphone, which is virtually instantaneous on the latest iphones/ipads, but it is still relatively quick and definitely hands free. The latter is useful if you don’t have the keyboard attached. Unfortunately my experience on the Lumia 950 XL has been disappointing at best, frustrating in some cases. I’ve gone in and repeatedly try to improve recognition but despite this Windows Hello only recognises me less than 50% of the time. What’s worse is that after not recognising me a couple of times it stops trying and forces me to use PIN to unlock. It would be good if it would prompt and suggest PIN to unlock, followed by perhaps a suggestion to improve recognition (perhaps to allow for different lighting conditions etc) but this should only be a suggestion, the camera should still try to identify me, especially since my head is in front of the camera and it should be able to at least detect the presence of a head, even if it can’t identify that it’s me. The disappointing thing is that even when it does recognise me, it’s no quicker than me swiping up and entering my 4 digit PIN, and you look much less of an idiot doing it. I feel that the integration of a finger print reader would have been much better – less chance of you putting your finger in the wrong place and less environment factors to account for. Not to mention the technology is probably cheaper than the camera required to do Windows Hello with a camera. This bring me to the final point of this post which is that I’ve bought a production device which comes with the RTM build of Windows 10 Mobile. Now of course, Windows is now a service, which means that patches and updates should come through progressively but at this point no updates have come out for regular customers. If you go to Settings and look at setting up Windows Hello, it is clearly marked as Beta…. WTF! Why have I got Beta features on a device I’ve paid a lot of money for? I don’t know when it became acceptable to ship Beta features to end customers but I think it traces back to Google (if you recall Google was in Beta for years before this tag was removed from their service). Beta testing is there for a purpose, to iron out bugs before you ship to end customers. Now that’s not to say that you can’t have some end customers as beta testers, but they should be invited/request to take part, rather than assume that every customer will tolerate unpolished, incomplete or broken features. Microsoft shipping Beta features to end customers just points to why Apple dominates the mobile market and why iOS customers rarely switch to other platforms. [...]

Windows 10 Microsoft Developer Camp in Sydney and Melbourne

Mon, 18 Jan 2016 10:53:32 +0600

Microsoft Dev Camps are no cost, hands-on, technical training events for developers led by Microsoft experts. Sydney 23rd February – Register Melbourne 25th February – Register Agenda Time Module title Hands-on / theory / demo 8:30am – 9:15am Registration and welcome Theory 9:15am – 10:15am Introduction to Windows 10 UWP Theory + demo 10:15 am – 10:30am Morning tea 10:30am – 11:30am Adaptive UI Theory + hands-on 11:30am – 12:00pm Live tiles & notifications Theory + demo 12:00pm – 1:00pm Lunch 1:00pm – 2:00pm Edge + hosted web apps Theory + hands-on 2:00pm – 3:00pm Cloud Services & connected experiences Theory + hands-on 3:00pm – 3:30pm Afternoon tea 3:30pm – 4:30pm More personal computing Theory + hands-on 4:30pm – 5:00pm Store & monetisation Theory + demo 5:00pm – 5:30pm Wrap up Theory [...]

Microsoft Lumia 950, Windows Hello and Continuum

Mon, 18 Jan 2016 09:39:47 +0600

Due to an issue with the USB dock on my Lumia 640XL preventing me deploying apps for debugging, I went ahead and ordered a Lumia 950 XL which arrived today. The unboxing experience went well and as per most new phones there’s the normal down time whilst you transfer and reinstall apps on the new device. There were two features that I really wanted to try out:

Windows Hello

I’ve been using my Surface Book for a while now, so I’m used to the speed and convenience of the Windows Hello sign in experience which means I can just look at my monitor and it signs in. On the phone the experience is basically the same – it looks for you and signs you in. However, I do feel that it’s actually slower than simply tapping the pin code. At this stage I’ll leave Windows Hello enabled but I suspect that it may annoy me, more than it is a convenience.


I don’t have one of the continuum docks yet, and since I purchased a grey-imported phone I wasn’t eligible for, the Microsoft Australia offer for getting a free dock (personally I think this should be open to anyone willing to sync $700+ dollars into a Windows Phone at this point given the dire lack of feature complete apps). However, I do have a TV that has a Miracast dongle ( attached to it, so I went ahead and tapped the NFC pad, and 10 seconds later the device was connected, displaying out my TV. The phone turns into a track pad and the whole TV is used for whichever app is being displayed.

I went and downloaded an app we’ve just helped deliver - Looks brilliant running at full desktop size on a TV screen.


Keeping Visual States in Sync with Application States using Adaptive Triggers and BuildIt.Lifecycle

Sun, 17 Jan 2016 08:02:00 +0600

In earlier posts on BuildIt.Lifecycle I’ve covered how changing state via the StateManager can trigger events that will cause changes in visual states on the corresponding page. With the Universal Windows Platform (UWP) we have visual state triggers which can be used to invoke state changes from within the view. For example an AdaptiveTrigger can cause a change in visual state based on the size of the window, which I covered in the post, Using the Universal Windows Platform SplitView Control with Visual States and BuildIt.Lifecycle. These two mechanisms of changing visual states are independent and thus would lead to an inconsistent experience when it comes to maintaining state. For example, if I update the AboutViewModel to include state definitions that modify a Data property, then when the state changes the value of Data will change between “Minimised” and “Expanded” private string data;public string Data{    get { return data; }    set    {        data = value;        OnPropertyChanged();    }} public AboutViewModel(){     StateManager        .Group()        .DefineState(AboutExpandStates.Minimised)            .Target(this)                .Change(x => x.Data, (x, c) => x.Data = c)                .ToValue("Minimised")        .DefineState(AboutExpandStates.Expanded)            .Target(this)                .Change(x => x.Data, (x, c) => x.Data = c)                .ToValue("Expanded");} If the application was to change state by invoking ChangeState on the StateManager, this would trigger the appropriate change in Visual State on the page. If the user were to resize the page, the AdaptiveTriggers would kick in, causing a change in the Visual State. However, this change wouldn’t be reflected in the StateManager, thus not updating the value of Data (ie would say “Minimised” when the SplitView was expanded, or saying “Expanded” when the SplitView was collapsed). Luckily the VisualStateGroup class in UWP raises a CurrentStateChanged event, which can be intercepted and used to route the update back in the StateManager. This has been added to BuildIt.Lifecycle to ensure consistence between the state of the StateManager and the corresponding visual states. In the same way as the name of each VisualState has to match the enumeration value, the name of the VisualStateGroup has to match the name of the enumeration itself. [...]

Toggling the SplitView using Visual States

Sat, 16 Jan 2016 19:16:11 +0600

Yesterday when I was Toggling the SplitView Pane using a Hamburger Button in a UWP Application, I did it by simply inverting the IsPaneOpen property on the SplitView. This is in conflict with the visual states I had previously declared. An alternative would be for the button to invoke a state change on the AboutViewModel – this relies on knowing what the current state is, as shown in the following code which sits within the AboutViewModel.

public void ToggleSplitView()
    var group = StateManager.StateGroups[typeof (AboutExpandStates)] as StateGroup;
    var current = group.CurrentState;
    var current = StateManager.CurrentState();
    StateManager.GoToState(current != AboutExpandStates.Expanded
        ? AboutExpandStates.Expanded
        : AboutExpandStates.Minimised);

Update: There is now a CurrentState method on the StateManager which eliminates the need to explicitly grab a reference to the state group. See bold lines in code above for the change


Toggling the SplitView Pane using a Hamburger Button in a UWP Application

Fri, 15 Jan 2016 19:29:40 +0600

Yesterday (Using the Universal Windows Platform SplitView Control with Visual States and BuildIt.Lifecycle) I introduced a SplitView into my sample application where I used a couple of buttons in the content. In a lot of applications the SplitView will be triggered by either AdaptiveTriggers used in conjunection with the visual states, or via a hamburger button. Today I’ll add both of these to our application. Firstly a couple of AdaptiveTriggers added to the visual state definitions:                                                                                                                                                                                 As the user adjusts the width of the window the Pane of the SplitView will open and close depending on whether the window is wide enough. Secondly, I need to add a hamburger button to the layout of the page. This is a regualr button control, styled to be a hamburger button – in this case the style for the hamburger button was taken from the UWP samples.

Using the Universal Windows Platform SplitView Control with Visual States and BuildIt.Lifecycle

Thu, 14 Jan 2016 11:51:17 +0600

In this post I’m going to add a SplitView to the About page. I’ve also created two visual states that will control whether the Pane of the SplitView is visible or not (ie IsPaneOpen) and whether the display behaviour is for it to overlay or shift the content over (ie Inline). In the main content area I’ve also added two buttons which will be used to switch between each visual state. Lastly, in the SplitView.Pane has a Close button which will be used to return to the previous page in the application.                                                                                                                                                                                                                                                                                                

Additional Windows using Regions with BuildIt.Lifecycle

Wed, 13 Jan 2016 10:01:15 +0600

In the first post on Getting Started with BuildIt.Lifecycle I touched on the notion of an application region being a logical representation of a Window that’s part of an application. Most Windows Phone, iOS and Android applications will only have a single region but the very nature of Windows lends itself to multi-windowed applications. In this post we’ll extend the sample application to launch a new Window by creating a new region within the application. We’ll start with the declaration of the region: public enum AdditionalStates{    Base,    Landing} public class AdditionalRegion : StateAwareApplicationRegion{     public AdditionalRegion()    {        StateManager.GroupWithViewModels()            .StateWithViewModel(AdditionalStates.Landing)                .OnComplete(DefaultCompletion.Complete)                .CloseRegion(this)            .EndState();    }     protected override async Task CompleteStartup()    {         await base.CompleteStartup();         await StateManager.GoToState(AdditionalStates.Landing, false);    }} You may notice this is slightly different from the PrimaryRegion I defined in my initial post as it inherits from the StateAwareApplicationRegion instead of just ApplicationRegion, and that there’s no StateManager property. The StateAwareApplicationRegion was added as a convenience class, which contains the StateManager property and implements the IHasStates interface. Note that both regions in my sample application now inherit from this class. There is only a single state defined for the AdditionalRegion, which will correlate to the only page that will get loaded. When this region is started, the state manager transitions to the Landing state, which will display the LandingPage. In order for this to work, we need to create and correlate a LandingPage to the Landing state. I’ve added a page to the application based on the Blank Page template, called LandingPage. In App.xaml.cs I then needed to add the association between the new page and the Landing state: LifecycleHelper.RegisterView().ForState(AdditionalStates.Landing); On the MainPage of the application I’ve added another Button which simply calls a new OpenAnotherWindow method on the MainViewModel. private void AnotherWindowClick(object sender, Windows.UI.Xaml.RoutedEventArgs e){    ViewModel.OpenAnotherWindow();} The OpenAnotherWindow method simply calls OnComplete with a new enumeration value of AnotherWindow (this enumeration value is independent of the fact that I’ll be using it to open a new window, I could have called it “ShowMeTheMoney” so long as it correlates to the handler I’ll define in the PrimaryRegion). public void OpenAnotherWindow(){    OnComplete(MainCompletion.AnotherWindow);} As I just mentioned, I need to define what happens when OnComplete is called. To do this I need to update the state declaratio[...]

Refactoring Data Passing Methods in BuildIt.Lifecycle

Tue, 12 Jan 2016 10:57:24 +0600

In my earlier post, Passing Data Between States with BuildIt.Lifecycle, the state declarations for the primary application region started to look really messy. As promised I’ve tidied up the extension helper methods, making it much easier to define delegates that are invoked when changing to and from a state. The updated state declartion now looks like: StateManager.GroupWithViewModels()    .StateWithViewModel(AppStates.Home)        .OnCompleteWithData(MainCompletion.Settings,vm=>vm.HelloWithTime)            .ChangeState(AppStates.Settings)        .OnCompleteWithData< AppStates, MainViewModel,MainCompletion,string>(MainCompletion.About,null)            .ChangeState(AppStates.About)        .WhenChangedTo(async vm => await vm.LoadData())    .EndState()                    .StateWithViewModel(AppStates.Settings)        .OnComplete(DefaultCompletion.Complete).ChangeToPreviousState()        .WhenChangedToWithData((vm, d) => vm.SettingsTitle = d)    .EndState()                    .StateWithViewModel(AppStates.About)        .WhenChangedToWithData((vm, d) => vm.AboutTitle = d)    .EndState(); Note that if you’re attempting to use these updates they haven’t yet made their way into the NuGet packages. I’ll endeavour to update these packages later this week. In the meantime I’d recommend downloading the source from the BuildIt repository on GitHub. [...]

Loading Data Using Services with BuildIt.Lifecycle

Mon, 11 Jan 2016 02:51:45 +0600

The BuildIt.Lifecycle automatically creates instances of ViewModels and associates them with the corresponding page/view as the user steps between application states. Behind the scenes this uses Autofac to create these instances and ensure any dependencies are resolved. ViewModels that require access to device hardware, or to services that load or save data, can simply include the interface in the constructor. Take the following example where the MainViewModel relies on an instance of the IDataService interface to populate the Contacts collection. public interface IDataService{    Task> LoadContacts();} public class MainViewModel : BaseViewModelWithCompletion{    public ObservableCollection Contacts { get; }=new ObservableCollection();     private IDataService Data { get; }    public MainViewModel(IDataService data)    {        Data = data;    }    public async Task LoadData()    {        var contactList = await Data.LoadContacts();        contactList.DoForEach(Contacts.Add);    } We need to make two changes to our application declaration. The first is to register the implementation of IDataService, which we’ll do in App.xaml.cs var core = new SimpleStatesApplication();var wm = new WindowManager(core);await core.Startup(builder =>{    builder.RegisterType().As();}); public class UWPDataService : IDataService{    public async Task>  LoadContacts()    {        return new []{"Joe", "Bob", "Frank"};    }} The other change is to then invoke this method when the MainViewModel is used, this is when the Home state is changed to. We add the following to our state declarations (group.Item2.States[AppStates.Home] as IViewModelStateDefinition)    .WhenChangedTo(async vm => await vm.LoadData()); Note that we can also register services as part of our application class, allowing them to be registered within the PCL, rather than the platform specific libraries. This is useful for services that you want to use the same implementation for all supported platforms. public class SimpleStatesApplication : RegionAwareBaseApplication{    protected override void RegisterDependencies(ContainerBuilder builder)    {        base.RegisterDependencies(builder);        builder.RegisterType().As();    }} The ILogService is used within BuildIt.Lifecycle, so registering this implementatino will allow you to view the diagnostic information in the Output window within Visual Studio. [...]

Passing Data Between States with BuildIt.Lifecycle

Sun, 10 Jan 2016 04:31:26 +0600

Yesterday I discussed in my post, Navigating Back using State History with BuildIt.Lifecycle, how we needed to extend the state manager concept to understand and track state history. The next challenge that app developers face, that doesn’t fit nicely into the current state manager concept is that you often need to pass data between pages of the application. Think of a simple example where you have a list of contacts on one page; the user taps on one of those contacts and is taken to a new page that shows the details of that person. What you need to pass between pages is information about which contact the user tapped. I’ll discuss later how we can pass data between states, and thus view models, later in the post, but first I wanted to dig into the concept of passing data between pages a bit further. When the user tapped on the contact in the list, there is a lot of information that we can record about that event: - Mouse/Touch position (don’t forget we’re not just dealing with mobile devices, apps are a big part of the desktop experience on Mac and PC now) - List index (the index of the item tapped in the list) - List item (the object in the list that corresponds to the cell that was tapped) - Item Id (some sort of unique identifier of the item that was tapped) With all these pieces of information, the question is which one to pass to the details page. Let’s review them individually: - Mouse/Touch position – this in itself isn’t very useful as it only has meaning on the page that’s currently in view and that point in time. For example, if the user were to scroll the list, all of a sudden this information is useless as it now points to a different cell in the list - List index – this is only useful if the details page has a reference to exactly the same list that is used to populate the contacts list page. If the underlying data set changed (eg sync with backend caused new contacts to be downloaded), then the list index might now point to a different item - List item – if the items in the list contain all the details necessary to populate the details page then passing the list item to the details page is ok. However, if you have a large list off contacts, chances are you only load enough data about each contact to display the item in the list (eg perhaps only photo and name). In this case, passing the whole entity isn’t that useful since the details page has to load the whole contact anyhow. The other point worth considering is about serialization of navigation parameters – depending on the platform there are mechanisms for persisting navigation stack, including data parameters; some of these have size and complexity constraints on the data passed between pages. - Item Id – this is probably the best choice for this scenario. It contains enough information for the contact to be loaded. If performance is a concern (ie you want the contact summary information to be instantly available when the user arrives at the details page, even if details have to be progressively loaded), then you should cache the contact summary information in memory in a service which can be accessed as soon as the details page is loaded. The cache service might also cache the last X number of loaded contacts in memory to make it quick for a user to go between contacts. Ok, so this works for this scenario but how do we summariz[...]

Navigating Back using State History with BuildIt.Lifecycle

Sat, 09 Jan 2016 04:40:28 +0600

So far I’ve only discussed transitioning between states with an assumption that every transition is forward looking and that our state manager doesn’t track any sort of history. Other than simple applications, or poorly architected applications that don’t make use of the devices back navigation feature, it is a requirement for most applications to track the page/view/state that the user was previously in, allowing them to easily navigate back to where they just came from. This doesn’t fit into the normal concept of a finite state machine, since this wouldn’t normally have any “memory”. However, our state manager can easily be extended to include a history of which states have been visited. Again, let’s start with updating the user interface on our simple application. On the settings page we didn’t have any way to get back to the main/home page of our application. I’ll add a new button, resulting in the following XAML and codebehind:                         public sealed partial class SettingsPage{    public SettingsPage()    {        InitializeComponent();    }    private void GoBackClick(object sender, RoutedEventArgs e)    {        (DataContext as SettingsViewModel).Complete();    }} The only change I needed to make to the SettingsViewModel is to change the back class. Note that in this case since there is only one way that the state can be exited, I’m going to use the built in DefaultCompletion enumeration, which has a single Complete value. public class SettingsViewModel : BaseViewModelWithCompletion{    public void Complete()    {        OnComplete(DefaultCompletion.Complete);    }} The only thing left to do is to update the state declaration for my application to change to the previous state when the Settings state is Complete, as follows: StateManager.GroupWithViewModels

Declarative Navigation using BuildIt.Lifecycle

Fri, 08 Jan 2016 04:37:50 +0600

Yesterday I showed in the post, Navigation using BuildIt.Lifecycle, that by wiring up to events in the HomeViewModel, the PrimaryRegion could then change the application state, thereby causing a navigation to the corresponding page. Since this pattern is likely to be so common I felt there was an opportunity to refactor it. In this post I’ll show a couple of ways that we can now re-write this code. The first is just a refactoring of what we did yesterday. There are now OnEvent and ChangeState extension methods that allow for a declarative way to say that when an event occurs on the ViewModel, it should correspond to a change in state. You will notice that the method for declaring the state has changed from DefineViewModelState to StateWithViewModel, and that we now have an EndState method to conclude the state declaration. This is all in aid of trying to improve the fluid usage of this library and we’re likely to see a number of iterations of this before it settles, so apologies if this causes you to rework your code. StateManager.GroupWithViewModels()    .StateWithViewModel(AppStates.Home)        .OnEvent((vm, a) => vm.ShowSettings += a,            (vm, a) => vm.ShowSettings -= a)        .ChangeState(AppStates.Settings)        .OnEvent((vm, a) => vm.ShowAbout += a,            (vm, a) => vm.ShowAbout -= a)        .ChangeState(AppStates.About)        .EndState()    .StateWithViewModel(AppStates.Settings)        .EndState()    .StateWithViewModel(AppStates.About); This refactoring was all very good except it still required events to be declared in the ViewModel, including invoking methods etc. I suspect that the most common use of this pattern will be for a single event to be declared which includes an enumeration indicating what type of “completion” the ViewModel. For example in this case we’d have an enumeration which includes Settings and About values, and depending on which value is included in the event, we’d choose to change to the corresponding state (in theory you could use the same enumeration that is used to define the states (ie AppStates) but I would avoid this as it could get confusing as there would be an implied link, rather than explicit declaration of intent). Rather than every developer having to implement this pattern, we can simply change our MainViewModel to inherit from BaseViewModelWithCompletion and declaring an enumeration, MainCompletion: public enum MainCompletion{    Base,    Settings,    About} public class MainViewModel:BaseViewModelWithCompletion{    public void DisplaySettings()    {        OnComplete(MainCompletion.Settings);    }    public void DisplayAbout()    { [...]

Navigation using BuildIt.Lifecycle

Thu, 07 Jan 2016 04:58:09 +0600

In my post, Getting Started with BuildIt.Lifecycle, I showed how to get started with BuildIt.Lifecycle. The next step is to add basic navigation between pages/views. To do this, we need to change our mindset to again think of this as a state transition. Before I cover what I mean by this, let’s add two buttons to our Home page that we’ll use to trigger the navigation to either the Settings or About pages.             As you can see from the XAML there are event handlers wired up to the Click event on each of the Buttons. In each of the event handlers we simply route a call to a corresponding method on the ViewModel. private MainViewModel ViewModel => DataContext as MainViewModel; private void SettingsClick(object sender, RoutedEventArgs e){    ViewModel.DisplaySettings();} private void AboutClick(object sender, RoutedEventArgs e){    ViewModel.DisplayAbout();} Now we need to think about what displaying either the Settings or the About page means in the context of our application state. When the application is launched the PrimaryRegion transitions to the AppStates.Home state, which correlates to the HomePage being displayed. When the user clicks on either button, what we want the application to do is to transition from the Home state to the either the Settings or About state, depending on which button the user clicks. Unlike some other frameworks where you can navigate from one ViewModel to another ViewModel by calling a base method such as ShowViewModel or call Navigate on some sort of Navigation wrapper, the HomeViewModel doesn’t actually know anything about the states of region (this is the responsibility of the StateManager that’s part of the PrimaryRegion). Instead, what the HomeViewModel has to do is to raise an event signalling that an event has occurred that it needs assistance dealing with. So the implementation for DisplaySettings and DisplayAbout becomes: public event EventHandler ShowSettings;public event EventHandler ShowAbout;public void DisplaySettings(){    ShowSettings.SafeRaise(this);}public void DisplayAbout(){    ShowAbout.SafeRaise(this);} Note: SafeRaise is a helper method defined in BuildIt.General but with the new features in C# 6 you could also write this as: ShowAbout?.Invoke(this,EventArgs.Empty); With the HomeViewModel raising these events, we need to subscribe to them somewhere so that the PrimaryRegion can trigger the state change on its StateManager to go to either the Settings or About states. This is done by wiring and unwiring event handlers as part of the state transitions into and from the Home state: sm.DefineViewModelState(AppStates.Home)    .WhenChangedTo(vm =>    {        vm.ShowSettings += ChangeToSettings;        vm.ShowAbout += ChangeToAbout; &n[...]

Comments (0) - Read and Add your own Comments