Onionizing Xamarin Part 4

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2
  3. Part 3 on our Infrastructure layer: Onionizing Xamarin Part 3

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 4

In this section, we will look at the code for our actual Xamarin.Forms client implementation along with talking about building other Non-Xamarin clients into our solution, and sharing as much code between them as possible. This are our Client layer, and will include setting up our Views, ViewModels, IoC container, and start up process.

Client Layer

First thing is first, let’s build our ViewModels. These ViewModels are going to interface with our Application layer by making calls to our defined Service Interfaces that will be injected into the constructors of our ViewModels.

Some things to note: We are using MVVM Light in this example to make our MVVM and IoC easier to get going. So things such as the ViewModelBase class and the Set() method are coming from that library. You can choose to utilize a different library, or roll your own pretty easily. In either case, the principles are the same.

Let’s first abstract some universal properties into a BasePageViewModel.cs

public class BasePageViewModel : ViewModelBase
{
    private bool _isLoading;
    private bool _isEnabled;
    private string _title;
    private ObservableCollection<string> _errors;

    public bool IsLoading
    {
        get
        {
            return _isLoading;
        }
        set
        {
            Set(() => IsLoading, ref _isLoading, value);
        }
    }
    public bool IsEnabled
    {
        get
        {
            return _isEnabled;
        }
        set
        {
            Set(() => IsEnabled, ref _isEnabled, value);
        }
    }
    public ObservableCollection<string> Errors
    {
        get
        {
            return _errors;
        }
        set
        {
            Set(() => Errors, ref _errors, value);
        }
    }

    public string Title
    {
        get
        {
            return _title;
        }
        set
        {
            Set(() => Title, ref _title, value);
        }
    }
    public BasePageViewModel()
    {
        IsEnabled = true;
        IsLoading = false;
    }

    public override void Cleanup()
    {
        base.Cleanup();
        Errors = null;
    }
}

 

From here let’s make a ViewModel for each of our pages (in this example, we will just look at one “MainPage”)

MainPageViewModel.cs

public class MainPageViewModel : BaseViewModel
{
    private readonly IUserService _userService;
    private string _bodyTitle;
    private string _bodyText;
    public string BodyTitle
    {
        get
        {
            return _bodyTitle;
        }
        set
        {
            Set(() => BodyTitle, ref _bodyTitle, value);
        }
    }

    public string BodyText
    {
        get
        {
            return _bodyText;
        }
        set
        {
            Set(() => BodyText, ref _bodyText, value);
        }
    }

    private async void Initialize()
    {
        IsLoading = true;
        await Task.Delay(2000); // simulate load time
        var users = await _userService.GetValidUsers();
        if(users?.Data == null || users.Data.Count() == 0)
        {
            var user = await _userService.CreateUserAsync(new NewUser
            {
                FullName = "Felipe Fancybottom",
                Email = "feffancy@fancybottoms.com"
            });

            BodyText = user.Data.Email;
            BodyTitle = user.Data.FullName;
        }
        else
        {
            BodyText = users.Data.First().Email;
            BodyTitle = users.Data.First().FullName;
        }
        IsLoading = false;
    }

    public MainPageViewModel(IUserService userService)
    {
        _userService = userService;

        Title = "Onion Template";
        BodyTitle = "Loading Name";
        BodyText = "Loading Email";
        Initialize();
    }
}

Notice how we injected the IUserService in the constructor, and use that to lazy load some data into our bindable properties. When we create our view and set the BindingContext to this ViewModel, we will see the UI automatically update when those do. This example does it async right from the constructor, but you can load your data and set up your initial properties any way you’d like.

The next step is to initialize our Inversion of Control, Dependency Injection, and ViewModelLocator to tie all our layers together and allow us to automatically set the BindingContext of our Page.

If it makes sense to you, you can break the IoC set up into a separate project that references all the previous layers. For the sake of simplicity, we are going to do it in the same project as our Xamarin.Forms project.

IoCConfig.cs

public class IoCConfig
{
    public IoCConfig()
    {
        ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
    }

    public void RegisterViewModels()
    {
        SimpleIoc.Default.Register<MainViewModel>();
    }

    public void RegisterRepositories()
    {
        SimpleIoc.Default.Register<IUserRepository, UserRepository>(); // this is where you would change the registration to use a different repository
    }

    public void RegisterServices()
    {
        SimpleIoc.Default.Register<IUserService, UserService>();
    }

    public void RegisterProviders()
    {
        SimpleIoc.Default.Register<IUserDataProvider, UserDataProvider>();
        SimpleIoc.Default.Register<ICloudStorageProvider, AzureStorageDataProvider>(); // this is where you would change the registration to use a different provider
    }

    public void RegisterStores()
    {
        SimpleIoc.Default.Register<IUserStore, UserStore>();
        SimpleIoc.Default.Register<IStoreManager, StoreManager>();
    }
}

The purpose of this class is to wire up our dependencies as well as our actual container for the ServiceLocator. This example is using SimpleIoc which is packaged with MVVM Light.

Now that we have our other layers glued together, we just need to create our ViewModelLocator to automatically handle our bindings, then make calls to the IoCConfig when the ViewModelLocator is initialized.

ViewModelLocator.cs

public class ViewModelLocator
{
    public MainPageViewModel MainPage
    {
        get
        {
            return ServiceLocator.Current.GetInstance<MainPageViewModel >();
        }
    }
    public ViewModelLocator()
    {
        var iocConfig = new IoCConfig();
        iocConfig.RegisterRepositories();
        iocConfig.RegisterProviders();
        iocConfig.RegisterServices();
        iocConfig.RegisterViewModels();
        iocConfig.RegisterStores();
    }
}

In our constructor, we initialize our IoC, and also provide properties for each of our ViewModels, so that we can bind it easily in our XAML.

The last two steps here are to add a Resource in our App.xaml to our ViewModelLocator, and create our Page.

App.xaml


<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="OnionTemplate.App">
    <Application.Resources>
        <!-- Application resource dictionary -->
        <ResourceDictionary>
                <vm:ViewModelLocator xmlns:vm="clr-namespace:NAMESPACEOF.VIEWMODELLOCATOR;assembly=YOURPACKAGENAME" x:Key="Locator" />
        </ResourceDictionary>
    </Application.Resources>
</Application>

Now that we have our resource, let’s create our page and wire up the BindingContext in our XAML.

MainPage.xaml


<?xml version="1.0" encoding="UTF-8"?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="NAMESPACE.MainPage" BindingContext="{Binding Source={StaticResource Locator}, Path=Main}" Title="{Binding Title}">
    <ContentPage.Content>
        <StackLayout Orientation="Vertical" HorizontalOptions="Center" VerticalOptions="Center">
            <Label Text="{Binding BodyTitle}"/>
            <Label Text="{Binding BodyText}"/>
            <ActivityIndicator IsRunning="True" IsVisible="{Binding IsLoading}"/>
        </StackLayout>
    </ContentPage.Content>
</ContentPage>

There is nothing required to write in our code behind (MainPage.xaml.cs) since it is all automatically wired up.

Last but not least, set our page in our App.xaml.cs:

App.xaml.cs


public partial class App : Xamarin.Forms.Application
{
    public App()
    {
        InitializeComponent();

        MainPage = new NavigationPage(new MainPage());
    }
}

At this point, we should be able to run the application (assuming that the Xamarin.Forms app is started off in each platform the way the template sets it up).

So we have our Xamarin.Forms implementation. But what about other applications that can’t use Xamarin.Forms? Web apps? Xamarin.Mac apps? Cloud apps? WPF?

Here is one of the coolest parts of the entire Onion pattern. We can go ahead and add more projects into our Client layer. These layers can use the same models, interfaces, and in some cases, implementations! For projects where we would need completely different logic, such as a Web App for example, we can implement multiple versions of the Domain and Application layers.

In our web app, we could create another project in the Infrastructure layer (say Infrastructure.WebData) that uses Entity Framework and SQL. Then in our IoCConfig of our Web App, we call to register our Infrastructure.WebData implementations for our Domain.Interfaces.

As long as each project in the Client layer serves the same purpose of configuring Views, and starting up our application with our Inversion of Control, any type of application can live here and follow the same pattern.

The Client layer can also contain abstractions of controls or other utilities that can be referenced by the core Client projects.

What’s Next

In the next segment, we will look at how to integrate our individual mobile platforms, and how to inject custom platform-specific code with some examples using the HockeyApp SDK.

 

Next: Onionizing Xamarin Part 5

Advertisements

Onionizing Xamarin Part 3

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

Don’t forget:

  1. Part 1 on the general project structure: Onionizing Xamarin Part 1
  2. Part 2 on our Domain and Application layers: Onionizing Xamarin Part 2

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 3

In this section, we’ll start to dive into the code for our infrastructure layers (or at least what is important), including our business logic and data logic.

Let’s dive into the data layer.

Infrastructure.Data

This layer is our actual implementation of our Domain definitions, so we are going to implement things such as our Repositories, DataProviders, Stores, or anything else that interacts with our data directly.

From our previous post we defined our IGenericStore + IUserStore and our IGenericRepository + IUserRepository, so now let’s implement them.

GenericStore.cs and UserStore.cs

public class GenericStore<T> : IGenericStore<T>
{
    public List<T> Data { get; set; }
    public GenericStore()
    {
        Data = new List<T>();
    }
}

public class UserStore : GenericStore<User>, IUserStore
{
}

For the sake of just testing data, our store just contains a collection of data, however, this is where you could implement an observable collection, or more complex data types as well.

Now a look at the repositories – Our implementation of our repository is just going to use in-memory storage, but this is a place where you could implement SqlLite, Azure Mobile Tables, or local file storage instead. You could implement all of these easily and just switch out in your UserRepository which one it inherits! That’s one of the biggest bonuses of our Onion Architecture. The github repository demonstrates this well: https://github.com/SuavePirate/Xamarin.Onion/blob/master/src/OnionTemplate/OnionTemplate.Infrastructure.Data/Repositories/UserRepository.cs

GenericMemoryRepository.cs and UserRepository.cs

public class GenericMemoryRepository<T> : IGenericRepository<T>
{
    private readonly IStoreManager _storeManager;
    public GenericMemoryRepository(IStoreManager storeManager)
    {
        _storeManager = storeManager;
    }
    public void Add(T entity)
    {
        _storeManager.Set<T>().Data.Add(entity);
    }

    public void AddRange(IEnumerable<T> entities)
    {
        _storeManager.Set<T>().Data.AddRange(entities);
    }

    public Task CommitAsync()
    {
        return Task.FromResult(false); // we don't need to explicitly save changes
    }

    public Task<T> FindAsync(Func<T, bool> predicate)
    {
        var entity = _storeManager.Set<T>().Data.Where(predicate).FirstOrDefault();
    return Task.FromResult(entity);
    }

    public Task<IEnumerable<T>> GetAsync(Func<T, bool> predicate)
    {
        var entities = _storeManager.Set<T>()?.Data?.Where(predicate);
        return Task.FromResult(entities);
    }

    public void Remove(T entity)
    {
        _storeManager.Set<T>().Data.Remove(entity);
    }

    public void RemoveRange(T entities)
    {

    }
}

public class UserRepository : GenericMemoryRepository<User>, IUserRepository
{
    public UserRepository(IStoreManager manager)
    : base(manager)
    {
    }
}

That’s all we need to define for our data  layer for now. Next let’s look at our business logic layer and how it interacts with the data layer through references to our domain interfaces.

Infrastructure.Business

Our business layer is our implementation of our Application layer. So we are going to implement the IBaseService and IUserService we defined in the previous segment:

IBaseService.cs and IUserService.cs

public class BaseService : IBaseService
{
    public BaseService()
    {
    }

    public IEnumerable<string> Validate(object model)
    {
        if(model == null)
            return new List<string> { "Empty model received" };
        return null;
    }
}

public class UserService : BaseService, IUserService
{
    private readonly IUserRepository _userRepository;
    public UserService(IUserRepository userRepository)
    {
        _userRepository = userRepository;
    }
    public async Task<Result<UserTransferObject>> CreateUserAsync(NewUser model)
    {
        var errors = Validate(model);
        if (errors == null)
        {
            var entity = model.ToUser();
            _userRepository.Add(entity);
            await _userRepository.CommitAsync();

            return new Result<UserTransferObject>(new UserTransferObject(entity));
        }
        return new Result<UserTransferObject>(ResultType.Invalid, errors);
    }

    public async Task<Result<UserTransferObject>> FindByIdAsync(int userId)
    {
        var entity = await _userRepository.FindAsync(user => user.Id == userId);
        if (entity == null)
        {
            return new Result<UserTransferObject>(ResultType.Failed, "Could not find user with this Id");
        }
        return new Result<UserTransferObject>(new UserTransferObject(entity));
    }

    public async Task<Result<UserTransferObject>> RemoveByIdAsync(int userId)
    {
        var entity = await _userRepository.FindAsync(user => user?.Id == userId);
        if (entity == null)
        {
            return new Result<UserTransferObject>(ResultType.Failed, "Could not find user with this Id");
        }
        _userRepository.Remove(entity);
        await _userRepository.CommitAsync();
        return new Result<UserTransferObject>(new UserTransferObject(entity));
    }

    public async Task<Result<IEnumerable<UserTransferObject>>> GetValidUsers()
    {
        var entities = await _userRepository.GetAsync(user =>         !string.IsNullOrEmpty(user?.Email));
        return new Result<IEnumerable<UserTransferObject>>(entities?.Select(entity => new UserTransferObject(entity)));
    }
}

The biggest thing to point out is how the constructor for our UserService takes in an IUserRepository. Later we will set up our IoC container and inject our actual UserService so that the logic ties together. Doing this allows us to avoid referencing the Infrastructure.Data layer in our Infrastructure.Business layer which gives us full Separation of Concerns in our layers.

What’s Next

In the next segment, we’ll talk about implementing our Xamarin.Forms application, setting up our Inversion of Control and Dependency Injection, and tying it all together.

We’ll also look at each of our different platforms and talk about how we can utilize them without using Xamarin.Forms.

Finally, in the last segment, we will talk about how to truly utilize the Onion Architecture to test, pull, and change important pieces of our application without having to touch anything else.

 

Check out Part 4 to look at the Client Layer

Onionizing Xamarin Part 1

For those who just want code: https://github.com/SuavePirate/Xamarin.Onion 

A strong and scale-able architecture is important in applications, especially in Mobile Apps. APIs and SDKs are constantly changing, new technology is constantly released, and team sizes are always changing. A solid Onion Architecture can save a development team a lot of time by making it simple to change service implementations, restrict access to certain areas, making logic flow easy to follow, and making testing isolated blocks of code easier.

Some of the important topics this will cover:

  • Separation of Concerns
  • Inversion of Control
  • Dependency Injection
  • Model-View-ViewModel
  • Testability
  • Why all these things are important

Part 1

This first post will talk about the general project structure and high level role of each layer in the solution. Later posts will touch on the individual projects’ code, why things are where they are, using the structure to build out tests, and ways to bend or change the structure to work for you.

Project Structure

For this example we will be talking about Xamarin.Forms, but the same patterns can be applied in the exact same way without it.
Lets just take a look at the high level structure and layers of the solution:

xamarinonionsolution

Domain

This is the lowest level. Projects within Domain should not reference any projects outside of this layer and should also avoid referencing any external libraries.

Domain.Models

These are our base data models. This project shouldn’t reference any other projects, even within Domain.

Domain.Interfaces

These are the definitions for our data access layer. Repositories, Stores, etc. There should be no implementation in this project and should only reference the Model project.

Application

This layer is what defines our Services and Business logic without implementing any of it. Projects in this layer can only reference Model layers of Domain.

Application.Models

These are our application models such as input models, data transfer objects, as well as any helpers for mapping Domain models to these. This project will only reference the Domain.Models to help map them to DTOs or other models. This, however, is also optional. You could opt to handle mapping externally when the models are needed in business logic rather than in the Application layer.

Application.Interfaces

These are the definitions for our business logic layer. Services, Managers, etc. There should be no implementation in this project and it should only reference the Application.Models project

Infrastructure

This is where we implement our data and business logic.

Infrastructure.Data

This is the implementation of our Data access layer. Communicate with 3rd party data providers, local storage, databases, etc. Domain.Interfaces should be implemented here.

Infrastructure.Business

This is the implementation of our Business logic layer. Communicate with the data layer through contracts from the Domain.Interfaces. This project should NOT reference the Data project. Application.Interfaces should be implemented here

Clients

This is where we implement client logic, set up IoC, create ViewModels, and controls. If we are using Xamarin.Forms, this is where the PCL or Shared Library with Xamarin.Forms is. This Layer can reference any of the above layers in order to wire up IoC. If you have multiple Xamarin.Forms projects in one solution, they can both be here.

Clients.Controls

This is where reusable controls within Xamarin.Forms exist. Pretty straightforward.

Platforms

This is the section where the Native Projects live. If you have too many native projects for things like wearables, or the different TV OS’s, then it might make sense to break this section into smaller sections for things like “Apple”, “Google”, “Windows”, or something similar. But for the sake of this demo, we are only working with one project for each platform, so they live together.

This layer should only reference the Client layer and Binding Layer

Droid

This is the Xamarin.Android project. If any native services need to be called from one of the shared layers, the IoC set up can be extended into this project and one of the interfaces could be implemented here and registered.

iOS

This is the Xamarin.iOS project. As stated above, native services can be set up and injected from here as well.

UWP

This is the UWP project. As stated above, native services can be set up and injected from here as well.

Binding

This is where Xamarin Binding projects should be if there is a need for binding to any native libraries. As with the Platforms layer, if there are many different binding projects, this layer could be split into different sections for each OS. This layer should be exclusive and not reference any other layer.

Tests

This is where UI and Unit tests are. This layer can reference any other level in order to test them. This layer can wire up a completely different IoC container, contain mock projects for simulating any other layer, or any other external reference.

 

Continue on:

Onionizing Xamarin Part 2

Creating a Circular Image in Xamarin.Android

If you’re working with mobile applications, sometimes something as simple as creating a circular image can be a bit more time consuming than it should be. Here is the snippet I use to create Circular Images in Xamarin.Android to follow up with my post about Creating Circular Images in XAML.

CircleDrawable:


public class CircleDrawable : Drawable
 {

     Bitmap bmp;
     BitmapShader bmpShader;
     Paint paint;
     RectF oval;

    public CircleDrawable(Bitmap bmp)
     {
         this.bmp = bmp;
         this.bmpShader = new BitmapShader (bmp, Shader.TileMode.Clamp, Shader.TileMode.Clamp);
         this.paint = new Paint () { AntiAlias = true };
         this.paint.SetShader (bmpShader);
         this.oval = new RectF ();
     }

    public override void Draw (Canvas canvas)
     {
         canvas.DrawOval (oval, paint);
     }

    protected override void OnBoundsChange (Rect bounds)
     {
         base.OnBoundsChange (bounds);
         oval.Set (0, 0, bounds.Width (), bounds.Height ());
     }

    public override int IntrinsicWidth
    {
         get
         {
             return bmp.Width;
         }
     }

    public override int IntrinsicHeight {
         get {
             return bmp.Height;
         }
     }

     public override void SetAlpha (int alpha)
     {

     }

    public override int Opacity {
         get {
             return (int)Format.Opaque;
         }
     }

    public override void SetColorFilter (ColorFilter cf)
    {

    }
 }

And here is an example of how to use it:

var bitmap = new Bitmap(); //do something else here to create your bitmap
var circleImage = new CircleDrawable(bitmap);

Databinding a Windows FlipView with MVVM Light

MVVM Light is a great cross-platform MVVM Framework, and was chosen to be used in this example. However, it isn’t required to get the same results.

FlipViews were a great addition to the WIndows Control family for Windows Phone and Windows Store applications. It’s easily customized, simple to use, and can give your app a user friendly experience for anything from an image gallery, to a news reader. So let’s get to the code.

Let’s first build the model we are going to use for each of our views in our FlipView. I’m using a PCL for my Models and ViewModels and a Windows Phone 8.1 project for the xaml, but it works in the same fashion for Windows Store.

Here is our model:


public class RotatorItem
 {
     public string Title { get; set; }
     public string ImageUri { get; set; }
     public string Subtitle { get; set; }
 }

Now let’s look at a simple ViewModel with MVVM Light to hold our collection of SimpleRotatorItems.

public class LandingRotatorPageViewModel : ViewModelBase
 {
     #region Private Properties
     private ObservableCollection<RotatorItem> _rotatorItems;
     private RotatorItem _activeItem;
     #endregion

     #region Public Properties
     public ObservableCollection<RotatorItem> RotatorItems
     {
         get
         {
             return _rotatorItems;
         }
         set
         {
             Set(() => RotatorItems, ref _rotatorItems, value);
         }
     }
     public RotatorItem ActiveItem
     {
         get
         {
             return _activeItem;
         }
         set
         {
             Set(() => ActiveItem, ref _activeItem, value);
         }
     }

     #endregion
     public LandingRotatorPageViewModel()
     {
         var rotatorItems = new ObservableCollection<RotatorItem>();
         rotatorItems.Add(new RotatorItem { ImageUri = "/Assets/Logo.scale-240.png", Title = "Title 1", Subtitle = "Subtitle 1"});
         rotatorItems.Add(new RotatorItem { ImageUri = "/Assets/Logo.scale-240.png", Title = "Title 2", Subtitle = "Subtitle 2" });
         rotatorItems.Add(new RotatorItem { ImageUri = "/Assets/Logo.scale-240.png", Title = "Title 3", Subtitle = "Subtitle 3" });
         rotatorItems.Add(new RotatorItem { ImageUri = "/Assets/Logo.scale-240.png", Title = "Title 4", Subtitle = "Subtitle 4" });
         RotatorItems = rotatorItems;
         ActiveItem = rotatorItems.First();
     }
 }

Let’s go ahead now and get our markup done for our page with the FlipView:

<FlipView x:Name="SimpleFlipView" ItemsSource="{Binding RotatorItems}" Grid.Row="1" SelectionChanged="FlipView_SelectionChanged">
    <FlipView.ItemTemplate>
        <DataTemplate>
            <Grid>
                <Grid.RowDefinitions>
                    <RowDefinition Height="200" />
                    <RowDefinition Height="120" />
                    <RowDefinition Height="80" />
                </Grid.RowDefinitions>
                <Image Source="{Binding ImageUri}" Height="150" Grid.Row="0" VerticalAlignment="Top" Margin="0,50,0,0"/>
                <TextBlock TextWrapping="Wrap" TextAlignment="Center" Grid.Row="1" Text="{Binding Title}" FontSize="30" HorizontalAlignment="Center" Margin="20"></TextBlock>
                <TextBlock TextWrapping="Wrap" TextAlignment="Center" Grid.Row="2" FontSize="20" HorizontalAlignment="Center" Margin="20">
                    <Run Text="{Binding Subtitle}"></Run>
               </TextBlock>

            </Grid>
       </DataTemplate>
   </FlipView.ItemTemplate>
</FlipView>

Last but not least, let’s make sure our ViewModel is bound to our Page in our page Class:

 public sealed partial class MainPage : Page
 {
     private LandingRotatorPageViewModel _vm;
     public MainPage()
     {
          this.InitializeComponent();

          _vm = new LandingRotatorPageViewModel();
          this.DataContext = _vm;
     }

     /// <summary>
     /// Invoked when this page is about to be displayed in a Frame.
     /// </summary>
     /// <param name="e">Event data that describes how this page was reached.
     /// This parameter is typically used to configure the page.</param>
     protected override void OnNavigatedTo(NavigationEventArgs e)
     {
     }
}

Now that the Page’s DataContext is set to our ViewModel, the binding we placed on the FlipView element ‘ItemSource=”{Binding RotatorItems}”‘ will bind our FlipView’s Items to the items we created in the constructor for our ViewModel, and will use our ItemTemplate to create our items from the fields on the RotatorItems.

Now let’s take a look at our final result:

FlipView Item
First FlipView Item bound to ViewModel
wp_ss_20150502_0002
Second FlipView Item

So there you have it. An easy solution to using the Windows FlipView Control to display content that is bound to a ViewModel.

Adding a Simple Refresh Token to OAuth Bearer Tokens

If you’re using a .NET as your web platform and are looking to expand it to another platform such as mobile applications, and need to authenticate users from that external application, one of the best ways of going about it is through the use of OAuth Bearer Tokens.

James Randall has a great post here about getting started with the OAuth Bearer token Authentication. This post isn’t going to focus on getting started, but will use this example to expand upon.

Using Bearer (access) Tokens allows you to authenticate users without having to send their password through the pipes with each request. Using an access token in your header will let you authorize requests to your api as well as through SignalR or other web services.

Here is an example of the authorization header sent with a request to authorize a user:
“Authorize Bearer YOUR_ACCESS_TOKEN”

However, what happens when this token expires? Of course, you can set an outrageously long expiration date, but that is a security nightmare. You don’t want to store the users password locally to continuously send requests to get a new token. You also don’t want to require the user to re-login every time the token expires.

The solution? Refresh tokens! A refresh token will allow you to receive a new access token after it expires without sending the user’s password.

The first step is to create a RefreshTokenProvider that we can add during our Startup processing. Here is a simple Provider that will work for this example:


 public class SimpleRefreshTokenProvider : IAuthenticationTokenProvider
 {
    private static ConcurrentDictionary<string, AuthenticationTicket> _refreshTokens = new ConcurrentDictionary<string, AuthenticationTicket>();

     public async Task CreateAsync(AuthenticationTokenCreateContext context)
     {
         var guid = Guid.NewGuid().ToString();

         // maybe only create a handle the first time, then re-use for same client
         // copy properties and set the desired lifetime of refresh token
         var refreshTokenProperties = new AuthenticationProperties(context.Ticket.Properties.Dictionary)
         {
             IssuedUtc = context.Ticket.Properties.IssuedUtc,
             ExpiresUtc = DateTime.UtcNow.AddYears(1)
         };
         var refreshTokenTicket = new AuthenticationTicket(context.Ticket.Identity, refreshTokenProperties);

         //_refreshTokens.TryAdd(guid, context.Ticket);
         _refreshTokens.TryAdd(guid, refreshTokenTicket);

         // consider storing only the hash of the handle
         context.SetToken(guid);
     }

     public async Task ReceiveAsync(AuthenticationTokenReceiveContext context)
     {
         AuthenticationTicket ticket;
         if (_refreshTokens.TryRemove(context.Token, out ticket))
         {
             context.SetTicket(ticket);
         }
     }

     public void Create(AuthenticationTokenCreateContext context)
     {
         throw new NotImplementedException();
     }

     public void Receive(AuthenticationTokenReceiveContext context)
     {
         throw new NotImplementedException();
     }
 }

We can now use this provider to add the setting to our Startup.Auth.cs:


 OAuthOptions = new OAuthAuthorizationServerOptions
 {
     TokenEndpointPath = new PathString("/Token"),
     Provider = new ApplicationOAuthProvider(PublicClientId, UserManagerFactory),
     AuthorizeEndpointPath = new PathString("/api/Account/ExternalLogin"),
     AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(60),
     AllowInsecureHttp = true,
     RefreshTokenProvider = new SimpleRefreshTokenProvider() //REFERENCE TO PROVIDER

 };

Now we have our access token that expires every hour, and a refresh token that expires every year. The time-spans to use for both of these is completely up to you.

Now we can use requests like these with our external application-

Authorize with username and password:

Method: POST
Url: http://yourdomain/Token?username=yourusername&password=yourpassword&grant_type=password

Response:

{

"access_token":"VSt0JjzP-9PO6OFk-i_dp7Xs7RA4JTai_nv1FXxTiZ-iMoYjCt42Jw8eJqV66EouqAxnsHIUzDucHKSQUhEch9tftf_dNgi0pDKFUZn5UVJ0rybZ8keG4LjT2oI851D1OnE0Ij0KnEr5ox_RNFpYW5Srqj_4Uy4uYkhrOLKxo3TEt_nBFNhVsvTAxoY5ggDdTK_th945XzeZeXjRSX-j8clYJpaxAUmA-Z38qhbyXiq29wSZKswhloaHcIVIJDXe9Fhpfe1nM4IfJT5Lwy1tjYH4XIphd7UX_nprX4JEwlJUFENJE9E-Gq6y7deXQa7j3JXIg8YBtvcR0Mj0Fjxhj6Bdaq2hCE1Ot6KgZUxOzzRkiuJlkMoQgmg8T2MM6STfQnX-cEd328n6oYgYBxg34kLbi8NGSHiAKEtxcF8Fuj7gizMOCK91iaVQTf_7UsJIkW6KFGeGLz0MG8A71jj-kNjzSFApYGo6VCoQJqXzREY",

"token_type":"bearer",

"expires_in": 3600,

"refresh_token":"969c9b04-afe5-48a3-9353-62509f71e906",

"userName":"yourusername",

".issued":"Thu, 30 Apr 2015 02:21:08 GMT",

".expires":"Thu, 30 Apr 2015 02:22:08 GMT"

}

Authorize with username and refresh token:

Method: POST
Url: http://yourdomain/Token?username=yourusername&refresh_token=969c9b04-afe5-48a3-9353-62509f71e906&grant_type=refresh_token

Response:

{

"access_token":"SAPmj6kWat4KcwhASsTkkuQ0hxeIZaq4ztZBduHV_Mr-0SoxzQZ61ojdiXDtUIo_ptfbuzx5sA9_3-GpPWZhQ702qvAXdYSnMy_OUVVypfVkP-9mUsS7iR_4uFd67MFrSVEfQ4Er1Tm9AiFLC1j4kR7WjAmZgn6YuhU1Z3NNOFMu6UGEutJEWZte4mcnHinYKxskwVt_45DBGqEaLQ1OQoPhYwLTPGIhAcvsjiVLOxHCWp46bfYOyP5tVBoZxoaftuYyQfEgOkeU44TRWdGRZBh6vKWKdjWqa-qpy8fCNoJkwpSSjWYGEyhG4IkDyRCRGpCfMHP5rbP6dfaWAAchk7qQCmcia_vuEFoZWFWER6_LFe58avh_ZqfmJQhl7lVaM4z5SEKmKP4RPXgK32T4jQEqoisOGi66bcueLzRGmCsW2BlBnxPC1QloY_VQR8bEoCqK7_C0haMH7t30sJz_2Cz9CgnMnIjeyVhdcQsg_4U",

"token_type":"bearer",

"expires_in": 3600,

"refresh_token":"9a773700-0b48-411e-9138-1fc0e266d8a9",

"userName":"yourusername",

".issued":"Thu, 30 Apr 2015 02:21:08 GMT",

".expires":"Thu, 30 Apr 2015 02:22:08 GMT"

}

This is obviously very simplified and lacks typical uses with things like Client Ids and handling proper storage and error handling, but it will hopefully help you get started with your Authorization layer for any external applications through Web API.