DEV Community: Matthew Soucoup

Power Apps and the .NET Developer

Matthew Soucoup — Fri, 28 Jan 2022 23:56:21 +0000

Power Apps is a low-code solution to building applications. A lot of the work needed to make the application work is done for you behind the scenes. You still have to write code to make the app work, but that's not the main focus when creating the app.

An app built with .NET is high-code. I don't mean that .NET isn't elegant or libraries don't exist to help. Rather when you write a .NET app your primary focus is on writing code to make the app work.

Both are incredibly powerful ways to build applications.

And when you mix Power Apps with .NET - your productivity can go through the roof.

So let's talk about why the .NET developer should know Power Apps.

Forms Over Data Like You've Never Seen Before

I'm just going to state this as fact, and it's based off of 20 some years of working in and with large enterprises - most enterprise development is creating some type of forms over data application.

In other words, an app that searches for data, views data, and modifies data. Yes, it may do other things, but the form over the data is the gist of the application.

Most enterprise development is creating some type of forms over data application.

Power Apps excels at creating such apps. It will automatically scaffold out an entire forms over data application for you - you just need to point it at your data source, like Azure SQL... or an Excel sheet (because you know, why not).

This then frees you up to concentrate on the core of the application. The portion of it that's not just the forms over data. But ... even then a lot of the time you're not starting from scratch. There are tons of components that give you a headstart on other development tasks. Like media or AI.

Right now you might be thinking ... so what exactly does this have to do with .NET development? The very simple answer ... it frees up your time.

Use Power Apps and everything that it gives you to quickly create robust applications. But a Power App isn't appropriate in every single situation. I mean, you're not writing any web APIs in Power Apps. They're not meant for customer facing apps.

But if you can speed up your development for internal frontend apps and that leaves you more time to concentrate on apps that need to be written in .NET - that's a win-win for everybody.

Connectors - and Custom Connectors

Part of what makes creating Power Apps such an attractive proposition are Connectors.

A Connector supplies external functionality to Power Apps. In other words, a Connector connects your Power App to Azure Blob Storage for example. There's a Docusign Connector. One for LIFX (control those lights!), Salesforce ... you get the idea.

It connects your app to external data.

External functionality made so it's easily consumable in a Power App.

And here's where things get interesting. You can create your own Custom Connector.

If you have an OpenAPI described web API, you can create a Custom Connector for it, and then consume it in Power Apps.

Starting with Visual Studio 2019 and continuing with 2022 - or using the .NET CLI - it's as easy as checking a box to generate an OpenAPI definition for you web API.

Now you're able to take your high-code .NET web API application - and maybe it's deployed in Azure App Service across several regions and managed in Azure API Management - and use it within your Power Apps App.

Thanks to a Custom Connector and a .NET web API, the Power Apps App is becoming more than just a low-code app.

You're mixing the best of both high-code and low-code worlds.

Fusion Development

And that brings us to the concept of Fusion Development.

Fusion Development is still new, but it's underlying concept is old: use the best tools for the right job.

In this sense, use Power Apps where it excels, creating frontends quickly that support forms over data. Use .NET where it excels, such as responding to web requests to get data and perform business logic lightning fast.

Use the best tools for the right job.

Mix and match where it makes sense. Once you get a feel for what Power Apps is capable of, you'll know when to use it. Just like you know when a switch makes more sense than an if.

Together you'll find yourself and your team building better apps faster.

Learn More

The low-code revolution, if you will, and its intersection with professional development is incredibly interesting to me.

If you want to learn more, I've created a couple of Pluralsight courses that explore Power Apps (and help prep you for the PL-200 certification exam). These links will give you a free trial:

I've also helped write a Microsoft Learn Path on Fusion Development for the professional developer.

Transform your business applications with Fusion Development

Check them out!

Excel is Amazing! Name Cells Like a Variable!

Matthew Soucoup — Mon, 10 Jan 2022 21:50:34 +0000

Excel is so much more than a place to track who isn't ... I mean is ... coming to a party that I throw.

It pretty much is a full-blown programming language upon itself. The more I mess around with it, the more I'm amazed with what it can do.

Here's something I just learned that kinda blew my mind. You can give individual (or a range) of cells a name. Like naming a variable. And then refer to that name in various formulas.

Think about how useful that can be - when you need to have a formula that calculates the sum of the cells that hold the values for the cost of eggs, milk, and bread - you could have:

That'll do the trick - but you gotta hope that A2, B2, and C2 refer to the correct cells. I mean by look at it who knows what they refer to.

But ... but ... what if you could name those cells, so in the formula you would know? It would be super apparent and there would never be a question again.

You can! Because Excel is amazing. And here's how.

Highlight the cell you want to name
Go to the formulas menu / tab / ribbon (or whatever the proper nomenclature is).
Click on Define Name
A modal window will show & it'll guess what you want to name the cell. The cell (or range of cells) that should be named. And will show you other cells that have been named. Go ahead and set the values (most likely just accepting the defaults).

That's it!

Then when you go back to your formula & start typing - Excel will even prompt you with the name of the cell - like Intellisense would.

(And if you're more of a click-to-select-a-cell person than a typer when doing formulas - Excel still will use the name!)

And the formula would look something like this:

And what's nice is that you can refer to those named cells on any sheet - not just the one they were defined on - super easy. No more trying to remember what the proper syntax is for cross-sheet cell reference.

What about cell ranges?

Pretty much same as before. Select the range you want to name - give it a name.

And then when you reference it in a formula - reference it as before.

Maybe everybody already knows about this - but when I found out that I could clean up my formulas and make them easier to understand ... so amazing!

Xamarin 101: Part 7 - Wrapping Up

Matthew Soucoup — Fri, 11 Oct 2019 14:32:30 +0000

Xamarin 101: Part 7 - Summary

You made it! You now have a fundamental understanding of Xamarin, Xamarin.Forms, how XAML makes a UI, and a bit about MVVM and navigation between pages.

You should now be ready to take the next steps into your mobile app development journey!

Learn More

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Xamarin 101: Part 6 - Xamarin.Forms Navigation with XAML

Matthew Soucoup — Thu, 10 Oct 2019 17:18:24 +0000

Xamarin 101: Part 6 - Xamarin.Forms Navigation with XAML

You've learned how to build a user interface with XAML. Add some smarts to it with the MVVM pattern. Now it's time to add some more pages to the app and navigate around in it with this short video!

Learn More!

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Xamarin 101: Part 5 - Xamarin.Forms MVVM with XAML

Matthew Soucoup — Wed, 09 Oct 2019 16:17:10 +0000

Xamarin 101: Part 5 - Xamarin.Forms MVVM with XAML

Model-View-ViewModel (or MVVM) is the heart and soul of Xamarin.Forms. It allows you to add a ton of application logic to your app, but without dirtying up your views with that code. Separation of concerns FTW!

And XAML is tailor made to implement MVVM - with specific attributes allowing for binding of properties and commanding.

What does that all mean? Check out this short video to find out more!

Learn More!

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Xamarin 101: Part 4 - Building a Xamarin.Forms UI with XAML

Matthew Soucoup — Mon, 07 Oct 2019 17:20:32 +0000

Xamarin 101: Part 4 - Building a Xamarin.Forms UI with XAML

XAML is a declarative markup language used to describe user interfaces. It allows you to build sophisticated UIs that are easy to understand at a quick glance. And it's straightforward to get started with too.

In this short video, learn how to build your first Xamarin application for both iOS and Android using XAML for the user interface.

Learn More!

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Xamarin 101: Part 3 - Solution Architecture

Matthew Soucoup — Fri, 04 Oct 2019 14:56:28 +0000

Solution Architecture

There are always a hundred ways to do something. And cross-platform mobile development with Xamarin is no different.

In this short video, we explain the way that Xamarin projects are structured out of the box (or what happens after File->New), and how that best enables you to create applications maximized for code reuse.

Learn More!

Walk-thru of the Xamarin.Forms new project setup

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Xamarin 101: Part 2 - Installing Xamarin

Matthew Soucoup — Thu, 03 Oct 2019 14:42:19 +0000

Installation

You very well can't start developing mobile apps without Xamarin without knowing how to install the platform and toolset!

This short video walks you through the process, step-by-step on Windows.

And this video walks you through the macOS installation process!

Get that Xamarin installed! 😀📱

More Info

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Xamarin 101: Part 1 - Introduction to Xamarin

Matthew Soucoup — Wed, 02 Oct 2019 21:51:46 +0000

The Introduction to Xamarin

Cross-platform mobile apps. C#. iOS, Android. .NET. Shared Code. Xamarin.Forms.

All of the terminology can be a little confusing. This short video below though takes the confusion out of it and explains what exactly Xamarin is, how it works, and how it can make you - a .NET developer - productive in mobile development right away.

Learn More!

There's lots of great documentation - but here's where to start to make the most of your time!

Happy mobile coding! And as always, if you have any questions - please ping me on Twitter at @codemillmatt.

Build Amazing Cloud Connected Apps with Xamarin, Azure, and App Center

Matthew Soucoup — Tue, 01 Oct 2019 23:38:35 +0000

Before we get going, in order to follow along with this article, you should download this repository:

codemillmatt / dotnet-conf-2019

Build Amazing Apps with Xamarin, Azure, and App Center

. Got it downloaded? Great - let's go!

Build Amazing Cloud Connected Apps with Xamarin, Azure, and App Center

Xamarin + Azure + App Center = One Amazing Cloud Connected App!

Each of these technologies by themselves are powerful, but when you combine them, you're able to build a cloud connected cross platform app that is able to harness the power of Azure in a matter of minutes. And it's even able to create user accounts, a very tricky feature that's necessary, but difficult to understand.

Now - I said you can create it in minutes ... that's not exactly true. You can't create anything in minutes. It takes work. I won't kid you.

But what does take minutes is to get a fundamental understanding of how these three pieces of technology work on a fundamental level and interact. And then once you have that - you can be off and running to create apps of your own!

Like Videos?

Do you want to watch a recording of what this article is all about?

Who wouldn't?

It just so happens I did a live session for .NET Conf 2019 that demonstrates this app and gives a high level overview of all the concepts involved - in about 25 minutes!

So check it out - and be sure to come back here for a more in-depth discussion.

What Are We Going to Build?

In the video above, throughout this article, and with all the code in this repo you just downloaded; we're going to build a weather application. (Based on the Pretty Weather sample.

I know, I know - another weather app.

But this one goes further than most. It actually retrieves the weather via a custom API! It allows users to sign-in to an Active Directory B2C instance. It stores weather preferences into a Azure Cosmos DB instance!

It's a fully enabled cloud app. Showing off how you can integrate a ton of cloud services into your Xamarin application.

How Did We Build It?

An iOS and Android app - all built with Xamarin.Forms. Shared application logic. Shared user interface. Shared code all over the place!
Azure Functions wraps up a 3rd party weather service into a custom API for the mobile app to call.
The mobile app uses the Mobile Backend as a Service (MBaaS) functionality of App Center to build out a Azure AD B2C instance so users can log in. Authentication and authorization is... confusing at best and App Center's MBaaS makes it easy.
The mobile app makes uses Azure Cosmos DB - so users can persist the weather - again with App Center's MBaaS making authentication/authorization to Cosmos seamless.

Xamarin! Azure Functions! App Center! Amazing!

Let's take a look at each of the components used to build this app in turn.

Xamarin

Xamarin's claim to fame is that it allows you to build 100% completely native iOS and Android applications using C# and .NET. But it does more! You can also build macOS, UWP, tvOS, WatchOS, even Tizen applications using it too!

You can find out how Xamarin works - it's techniques for code sharing here. And you can find out how Xamarin.Forms extends that code sharing to the user interface layer here.

In this application - we use Xamarin.Forms to build out the user interface and the application logic layer. In fact, the only code that runs on iOS or Android alone is the code which bootstraps Xamarin.Forms. It's boilerplate code added with the File->New process when creating a project. For our purposes - this application is 100% shared code!

The app uses the following features of Xamarin.Forms:

The app is built of 4 distinct pages:

AppShell.xaml -> the overall container that provides Shell functionality
MainPage.xaml -> displays the current weather conditions for the selected city & allows the user to log in via App Center
SavedCitiesPage.xaml -> displays the saved cities from App Center
AddCitySearchPage.xaml -> allows the user to select a new city to display weather conditions from and saves it to App Center

MVVM Pattern

MVVM stands for Model-View-ViewModel. The pattern is a lot like MVC (just more V's and more M's 🤣). Its purpose in life is to decouple any application logic from the application's user interface. You put all logic into the ViewModel. The ViewModel returns information - in a Model class - to be displayed in a View.

And you can use what's known as data binding to have the view updated automatically whenever the data it's bound to changes (and vice versa).

This app uses the MVVM pattern for every page. For the MainPage.xaml which shows the current weather conditions - it has an associated view model of WeatherViewModel. And that's associated in the MainPage.xaml with the following syntax:

<ContentPage.BindingContext>
    <viewmodel:WeatherViewModel Temp="61" />
</ContentPage.BindingContext>

Then the binding to each user control is done with a syntax that looks like this:

<Label Text="{Binding Temp}"/>

That tells Xamarin.Forms to look into the ViewModel for a property called Temp.

Then in order for the Labels Text property to change anytime the ViewModel's Temp property changes - the ViewModel must implement the INotifyPropertyChanged interface. And the Temp property's implementation will look like this:

int temp;
public int Temp {
    get => temp;
    set 
    {
        temp = value;
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Temp)));
    }
}

Learn more about data binding, MVVM, and building XAML-based Xamarin.Forms apps in this 101 video series!

Shell

So let's talk about Xamarin.Forms Shell for a bit. Shell gives applications an opinionated way to do a user interface. Tabs. Flyout menus. Navigation. This app only uses a subset of the navigation functionality.

You can see the navigation happening in the WeatherViewModel class's ExecuteSavedCitiesCommand.

async Task ExecuteShowSavedCitiesCommand()
{
    try
    {
        // some App Center stuff we'll talk about later

        var citiesPage = new SavedCitiesPage();

        await Shell.Current.Navigation.PushModalAsync(citiesPage);
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine(ex);
    }
}

Shell is cool in that it allows the app to navigate to new pages from view models. First we new up a Page. Then navigate to it - asynchronously of course. await Shell.Current.Navigation.PushModalAsync(citiesPage);

Shell provides means to both push onto the navigation stack and also push onto a modal stack.

Messaging Center

Messaging Center is a great way to send... well messages.. between any class in a Xamarin.Forms solution - even the Android or iOS projects!

In the weather app, I'm using Messaging Center to indicate when a city has been selected from the search list. This will allow the SavedCitiesViewModel to add the newly selected city to its display list and also save it to Cosmos.

One thing to note - when sending messages using Messaging Center - use custom classes as the origin of the message. Not the view model or page which you sent them from. This makes the message more reusable. See my article here for more info on it.

And here's a quick code sample on how it's done.

var message = new SearchCitySelectedMessage { SelectedCity = SelectedCity };

MessagingCenter.Send(message, SearchCitySelectedMessage.Message);

The SearchCitySelectedMessage is the custom class. And MessagingCenter is using it as the origin of the message.

Value Converters

The final cool thing that's happening in the application is the use of value converters. You use these cool cats during data binding, but when you don't want the control to display the value of the property you're binding to. Rather you want the control to display a different value - but that value is based on the property the view model.

Take a peek at an example.

<FontImageSource Glyph="{Binding Icon, Converter={converters:CurrentConditionsIconConverter}}"/>

Here the Glyph property of FontImageSource is bound to the view model's Icon property. But I really want something else to be displayed. So it's attached to a value converter that looks something like this.

public class CurrentConditionsIconConverter : IMarkupExtension, IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        // these hex codes coorespond to font aweosome solid codes
        if (value is string condition)
        {
            if (condition == "clear-day")
                return ((char)0xf185).ToString();

            if (condition == "clear-night")
                return ((char)0xf186).ToString();

        // And there's more
        }
    }
}

That's all the cool Xamarin.Forms stuff that's going into the app - now let's take a peek at what's happening in Azure Functions!

Azure Functions

Azure Functions is Microsoft's serverless offering. And you can think of serverless as the next evolution to the "as-a-Service". This is Functions-as-a-Service. And you only have to worry about writing code. No operating system. No hardware. You don't even have to think about scaling. You just have to think about what's core to your application.

And our application is using Functions as something of a backing Web API. Functions can do more - and you can read about bindings and triggers here.

We're using HTTP triggers. Meaning anytime an HTTP request comes in - our function reacts to it. (And only while it's running do we get charged for it too!)

You can find the code for our Function in the PrettyWeather.Functions solution.

There's one Function involved and it calls out to the Dark Sky Weather API.

You may be wondering why don't we just put the call to Dark Sky right into the Xamarin app? There's a couple of reasons.

Dark Sky relies on an API key. We don't want that API key on a user device. So it's better to have it stored in the cloud.
Having the weather API in a Function allows us to shape the response to make it easier for our app to deal with. And it makes it easier for other apps we create (even web apps) to consume it.
And having all the logic for calling the 3rd party weather service in a single place makes it easier to refactor should we need to do that.

So ... if you want to reproduce this sample as is - sign up for a Dark Sky account - it's free. And then create a local.settings.json file that looks like the following:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "DarkSkyKey": "**** YOUR KEY IS GOING TO GO HERE ****",
    "DarkSkyUrl": "https://api.darksky.net/forecast",
    "DarkSkyParams": "exclude=minutely,hourly,alerts,flags,daily"
  }
}

Then you'll be good to go.

Invoking a Function From a Xamarin App

There is nothing special calling an Azure Function from a Xamarin application. It's the same as calling any web api.

public async Task<WeatherInfo> GetWeatherInfo(double latitude, double longitude)
{
    try
    {
        var infoJson = await httpClient.GetStringAsync($"{functionsUrl}?lat={latitude}&long={longitude}");

        var weatherInfo = JsonConvert.DeserializeObject<WeatherInfo>(infoJson);

        return weatherInfo;
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine(ex);
    }

    return null;
}

That httpClient variable is of the type System.Net.HttpClient - new'd up with the default constructor. That's it. Done and done.

App Center

Now App Center. App Center is known for its DevOps functionality. You can hook it up to a source control repository and have it build on every push. Have it distribute to testers or the store. Have it track crashes and analytics.

But recently App Center has been developing a Mobile Backend as a Service functionality that makes it easier to interact with Azure AD B2C for letting users create accounts and sign-in to your apps. They have also been working with Azure Cosmos DB to make it better to work with data - both online and off - seamlessly. Including having it work with with Identity so you can store personal data without having to worry about handling the tokens from the AD B2C instance yourself!

The MBaaS portion of App Center does have a bit of ceremony to setup - so follow the steps here for Identity. And here for Data. But once you're up and running interacting with them from a Xamarin app couldn't be easier. Seriously.

To sign somebody in:

var userInfo = await Auth.SignInAsync();

Yeah, that's it.

Then to save some data to a user's private stash in Cosmos DB

await Data.CreateAsync<CityInfo>($"{city.CityName.Replace(" ",string.Empty)}-{city.State}", city,
        DefaultPartitions.UserDocuments);

That first parameter specifies the ID to be used in Cosmos. The second one the object to store. Then the last one where you want to store it. If you use DefaultPartitions.UserDocuments, the App Center SDK will use the signed-in user from the Auth portion and do everything. You don't have to worry about handling tokens yourself.

Similarly to read documents for a particular user:

public async Task<IEnumerable<CityInfo>> GetSavedCities()
{
    var allSavedCities = new List<CityInfo>();

    var savedCitiesFromCosmos = await Data.ListAsync<CityInfo>(DefaultPartitions.UserDocuments);

    allSavedCities.AddRange(savedCitiesFromCosmos.CurrentPage.Items.Select(ci => ci.DeserializedValue));

    while (savedCitiesFromCosmos.HasNextPage)
    {
        await savedCitiesFromCosmos.GetNextPageAsync();

        allSavedCities.AddRange(savedCitiesFromCosmos.CurrentPage.Items.Select(ci => ci.DeserializedValue));
    }

    return allSavedCities;
}

There's a bit more there - but that's because App Center returns data in pages - so it doesn't return everything all at once. But the key here is Data.ListAsync<CityInfo>(DefaultPartitions.UserDocuments); That's going to use the signed in user - and only return they're documents that match the CityInfo data type.

The App Center SDKs are awesome. Check them out.

Summing It Up

So while you won't be able to build a cloud connected app in minutes - there are a ton of tools at your disposal to let you build one in a straight forward manner.

Xamarin - for creating iOS and Android (and other) apps while sharing a ton of code across the platforms
Azure Functions - for creating a Web API that lets you concentrate on your code and nothing else
App Center - a new Mobile Backend as a Service that lets you connect to an AD B2C and Cosmos DB instance and handles all the hard work for you!

If you have any questions - reach out anytime at @codemillmatt - I'd love to hear from you!

5 Azure Offerings I ❤️ for Xamarin Development

Matthew Soucoup — Tue, 02 Apr 2019 17:03:27 +0000

I'll admit it... I ❤️ Xamarin and I ❤️ Azure. So I thought what better way to spread some ❤️for Xamarin, than to talk about five Azure offerings that I ❤️ when doing Xamarin development!

And give all of these offerings a spin by signing up for a free Azure account!

Azure AD B2C

It won't come as a surprise to anybody that Azure AD B2C is on my list of Azure offerings that I ❤️. After all, I've written something like a 13 part article series on it, instructed a Xamarin University guest lecture, not to mention given several conference talks too.

But why do I like it so much?

First and foremost, when combined with MSAL.NET, it allows for a pretty simple way to allow users to create accounts and sign in to your app. And not only that, the users can sign up using existing social accounts they may already have, like Twitter or Facebook. So they don't have to create and remember yet another account.

Then once you have accounts created, an entire world of authentication and authorization opens up to you.

Plus, it integrates seamlessly with other Azure services. You want to lock down your Azure Functions? It's straight-forward to do so with Azure AD B2C and the Functions portal.

Azure Functions

Speaking of Azure Functions - that's number two on my list. Functions are not something that get consumed by an SDK hosted within your Xamarin application. Rather they will generally get invoked by an HTTP call.

But what make these amazing is that they allow you to create a backend for your app without having to spin up an entire ASP.NET WebAPI or Node.js backend which will sit idle most of the time waiting for a request to come in. With Azure Functions, you create a ... well, function ... and that singular function is the endpoint. You don't have to worry about the rest of the overhead that goes with hosting a web-based API. (This is where the term serverless comes in.)

But what sets Functions apart is that they have bindings to other Azure services.

Need to have a particular query run and the dataset populated from Azure Cosmos DB - and have that sent as an incoming parameter? ✅
Need to write to an Azure BLOB Storage? ✅
Even write to SignalR clients? ✅ ✅ and ✅!

Check out all the bindings here.

With all of this power attached to other Azure services - Functions are an amazing way to power your mobile backend!

Azure Key Vault

Now this next one is a little tricky.

First let me lay out a scenario...

Let's say that you've been given the chance by your boss to develop the app that you've been talking about for the last 2 years.

You have 2 months to put it together. So you move as fast as possible and hardcode database connection strings, Twitter keys, and anything else that needs a secret right into a config file (but at least you didn't push it to GitHub!)

Hey, you got to get it done!

You do a tremendous job! So good in fact, that you get 3 more developers! But an issue quickly starts to arise - how do you distribute your app's secrets? And what happens when your teams grows even more? And even worse, what happens when Steve - and it's always Steve - is at a coffee shop and somebody snaps a photo of his laptop screen with your database connection string exposed?

This is where Azure Key Vault comes in handy! It's a vault - that stores your keys - in Azure. By having a single point of where all of your secrets can be, it allows you to quickly cycle, or version, keys should a breach occur.

All you need to do is tell Key Vault - hey, give me this key ... and it'll send the secret value down to you!

But here's the tricky part. You really shouldn't ever have a secret on-device, even in a transient state. What you should do is request an access token, pass that token to a web service, and once that service verifies that you have access it grabs the key and does what it need to do.

The web service, by virtue of being hosted in Azure, will have access to Key Vault (after some config is done).

So Key Vault - it's a great place to store your app's secrets. And there is a .NET SDK should you choose to access them on-device. But you should really consider authenticating, and passing a token to a web service (which uses the Key Vault SDK), and have that service grab whatever info it can based on the secret key.

Still, use Key Vault whenever you can to store your secrets!

Azure Custom Vision API

You've probably seen the cool demos from the Cognitive Services Computer Vision API - where it tells you that it's looking at an "orange on a table".

Yeah - that's cool and all. But there's something even better. There's an Azure service out there that let's you train up your own vision model... which is Machine Learning talk for telling the computer exactly what types of things you want it to recognize.

And that service is the Azure Custom Vision API.

Let's say you want to identify individual varieties of plants by taking a photo of them.

If you used the Cognitive Services Computer Vision API - all it would tell you is that it sees a plant.

However, the Custom Vision API would tell you it found a Fiddlehead Fern!

Now, all of this in-depth info does not come without its share of work. In order for it to distinguish the species of plant, you first have to load in many different photos of that plant. Then label each photo - or tell the machine what it is. After that, you train it. So it starts to learn how to identify which plants are which.

It might take more initial work, but what you get in the long run is a more specific and tailored vision model that Cognitive Services and provide you out of the box.

Oh! And you DO NOT have to call a web api to use these! You can download a TensorFlow, CoreML, or even an Onnx (for Windows) model on device and run them that way! And that means fast, fast, fast! Always good for mobile development.

App Center

Here I'm not going to talk about the existing App Center functionality of Build, Test, Deploy, Crash-a-ltyics, and Push.

Rather, I'm going to talk about the future of App Center. And this is a future that's going to make a lot of Xamarin developers very, very happy!

You see, the App Center team has released a roadmap for the first 6 months of their 2019 development.

And one of the items on that roadmap is: creating next generation Azure mobile services.

App Center is going to create the next generation of Azure mobile services!

And here's the best thing - they're going to do all of their planning and design in the open! You can follow along here.

More to the point, start leaving your comments so you can influence the design on upcoming changes to Identity, a Cosmos DB storage backend, and more!

This is being designed in the open and the team is 100% open to community collaboration. Please, let them know what you think!

Summing It Up!

There you have it - five great Azure services that I ❤️ and make life easier for Xamarin developers.

Azure AD B2C for all of your user's account needs. Azure Functions for a full on backend without you having to do all the work. Azure Key Vault - keep those secrets safe! Azure Custom Vision API - detect highly specific vision models.

And of course - the all new App Center - go ahead and help determine the future of mobile development in Azure!

So give these services a whirl with that free Azure account!

Using Azure Key Vault with Your Mobile App the Right Way

Matthew Soucoup — Mon, 18 Mar 2019 17:32:45 +0000

Hey! Follow along with all the action here! First, if you don't have an Azure subscription, get a free one here! And then next, you can deploy all the resources I'm going to talk about as easy as clicking on the button below button.

Don't hardcode connection strings - or any secrets - in your apps! And for all that's holy - encrypt those secrets!

Like most other advice that I get (floss... exercise... shower more than once per week...) that seemingly easy to follow best practice of security guidance doesn't get followed very often.

Why? Because it's an extra step in the development cycle. Why go through the hassle of encrypting, storing, having to come up with a means to distribute my app's secrets to other devs on my team... when I could just have them sitting around somewhere in plain text? What are the odds that somebody will decompile my app to get at them anyway?

Just like why would I exercise when I could sit around, eat Pringles, and watch re-runs of SpongeBob SquarePants? What are the odds that I'm going to die of a heart attack today?

Well ... eventually luck runs out. Someday, something bad will happen to my app's secrets even if the app doesn't get cracked (like I commit the secrets file to GitHub). Just like someday I'll regret skipping all of those workouts to watch marathons of the Golden Girls. (Lol ... like that would ever be a regret.)

But there has to be a way ... there has to be a way to keep the app's secrets safe, all the while following best practices, and not making our lives too difficult ... right? Right?

Enter Azure Key Vault

Azure Key Vault provides a centralized place to store not only your application's secrets, but also can be used for key and certificate management too.

Key Vault puts all secrets in one spot ... almost as good as a plain text file, but with encryption, authorization, and lots of other perks. 😉

Key Vault secrets are essentially a key/value store - but with lots of polish on top of them. At a minimum, you create a secret within Key Vault, give it a name and then place the (secret) value in it.

As the documentation states, the data/secret is encrypted both at rest and in transmission and Microsoft never sees the data contained within. You can monitor the access & use of each secret. And access to secrets is controlled by Active Directory.

You can version secrets - so if the connection string changes you can set the existing value as old and create a new value, with the connection string, all within the same key.

You also can disable keys, set activation and deactivation dates.

And each secret in Key Vault gets its own URI which it can be referenced by.

So it's cool, right? Application secrets in a single spot, encryption by default, and there are even Microsoft provided SDKs to get at them.

So Here's What We're Going To Do In This Article...

We’re going to start out with a Xamarin mobile app. That app is going to access Azure Table storage. The API Key to get at Table storage will be hardcoded into the app.

We want to move the API key into Key Vault. But we don’t want to have any credentials or secrets at all in the mobile app.

So instead we’re going to create a Functions app to use Key Vault. (And you’ll see how we get around the credentials problem below.)

The mobile app will then invoke the Function to get the data.

In fact, anybody will be able to issue a GET request against the Function and receive back the contents of the table.

The API key to Azure Storage is protected within Key Vault and only accessible from the Azure Function. And since the Function only returns data, we’re not concerned with people inserting data into the Table.

If you wanted to lock down the Function so only certain people can access it or limit the data the Function returns based on who’s logged in. Check out my series of articles on authentication and authorization with Azure AD B2C.

Away we go!

Let's Use Key Vault!

So I have an app that pulls some data from Azure Table storage.

It's a Xamarin.Forms app and it displays the data it finds in the Table in a ListView - it looks like this:

The code which grabs the data from Table storage looks like this:

There's a couple things wrong here (or as I like to say, it's demo code!) - but the big one, and the one that we're going to fix, is that the Azure Storage account's API key is hardcoded.

The fix should be fairly easy ... add the API key for Azure Storage to Key Vault, use the .NET Key Vault SDK to grab it, then continue on with the code - pretty much as is.

So Let's Add The Secret!

Adding the secret in Key Vault is easy, easy, easy! (As an aside, don't you hate when people say something is easy? Everything's easy when you already know how to do it. So let's try it again....)

Adding the secret in Key Vault isn't too bad!

Open up your Key Vault in the portal, go to the Secrets option then the Generate/Import button.

Then you'll see this page - on there give the secret a name - and pop in the value. In this case it'll be the storage connection key.

Now on to using Key Vault's .NET SDK to access it from our mobile app and we'll be done!

But... Don't Use Key Vault - In a Mobile App

Ugh... but I have some bad news ... don't use Azure Key Vault when you're building a mobile app.

At least not directly.

You see, we want to keep all app secrets off the device if possible. Even if they're never being stored and will only be in memory transiently.

To solve this particular conumdrum... we're still going to take advantage of Key Vault and all it has to offer and put the Azure Storage API key in there.

But instead of having the mobile app directly access the Table storage, we're going to have an Azure Function do that.

This then gives us several benefits.

We get to use Key Vault! 🎉
Key Vault is accessed completely over the Azure backbone - no public internet - and same for Azure storage. Fast!
We'll end up with an API that can be used in more places than the mobile app.

OK good ... we're going to use Function-Table storage bindings to get at the data. And the mobile app will call that Function.

But how does the Function access Key Vault to retrieve the Azure Storage connection string?

Hardcoding Key Vault's credentials into the Function's app settings would kind of defeat the purpose of not having the Storage's connection string in the app settings.

So how does Azure Functions communicate to Azure Key Vault ... without the hardcoded credentials?

Through the wonders of the Managed Identity.

Managed Identity

So remember when I said that access to the Key Vault is controlled through Active Directory?

It turns out that it's pretty straightforward to make your Function App a member of the Active Directory. And once it's Active Directory-izied you can grant the Function App access to Key Vault as easily as you can grant access to a person that's in Active Directory.

And this is what's known as Managed Identity.

Active Directory-izing Your Function App

This same process goes for any App service.

It's really kinda anti-climatic.

Pop over to the Azure portal for your Function. Select the Platform Features tab, then the Identity option.

You have Active Directory-izied your Functions app.

Now the Functions App (which is really an App Service) will now appear in the Active Directory that your Azure subscription is a part of.

Done (with this part).

Granting the Key Vault Permissions

The next step is to grant the new Active Directory (AD) principal - aka your Function App permission to the secrets contained within Key Vault.

Back over to Key Vault in the Azure portal we go!

You grant new permissions to AD principals through the Access policies option and the Add new button.

The next page then take a bit of explanation.

The first thing you can do is Configure from template. This is a shortcut to select various permissions for you. Which can be seen in the various permissions dropdowns.

I picked Secret Management which selected all the secret functions for me.

The next thing that needs to be done is select the principal to apply these roles to.

And to select your function app - search for its name. Eventually AD will find it. Select the name and hit Select and OK a bunch of times.

And then you're set.

Getting the Function to Talk to Key Vault

Now to get the Function to use Key Vault. The code looks like this:

If you've ever created a Function that accessed Azure Table storage before, you're probably thinking to yourself ... "the Function's code when accessing Key Vault is exactly the same as when it doesn't!"

The Function's code when accessing Key Vault is exactly the same as when it doesn't!

But how does the Function use Key Vault? The magic is in the App Settings. In particular the KeyvaultedStorageConnection string.

To make that particular value access Key Vault - you use this syntax:

So it goes into the Function's app settings. It's the value portion of the KeyvaultedStorageConnection key.

And as you can tell, it uses the syntax: @Microsoft.Keyvault(SecretUri=<A SECRET URI>).

Where does that <A SECRET URI> come from?

From the secret's panel in Key Vault, of course! Back into Key Vault into the portal you go!

Click on Secrets on the left-hand navigation. Then click on the secret you just created. Then by clicking on the current version in the resulting window, you'll see the property's of the secret.

In that window - there's a Secret Identifier box. That's the URI which you'll use for the <A SECRET URI> above.

The App's Code

At this point you're done. Well, except for getting the mobile app to call the Function of course.

The Function in this case is HTTP triggered. So it's a web call from our Xamarin app - looks like this:

That's All Folks

And finally, we've reached the end of our journey!

The mobile app no longer has secrets hardcoded in it, but yet it's not using Key Vault either! Because we don't want any secrets to land on that mobile app if we can at all avoid it.

We're still using Key Vault though, and all of the goodness it provides, and created a Function to access it - through Managed Identity. This way the Function doesn't have to have any secrets stored in it either!

Cool, cool, cool! Not too much extra work - and a ton of extra security!

Now if you'll excuse me - I think there's another rerun of SpongeBob about to air.

A Quick Postscript - Or Using a SAS On Device

Why not use a Storage Access Signature (SAS) to access the Azure Storage Account? Well, from the mobile device that could totally have been done. And with that I could have still used the .NET Storage SDK.

However, to generate that SAS, I would still have needed to get direct access to the Storage account through the full connection string somehow. And that would be done in the same manner as above. Except instead of returning data, the Function would have returned an SAS token.