AvantiPoint

MauiMicroMvvm for all of your small apps

2022-08-06T04:50:53Z

For many it may come as a surprise that I put this together or even that I published it. After all normally you would hear me talk about how you should use Prism. You might ask has something changed? The answer is no, nothing has changed. I do however understand that sometimes you might want something that is minimalistic and works with Shell. While I continue to believe Shell is the exact wrong answer for any Enterprise application, there are still a whole host of small apps out there for which Shell may be a good fit. So why write yet another MVVM Framework for it?

The truth is that I've looked at what's out there, and needless to say I feel they miss the mark in some very significant ways. Some of the things I see done wrong over and over in the Xamarin/.NET MAUI space are:

Not understanding a View in MVVM terms is not a Page. In fact if we're using MAUI speak it would be a VisualElement as a View could be a Page, or any MAUI View.
Either not understanding that in MVVM the View and the ViewModel should be decoupled. In fact the ViewModel itself should be completely testable without the View or View types.
Not having a solid grasp on Dependency Injection. While I could easily critique some of the MAUI API itself on this one, the MAUI API has made huge changes to make DI a more First Class experience, and this will only continue to be refined and improve over time. Sadly many of the community frameworks I have looked through still do not demonstrate a proper reliance on Dependency Injection and instead use anti-patterns that stem from and lead to bad architecture.
Thinking you need to reinvent the wheel. For those who have been around for a while you're probably familiar with the ICommand. There are a lot of decent, and a few pretty good implementations of the ICommand including Prism's DelegateCommand, ReactiveUI's ReactiveCommand, and MVVMLight (now the Microsoft.CommunityToolkit's) RelayCommand. Unless you're really trying to provide some special functionality around the ICommand, in my opinion it doesn't belong in the MVVM Framework particularly as MAUI already has a built in Command that works great in many cases.
Forcing you to adopt a specific type of base View or ViewModel class. This one should be pretty evident why it's a bad idea, what happens when I want to adopt some 3rd party library that gives me some special functionality... If I have to use the base type from the MVVM library I lose the ability to customize my app.

After looking at some of the options out there in the community I decided to put something together that people could use that solves these problems. I call it MauiMicroMvvm or MauiMicro for short. It's a micro Mvvm framework that is designed to provide only what you absolutely need and nothing that you don't. Naturally it does have a base ViewModel type that implements INotifyPropertyChanged, but it also has some lifecycle abstractions that are helpful for those that might want to use something like ReactiveUI. As you might guess, it also includes some abstractions around Navigation & showing native Dialogs that help you to keep your code testable.

Getting Started

When using MauiMicro you actually can start by deleting the Application. Unless you absolutely need to override methods in the Application you can actually have just the AppShell and your Pages to get off the ground and you can even provide the resource paths for your styles just like you would in XAML. The result is something like the following:

```cs
var builder = MauiApp.CreateBuilder();
builder.UseMauiMicroMvvm<AppShell>("Resources/Styles/Colors.xaml", "Resources/Styles/Styles.xaml")
    .ConfigureFonts(fonts =>
    {
        fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
        fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
    });
builder.Services.MapView<MainPage, MainPageViewModel>();
return builder.Build();
```

Any view that has been mapped using the MapView extension can now be auto-wired using the attached property like:

```xml
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:micro="http://schemas.mauimicromvvm.com/2022/dotnet/maui"
             micro:MauiMicro.Autowire="True">
```

With the View autowired, this will automatically resolve our ViewModel and set the BindingContext for us. Next it will attach a lifecycle helper Behavior that will help us get notified when the View has appeared or disappeared, and when the App goes to Sleep or Resumes. The result in our ViewModel is something like this:

```cs
public class MainPageViewModel : MauiMicroViewModel
{
    public MainPageViewModel(ViewModelContext context)
        : base(context)
    {
    }

    protected override void OnParametersSet()
    {
        // Provide any custom logic for initialization when Navigation Parameters are set
    }

    public override void OnFirstLoad()
    {
        // Do something the first time the View appears
    }

    public override void OnAppearing()
    {
        // Do something anytime the View Appears
    }

    public override void OnDisappearing()
    {
        // Do something anytime the View Disappears
    }

    public override void OnResume()
    {
        // Do something when the app resumes
    }

    public override void OnSleep()
    {
        // Do something when the app goes to sleep
    }
}
```

As a benefit of using the MauiMicroViewModel in addition to the MauiMicro specific interfaces, this also implements IQueryAttributable from .NET MAUI and it will automatically set the values of your properties for you. To make it even easier, when using the MauiMicroViewModel there is no need for a backing field as the MauiMicroViewModel makes use of an internal dictionary with a Get/Set that makes setting properties as easy as:

```cs
public string Message
{
    get => Get<string>();
    set => Set(value);
}
```

Next Steps

If you're looking for a lightweight framework to build Shell apps with, and you want to be sure that you're using a framework that keeps your code testable, and keeps you on the path towards Good Architectural Design, then you'll want to use MauiMicro. While there isn't currently a template for it, as you can see from this post there isn't much you need to do to convert a standard MAUI template.

Mobile Authentication with Essentials WebAuthenticator

2022-06-13T17:51:03Z

Authentication in mobile apps is often a critical step, but far more complicated than it really should be. .NET 6.0 Minimal APIs really helps us write less and produce exactly what we need. But the setup to get Microsoft, Google and yes just because we picked those 2 we are now forced (thanks a lot Apple) to use Sign in with Apple. Of course Apple being Apple couldn't be like everyone else so there are a few steps that you need to take in order to get setup. Even once we've got our Client Id & Client Secret for Microsoft & Google, plus our Service Id, Team Id, & Auth Key from Apple setting these up and having a token that you can use to now have Authenticated Endpoints, well it's a hot mess. We thought it was about time to make this easy, even if it's a bit opinionated. Introducing the AvantiPoint MobileAuth Library, now available on NuGet.org. With the MobileAuth Library we can easily stand up a new API with Microsoft, Google & Apple and expose a Login, Logout & User Profile endpoint to return the User Claims as a Dictionary all in only a few lines of code.

```cs
var builder = WebApplication.CreateBuilder(args);
builder.AddMobileAuth();

var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();

app.MapDefaultMobileAuthRoutes();
app.Run();
```

Why Use the MobileAuth Library

If you're looking at the MobileAuth Library the chances are that you want to stand up your own API for your Mobile App and you need to authenticate users, but you want to keep things as simple as possible so you can focus just on the code you need to write. Jumping through hoops to get authentication working so that you can use the WebAuthenticator from Xamarin.Essentials or Maui Essentials shouldn't be something you need to deal with. Of course there is no library that can eliminate the need for you to set up the Client Credentials with Microsoft, Google, Apple, etc, however we can try to make this easier. When using this library it requires minimal configuration on your part while ensuring that you can focus on writing API's that require an authenticated user.

How to Configure the MobileAuth Library

For brevity I'm going to leave out the details on specifically how to get the Client Id & Client Secret for Google & Microsoft, and how to get everything you need for Apple as there is already a lot of information on this in the Project Readme. Configuring the Library really is quite simple though.

```json
{
  "OAuth": {
    "CallbackScheme": "mobile-demo",
    "JwtKey": "DanSiegelMakesTheBestLibraries",
    "Apple": {
      "ServiceId": "com.company.app.sid",
      "KeyId": "{your key id}",
      "TeamId": "{your team id}"
    },
    "Google": {
      "ClientId": "{your google client id}",
      "ClientSecret": "{your google client secret}"
    },
    "Microsoft": {
      "ClientId": "{your microsoft client id}",
      "ClientSecret": "{your microsoft client secret}"
    }
  }
}
```

An important consideration here is that if you only want to start with a single provider you can easily do that. By Default any provider that is not properly configured will simply be ignored. The CallbackScheme must match what you set up in your mobile app for the WebAuthenticator. The JwtKey is technically optional as a default key will be provided for development purposes, however you really should provide some sort of key, and while the one shown may be a joke, it would work.

Next Steps

Check out the Demo API
Check out the MAUI Demo App - This provide a full DI example using a Refit client to get the User Credentials
Read up on how to set everything up for Sign in with Apple
Create your Google Client Id & Secret
Create your Microsoft Client Id & Secret
Consider adding an EntityFramework DbContext to manage tokens. This can help you to Validate technically valid tokens have not been invalidated by a user sign out.

Building Custom NuGet Feeds

2021-04-26T17:22:02Z

Most .NET Development shops have a tendency to build up a lot of code over the years. Naturally many of our clients that have been around for a while have some pretty horrible ways of managing code because how on earth do you make it easier share code from one developer to another or one team to another? Perhaps one of the most amusing things is that we already knew the answer because we use it everyday as .NET developers. The answer of course is NuGet. Now of course putting closed source, proprietary code up on NuGet.org would be a horrible idea, but the NuGet toolchain doesn't require us to be tightly coupled to NuGet.org.

Now the purpose of this blog is not to teach you fundamentals of packaging your libraries into packages. There are some undeniable facts however. For starters if you are packaging your libraries into NuGet packages then you are implementing some sort of Versioning strategy which can be particularly helpful for diagnosing bugs and regressions. What version was it when the bug was introduced? When you are packaging your libraries you don't stay on version 1.0.0.0 for 20 years (and yes we have seen many shops doing exactly this).

Ok so we know we need a feed, but we don't want to use GitHub packages, or Azure DevOps Artifacts... we want something that we can control. This is often a much more common scenario than it may seem at first glance. It's something that I use personally for Sponsor Connect, it's something that we use for Enterprise customers who are looking for access to private builds of Prism or some of our other tools. This concept is something that component vendors such as Telerik and Infragistics use with private feeds that authenticate their customers.

Frankly though we found it tiring that it was such a heavy lift to get your own NuGet feed. Yes there are some options out there. If you're working within your intranet you could even stand up a host running BaGet and provide an unauthenticated feed that will replace your need to use nuget.org entirely if you want. BaGet is a great project, but it is lacking for the scenarios we kept running into. The feed needs to be public, we need to authenticate the user, and further we need to know if they have publishing rights, can they access a specific package, and finally what are our users doing? After discussing this with some of our friends in the industry we've decided to openly share the base infrastructure of what we use for Sponsor Connect, and our Enterprise feeds. This is all open source and now available on NuGet.org to make it easy for you to include in your AspNetCore app and quickly standup a customized NuGet feed with your own Authentication logic.

Getting Started

AvantiPoint Packages is super simple to get started with, and can be used as either an authenticated or unauthenticated NuGet feed. What sets AvantiPoint Packages apart though is how easy it is to implement your own custom Authentication for Package Publishers and Package Consumers, as well as to hook into events such as Package/Symbols Uploaded/Downloaded, and even provide custom package specific logic to determine if someone should have access to download a specific package.

```cs
public class PackageAuthenticationService : IPackageAuthenticationService
{
    public async Task<NuGetAuthenticationResult> AuthenticateAsync(string apiKey, CancellationToken cancellationToken)
    {
        // Your logic goes here
        // You should validate that the user has Package Publishing privileges
    }

    public async Task<NuGetAuthenticationResult AuthenticateAsync(string username, string token, CancellationToken cancellationToken)
    {
        // Your logic goes here
    }
}
```

As you can see it's a very simple interface that you can implement to provide your own custom authentication logic. This is split into two methods. The first is meant for legacy NuGet ApiKey authentication. This is currently only supported for Package Publishing. The second is used for Basic user authentication and should be used for Package consumers. A good practice that you should employ when creating the NuGetAuthenticationResult is to create a ClaimsPrincipal. This will allow you easily access any claims you would like to set on the user later as we respond to events the authenticated user is doing.

For instance let's look at a scenario that our friends at Telerik or Infragistics might employ as they both maintain private NuGet feeds for their customers. Each company offers controls for Desktop, Web, & Mobile development with licenses that might grant you access to one or more of those control suites. Luckily this is a scenario where AvantiPoint Packages shines as it is really quite easy to grant users access to only download packages they actually should have access to. Building on our Authentication with a ClaimsPrincipal we constructed and passed back in the Authentication Result we might have something like the following.

```cs
public class NuGetFeedActionHandler : INuGetFeedActionHandler
{
    public NuGetFeedActionHandler(IHttpContextAccessor contextAccessor)
    {
        HttpContext = contextAccessor.HttpContext;
    }

    private HttpContext HttpContext { get; }
    private ClaimsPrincipal => HttpContext?.User;

    public async Task<bool> CanDownloadPacakge(string packageId, string version)
    {
        // Your validation logic here...
    }
}
```

While this is interesting really there are a few other events that may be of more use to us. Let's look next at Uploads. AvantiPoint Packages provides separate events for Packages and Symbols uploads. So let's see how we might handle these...

```cs
public class NuGetFeedActionHandler : INuGetFeedActionHandler
{
    public async Task OnPackageUpload(string packageId, string version)
    {
        // Email User confirmation of package upload
    }

    public async Task OnSymbolsUpload(string packageId, string version)
    {
        // Email User confirmation of symbols upload
    }
}
```

You really have fine grain control over how to handle any of these events, and the best part is that you can focus only on what you want to do here.

Setting up your NuGet Feed

To set up your own NuGet feed from scratch is actually pretty simple.

Create a new empty AspNetCore 5.0 WebApi project
Install the latest AvantiPoint.Packages.Hosting nuget
Install the latest AvantiPoint.Packages.Database.{provider} nuget
Optionally install the Aws or Azure package to use Cloud storage with AvantiPoint Packages
Update your Startup

```cs
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddNuGetPackageApi(options => {
            // Or use Azure or Aws Cloud storage
            options.AddFileStorage();

            // Or use another Database provider
            options.AddSqlServerDatabase("DefaultConnection");
        });
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseEndpoints(endpoints => {
            endpoints.MapNuGetApiRoutes();
        });
    }
}
```

Have issues or want to get more information? Be sure to check out the GitHub repository.

Regions in Prism for Xamarin.Forms

2020-10-20T16:18:48-07:00

Prism has long been considered the premiere choice of frameworks for developing Xamarin.Forms applications with about 1.5 million downloads of just the Prism.Forms NuGet package alone! Why has Prism been the gold standard for app development? For starters Prism originated around 2008 from the Microsoft Patterns and Practices team for WPF development. Prism was never about basic MVVM helpers like providing a base implementation of INotifyPropertyChanged and ICommand, with perhaps a ViewModelLocator thrown in for good measure. Sure Prism has all of these things but Prism has always been about giving you the tools you need to actually develop your app which includes an understanding of the platform you're working with to give you the ability to Navigate. This is a key feature that makes Prism an actual MVVM Framework for building Highly Modular, Highly Testable XAML applications rather than just a set of MVVM Helpers like MvvmLight or the new Microsoft.Toolkit.Mvvm.

Recently Prism celebrated a huge leap forward for its Xamarin.Forms developers with the introduction of support for Region Navigation. Regions has long been the preferred method of application development for WPF development and was adopted as the preferred method of app development for Uno Platform apps.

What is a Region

Before we can really start to understand what exactly a Region is, let's define a few terms:

Page - This is a Xamarin.Forms concept which generally encompasses the entire device screen for platforms like iOS/Android or a traditional application window on platforms like UWP/macOS
View (Xamarin.Forms) - This is a Visual Element from Xamarin.Forms that is generally added as the content of a Xamarin.Forms ContentPage. Developers coming from other backgrounds may often think of these as Controls and Layouts. Examples include the Label, Button, StackLayout, and Grid.
Composite Control - This is generally a Xamarin.Forms Layout such as a StackLayout, Grid, ContentView, or other layout which contains various children. This may be very simple or as complex as anything else you may typically do on the Page.
View (MVVM) - This is a Visual Element presented by the Application that is bound to a ViewModel. The View could represent the entire visible area to the User or a subsection of the total visible area within the device screen or application window.

For the purposes of this article, and to avoid confusion note that when we use the term View we are referring to the MVVM context of what a View is. When we say control we are referring to the Xamarin.Forms context of what a View is, and when we say Page we are referring again to the Xamarin.Forms context of what a Page is.

So what is a Region? A Region within Prism.Forms is generally a Composite Control. If you're coming from the context of traditional Prism.Forms Page based app design just think whatever you had on the Page but a small section that may need to change or be reused across various Pages.

How do I use Regions in Prism for Xamarin.Forms

While we don't want to get into the specifics for how to add support for additional controls, it is important to understand that support for controls used in your Xamarin apps is provided by mapping a RegionAdapter to a control type that you need to support. Out of the box Prism includes support for:

ContentView	Frame	FlexLayout
CarouselView	ScrollView	StackLayout
CollectionView (experimental)

These out of the box adapters do not require any mapping. So what do you need to do? For starters let's create a View that we'll call RegionViewA

```xml
<StackLayout xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="HelloRegions.Views.RegionViewA">
  <Label Text="Region View A" />
  <Label Text="{Binding Message}" />
</StackLayout>
```

Now that we have a View that we will display in our Region lets create a Page to host our Region, we will call the Page ViewA.

```xml
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:prism="http://prismlibrary.com"
             x:Class="HelloRegions.Views.ViewA">
  <ContentView prism:RegionManager.RegionName="ContentRegion" />
</ContentPage>
```

Now that we have our two Views lets head over to our App and register these for Navigation. We will also need to make sure that our App is ready to use Regions and navigate to our initial Page so that the Application.MainPage is set to our Page (ViewA).

```cs
public partial class App : PrismApplication
{
    protected override void OnInitialized()
    {
        InitializeComponent();
        NavigationService.NavigateAsync("ViewA?message=Hello%20Region%20From%20PrismApplication!");
    }

    protected override void RegisterTypes()
    {
        containerRegistry.RegisterRegionServices();
        containerRegistry.RegisterForNavigation<ViewA, ViewAViewModel>();
        containerRegistry.RegisterForRegionNavigation<RegionViewA, RegionViewAViewModel>();
    }
}
```

Now we could run our app but we really wouldn't see anything as we haven't done anything to load RegionViewA into our ContentRegion in ViewA. So next we'll need to look at how we can do that in our ViewAViewModel.

```cs
public class ViewAViewModel : BindableBase, IInitialize
{
    private IRegionManager _regionManager { get; }

    public ViewAViewModel(IRegionManager regionManager)
    {
        _regionManager = regionManager;
    }

    public void Initialize(INavigationParameters parameters)
    {
        _regionManager.RequestNavigate("ContentRegion", "RegionViewA", RegionNavigationCallback);
    }

    private void RegionNavigationCallback(IRegionNavigationResult result)
    {
        // Handle any errors or anything else you need to here...
    }
}
```

Now you may have noticed that we had a binding for a Message property in our RegionViewA, and we passed a message in our querystring when we navigated to ViewA but so far we haven't done anything with that. So let's look at how we can pass parameters to our Region now:

```cs
public void Initialize(INavigationParameters parameters)
{
    _regionManager.RequestNavigate("ContentRegion", "RegionViewA", RegionNavigationCallback, parameters);
}
```

It really couldn't be easier to use. Prism 8.0 and Regions for Prism.Forms are out of preview. Need help with your Prism application? Be sure to contact us today about our Enterprise Support contracts or for other help getting your projects ready to use Regions.

Welcome to the NEW AvantiPoint!

2020-07-16T00:46:48Z

Welcome to a brand new AvantiPoint.com! Truth be told this has been a long time coming. A lot has changed for us since we first launched in 2014 and it was time for an update. After all our website was running on ASP.NET Core 1.0 preview 2...

We've been hard at work this year and are kicking things off with a brand new website to better help our amazing clients. This long overdue refresh of our website is finally giving us a brand new blog to keep you up to date with what you need to know in the Mobile Development space, and we encourage you to sign up below for updates when we post. In addition to the new website, we're proud to announce our brand new Customer Portal. This portal is a great place to access private resources and better interact with us.

Customer Portal

The Customer Portal has several features that will make it much easier on our clients going forward. We know several of our clients have loved using the AvantiPoint Mobile Toolkit. While this is Open Source we haven't really been posting it on NuGet.org. The Packages for the Mobile Toolkit along with some new special tooling that we'll be releasing for our customers only will be available through our private NuGet feed.

As you may have noticed from the picture of the portal, we've also started providing a knowledge base of F.A.Q.'s for our customers to access any time. Another item that has frankly been on our backlog for quite a while is an official support ticketing system. While we love emailing our customers the truth is that for both you and us, it can be hard to go back and find the answer to a question you know was already asked. We're looking forward to the great conversations and simplifications that this new support portal will be providing, and we think you will too!

Developer Services

We know from talking to a lot of you that you may not have realized that a large source of our business has been, and we expect will continue to be developer centric. Of course we love building apps for our clients, but we're also here for those of you who want to build an app yourself, but just require some help.

In fact if you're a developer with one of the thousands of companies that relies on the Prism Library, we offer the only official Prism code level developer support plans. Whether you're ready to get started today or you have a few questions be sure to reach out to us today!

AvantiPoint

MauiMicroMvvm for all of your small apps

Getting Started

Next Steps

Mobile Authentication with Essentials WebAuthenticator

Why Use the MobileAuth Library

How to Configure the MobileAuth Library

Next Steps﻿﻿

Building Custom NuGet Feeds

Getting Started

Setting up your NuGet Feed

Regions in Prism for Xamarin.Forms

What is a Region

How do I use Regions in Prism for Xamarin.Forms

Welcome to the NEW AvantiPoint!

Customer Portal

Developer Services

Next Steps