Over the past eleven years, I’ve worked on everything from high-performance microservices handling billions of hotel bookings to a government-backed mobile app that helps citizens record biodiversity in Australia. But no matter what I’ve worked on, mobile development has always been what I love most.

For almost nine years, I’ve been dedicated to creating mobile apps that users interact with daily, ensuring a smooth experience, optimal performance, and scalable architecture.

Since 2020, my journey has taken an exciting turn into freelancing, where I help businesses build, maintain, and scale their mobile applications. A large part of this expertise has come from co-creating and maintaining Fabulous, a declarative mobile framework for .NET, inspired by architectures like SwiftUI and Elm. My contributions to this field have also been recognized through five consecutive Microsoft MVP awards.

With this foundation, it’s time to push my expertise further—by mastering Jetpack Compose, SwiftUI, and Flutter.

Why Learn New Mobile Frameworks?

Mobile development is always evolving, and keeping up means embracing modern UI frameworks. While React Native is a major player, I prefer strongly typed languages, as I believe a proper type system prevents over 90% of common bugs. That’s one of many ways JavaScript falls short, which is why I’m drawn to Jetpack Compose (Kotlin), SwiftUI (Swift), and Flutter (Dart).

These frameworks have become the go-to choices for Android, iOS, and cross-platform development, and knowing all three lets me offer businesses the right tool for the job instead of a one-size-fits-all approach.

But it’s not just about picking up new technologies—it’s about seeing how different frameworks solve the same problems in their own way. Learning multiple approaches helps refine best practices, improve architecture, and ultimately build better apps.

What Truly Separates a Great Mobile Developer?

A common misconception in hiring and evaluating engineers is focusing solely on years of experience with a specific technology. While experience is valuable, true expertise comes from understanding the core principles of software engineering—which translate across languages and frameworks.

Through my work over the years, I have already developed expertise in:

• Business Goals – Understanding user and stakeholder needs and translating them into features
• User Experience – Designing smooth, performant, and accessible apps for a delightful experience
• Software Architecture – Building scalable, maintainable, and modular systems
• State Management – Choosing the right architecture for the app’s needs (MVU, MVVM, Redux, etc.)
• Performance Optimization – Ensuring responsiveness and efficient memory use
• CI/CD Pipelines – Automating builds, testing, and deployment for mobile apps
• App Distribution – Navigating Apple & Google Play requirements for seamless deployment

These skills aren’t framework-dependent—they are fundamental to great mobile development.

Mastering new mobile UI frameworks isn’t about starting from scratch—it’s about adapting existing expertise to different ecosystems.

My Advantage: Building a Framework from the Inside Out

Most developers learn new frameworks by watching tutorials, reading documentation, and experimenting. My approach is different—I have already built a mobile UI framework.

For over seven years, my work on Fabulous has given me inside-out knowledge of what makes declarative UI frameworks powerful and scalable. This experience gives me a unique perspective when learning new frameworks, as I can analyze not just how they work, but why they were designed the way they are.

Through this journey, I aim to apply my deep understanding of declarative UI to Jetpack Compose, SwiftUI, and Flutter while refining my approach to mobile development across ecosystems.

Understanding the Similarities Between Frameworks

One of the reasons I feel confident jumping into these new frameworks is that I already understand the core principles behind them. Declarative UI frameworks share fundamental concepts, including unidirectional data flow, state management, and component-based design.

To illustrate, here’s a simple counter app implemented in SwiftUI, Jetpack Compose, and Fabulous:

SwiftUI

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("\(count)")
            Button("Increment") {
                count += 1
            }
        }
    }
}

Jetpack Compose

@Composable
fun CounterView() {
    var count by remember { mutableStateOf(0) }

    Column {
        Text("$count")
        Button(onClick = { count++ }) {
            Text("Increment")
        }
    }
}

Fabulous

let CounterView () =
    Component() {
        let! count = Context.State(0)

        VStack(spacing = 20.) {
            Text($"{count.Current}")
            Button("Increment", fun () -> count.Set(count.Current + 1))
        }
    }

These examples demonstrate how similar modern UI frameworks have become. While the syntax differs, the underlying concepts—such as state-driven rendering and UI composition—are nearly identical.

Introducing Snapdex: A Production-Quality Playground for My Learning

As I embark on mastering these frameworks, I wanted a real-world project to apply my knowledge. That’s why I started working on Snapdex.

What is Snapdex?

Inspired by the Pokédex from Pokémon, Snapdex is an app that lets users track Pokémon they encounter in the real world. Whether it’s a plush toy, a poster, a trading card, or even a sound clip from a video game or TV, users can take pictures or record audio, and the app will use AI-powered recognition to identify the Pokémon and unlock its corresponding entry in the Pokédex.

This project is an opportunity to demonstrate expertise across the full spectrum of mobile development, ensuring a seamless and high-quality user experience:

• User Experience & Interface – Designing clean, intuitive, and visually appealing UI with smooth animations.
• Robust Architecture – Implementing best practices in MVI, MVVM, and Clean Architecture for maintainability.
• Data Management & Offline Support – Handling API calls, local database persistence, and seamless offline syncing.
• Security & Authentication – Protecting user data with encrypted storage, secure tokens, and access controls.
• Cloud & AI Integration – Leveraging Firebase/AWS for backend services and AI-powered Pokémon recognition.
• Platform-Specific Features – Accessing camera, microphone, dark mode, system notifications, and deep linking.
• Performance & Stability – Optimizing image caching, monitoring analytics, and ensuring crash resilience.
• Automation & Deployment – Streamlining development with CI/CD, Gradle, Swift Package Manager, and automated testing.
• Localization & Accessibility – Adapting the app for multiple languages and inclusive design.

Each of these aspects will be carefully designed and implemented, ensuring that Snapdex is not just a functional app, but a showcase of best practices in modern mobile development.

Everything will be open-source on GitHub, allowing you to see my work firsthand and evaluate my expertise in real-world scenarios.

Why Snapdex?

• It involves rich UI interactions, perfect for testing new frameworks
• It requires high-performance rendering, a challenge across mobile platforms
• It’s a fun and engaging project, keeping me motivated as I learn

By developing Snapdex in Jetpack Compose, SwiftUI, and Flutter, I can directly compare how each framework handles UI composition, animations, performance optimizations, and scalability.

Looking Ahead

Mastering these frameworks is more than just a technical challenge—it’s about broadening my expertise, increasing my flexibility, and preparing for the future of mobile development.

I believe that the best mobile developers aren’t defined by a single framework, but by their understanding of core engineering principles. Jetpack Compose, SwiftUI, and Flutter represent the future of mobile development, and I’m excited to push my skills further by diving deep into each of them.

This is the next chapter of my journey—and I’m eager to share what I learn along the way.

Final Thoughts

If you’re also navigating the shift to modern declarative UI frameworks, I’d love to hear your thoughts! Have you transitioned to Jetpack Compose, SwiftUI, or Flutter? What challenges did you face, and how did your prior experience shape your learning process? Let’s connect and learn together.

Follow My Progress:

• Find me at https://timothelariviere.com
• Follow Snapdex on GitHub
• Learn more about Fabulous
• Connect with me on LinkedIn

Version 2.0 is the first of several major releases.
It comes with a brand new DSL inspired by SwiftUI and improved performance to ensure the best possible development experience.

In later releases, we will introduce support for MAUI and support for components to help you scale your apps with ease.
If you’re interested, you can read more about it here: Reasonable goals of v2

I want to thank all Fabulous contributors for their contributions and support over the years.
Special thanks to Simon Korzunov (@twopSK) for helping design the new architecture and for his awesome work on performance improvements, and Edgar Gonzalez (@efgpdev) for his first contributions in Open Source by patiently mapping all Xamarin.Forms controls to Fabulous 2.0 and providing a lot of feedback.

What’s new in version 2.0

New View DSL

We’re introducing a new DSL for Fabulous, inspired by SwiftUI.
This DSL is more concise, easier to extend and features proper type-safety to ensure your code is readable and always working as intended.

It makes use of 2 new concepts: Widgets and Modifiers.

Widgets are the building blocks of your UI. You compose them together to define what your app looks like.
Some of those widgets will require essential properties to be passed as parameters: for example Label requires a text parameter, Button requires a text and onClicked parameters, etc.

In v1.0, properties were available as optional parameters and some as extension methods.
Now in v2.0, properties are now all set through modifiers.

Those modifiers are accessible via the dot notation.

Label("Hello, World")
    .font(namedSize = NamedSize.Large, fontFamily = "Arial")
    .textColor(light = FabColor.Red, dark = FabColor.Blue)
    .horizontalTextAlignment(TextAlignment.Center)
    .padding(10.)

Thanks to the strongly-typed nature of Widget, the compiler will now prevent you from combining incompatible widgets.

And your IDE will only show you the modifiers available for the current widget.

For comparison, here is the same UI in both v1.0 and v2.0:

/// Fabulous 1.0
let view model dispatch =
    View.ContentPage(
        title = "Home",
        content =
            View.StackLayout(
                orientation = StackOrientation.Vertical,
                spacing = 8.0,
                children = [
                    View.Label(
                        text = "Welcome to Fabulous 1.0!",
                        fontSize = FontSize.FromNamedSize(NamedSize.Large)
                    )

                    View.Label(
                        text = $"Click count = {model.Count}"
                    )

                    View.Button(
                        text = "Click me!",
                        command = (fun () -> dispatch ButtonClicked),
                        foregroundColor = Color.FromHex("#FF0000")
                    )
                ]
            )
    )
    
// Fabulous 2.0
let view model =
    ContentPage("Home",
        VStack(spacing = 8.0) {
            Label("Welcome to Fabulous 2.0!")
                .font(namedSize = NamedSize.Large)

            Label($"Click count = {model.Count}")
            
            Button("Click me!", ButtonClicked)
                .foregroundColor(FabColor.fromHex "#FF0000")
        }
    )

You may have noticed dispatch is missing in Fabulous 2.0. We take care of dispatching messages for you now, so you can focus on the UI itself.

Focus on performance

The second major improvement is reduced allocations on hot paths. This will make your apps faster and more responsive.

Almost all the internal infrastructure of Fabulous now works with structs instead of classes.
This drastically reduces GC pressure on your apps by keeping as much as possible on the stack.

We’ve also optimized for CPU cache misses to achieve even better performances.

And finally, we optimized for trimming in Release builds to produce the smallest binaries possible.

Comparison of dll sizes for FabulousContacts between Fabulous 1.0 and 2.0 (iOS release build with linker enabled)

More than 80% reduction in dll size overall for Fabulous 2.0, leading to 13% size reduction for the FabulousContacts app itself!
This is a huge improvement over 1.0.

_{* Please note that for some dlls, the F# optimization and signature data can make for a big chunk of the dll size (2/3 in case of F.XF.dll, about ~0.7 MB).
Those data are not used at runtime but the Xamarin linker doesn’t remove them.
After we start support for MAUI, the dll sizes will be much smaller thanks to the .NET 6.0 linker removing those unused data.}

_{** Fabulous.XamarinForms.Maps is not available yet for Fabulous 2.0.
Instead the Map widget has been directly integrated into FabulousContacts.}

_{*** Decompressed IPA files}

Better 3rd party support and extensibility

With the new Widgets and Modifiers, extending an existing widget is as easy as declaring an extension method!
Also makes it very easy to add 3rd party support.

Here is an example of adding support for the Xamarin.Forms.Map control:

// Declare a marker interface (used for strong-typing the widget)
type IMap = inherit Fabulous.XamarinForms.IView

module Map =
    // Tell Fabulous to instantiate Xamarin.Forms.Map when using Map widget
    let WidgetKey = Widgets.register<Xamarin.Forms.Map>()

    // Define which properties will be available
    let RequestedRegion = Attributes.defineSimpleScalarWithEquality<MapSpan> (...) // code omitted for brevity
    let HasZoomEnabled = Attributes.defineBindableBool Xamarin.Forms.Map.HasZoomEnabledProperty
    let HasScrollEnabled = Attributes.defineBindableBool Xamarin.Forms.Map.HasScrollEnabledProperty

[<AutoOpen>]
module MapBuilders =
    type Fabulous.XamarinForms.View with
        // Expose Map widget with a specific constructor (requestedRegion will be mandatory)
        static member inline Map<'msg>(requestedRegion) =
            WidgetBuilder<'msg, IMap>(
                Map.WidgetKey,
                Map.RequestedRegion.WithValue(requestedRegion)
            )

[<Extension>]
type MapModifiers =
    // Define the withZoom modifier
    [<Extension>]
    static member inline withZoom(this: WidgetBuilder<'msg, #IMap>, ?enabled: bool) =
        let value = match enabled with None -> true | Some v -> v
        this.AddScalar(Map.HasZoomEnabled.WithValue(value))

    // Define the withScroll modifier
    [<Extension>]
    static member inline withScroll(this: WidgetBuilder<'msg, #IMap>, ?enabled: bool) =
        let value = match enabled with None -> true | Some v -> v
        this.AddScalar(Map.HasScrollEnabled.WithValue(value))

// Usage
Map(MapSpan.FromCenterAndRadius(...))
    .withZoom()
    .withScroll(false)

Support for other frameworks

One key feature of Fabulous is the possibility to be integrated with frameworks, other than Xamarin.Forms.

We made it even easier in version 2.0 by providing the whole reconciliation infrastructure directly as part of the Fabulous library.
All you need to do to integrate Fabulous with your framework is to implement the widgets and modifiers you need.

Fabulous will take care of the rest.

New Fabulous website

Along with this new release, we also launched a new website dedicated to Fabulous.

https://fabulous.dev

It’s a great place to learn more about Fabulous, and to see how it’s used in the wild.
Documentation is available at https://docs.fabulous.dev

Right now, the website is in a very early stage, but we’re working hard to make it as useful as possible.
We are currently focusing on adding more documentation for 2.0.

We are looking for contributors to help us improve the website itself.
If you’re interested in contributing to the website, please contact us on the Fabulous Discord channel.

Get started today

You can start right now by installing the templates available on NuGet!

Follow the Getting Started guide to learn start to use Fabulous 2.0: https://docs.fabulous.dev/v2/getting-started

If you have any questions, feel free to ask them on the Discord channel or raise issues on GitHub: https://github.com/fsprojects/Fabulous
We are also available on Twitter @FabulousAppDev.

If this year, like all the previous ones, you wrote Santa asking him to bring a new framework finally letting you write apps you’ll love, with a clean, easy-to-use, reliable, maintainable and testable architecture, your present has come early!

Today, we will see together what Fabulous is, what it offers, and how it helps you build apps that you will finally be proud of.

F# and the MVU architecture

Recently, frameworks like Elm, React-Redux and Flutter became really popular thanks in part to their alternative approach to app development, showing that mainstream MVC / MVVM architectures were not the only way to go.

Elm introduced its own architecture: MVU, standing for Model View Update, which inspired Redux.

The concept is to have a central state (the model) that can only be updated through messages sent by the UI when the user interacts with it, or by a “subscription” sending messages at any point in time (e.g. a push notification, an asynchronous task that completes, etc.).
When the state is updated, the view is reevaluated to define how it should look for this particular state.

Credits: Beginning Elm (https://elmprogramming.com)

This architecture has several advantages over traditional ones:

• Centralized state and updates
  The immutability of the state is one of the greatest asset of MVU.
  It ensures that developers can only update the state through messages, declared in an enum-like type, thus centralizing all possible changes.
  No more implicit changes, sometimes hidden deep in the source code, that can be understood only if you know perfectly how the application works.

• No concurrency issues
  By updating the state only through messages, it allows the framework to apply concurrent messages one after the other.

• Explicit views at each update
  In a typical app framework, you would define your UI once and react to the user input by updating parts of it little by little. So to understand what made the UI look that way, you need to mentally reenact what the user did.
  In MVU, you’re no longer responsible for that. Instead, each time the state is updated, you’re asked to provide the complete view for this particular state (usually through a virtual representation) without having to think about what was the previous UI. The framework takes the responsability to update the UI.

• Reproducible views
  The fact your view is reevaluated each time the state is updated means that you can write side effect-free functions (aka pure functions) to generate the view according to a given state. This means that if you provide the same state, you will get the exact same view. Very convenient to test!

At any time, you know the complete state of your application and can trace what sequence of messages brought it to that state. (time-travel debugging FTW!)

For more information on MVU, please read the Elm’s website.

This architecture is a perfect match for functional programming.
Pure functions, immutability, exhaustive pattern matching and so on. All are natural attributes of functional languages, like F#!

Hence, the architecture of Elm was ported to the F# programming language: Elmish was born.

What about Fabulous?

Fabulous is heavily inspired by Elmish. They, in fact, share a common approach to MVU.

Fabulous is an open-source, community driven set of .NET Standard 2.0 libraries to write apps in F# using an MVU architecture available as NuGet packages.
The source code can be found on GitHub.

It started as Elmish.XamarinForms, providing only something called “static views” based on Xamarin.Forms. Later on, a “dynamic views” approach (still for Xamarin.Forms) has been introduced and it was renamed Fabulous for the occasion. Finally, it evolved in a set of platform-agnostic libraries, allowing you to use your favorite framework by adding support for it with a small adapter library.

The Xamarin.Forms part has been extracted into its own adapter library. But it remains the only officially supported framework as of today.

While Elmish decided to let the users “bring their own views” by not forcing a way to declare views, Fabulous provides several ways to define them: static, dynamic and adaptive views.

They all use the same building blocks:

• A model (usually named Model)
• A set of messages (usually named Msg)
• An init function giving the default model at the start of the application
• An update function applying the corresponding changes to the model for a given message, returning a new model
• A view function that will apply the new model to the UI

Once we have all those building blocks, we can assemble them in a Program that we will use to start the MVU application loop.

open Fabulous

type Model =
    { Count: int }

type Msg =
    | Increment
    | Decrement

let init () =
    { Count = 0 }

let update msg model =
    match msg with
    | Increment -> { model with Count = model.Count + 1 }
    | Decrement -> { model with Count = model.Count - 1 }

let view ... =
    // We will see how we can define our UI later in this post
    ...

let program = Program.mkSimple init update view

One of the advantages of this architecture is that it’s completely composable.
As the application grows, you can create sub-components with their own Model/Msg/init/update/view that you can call inside their parent component.

The view function, your choice

All the examples will use Xamarin.Forms. Like said before, Fabulous was initially all about Xamarin.Forms so it remains the most fully supported framework.

To see the difference between each way to write a view, we will take the same application, a simple counter app.

Fabulous has been tested on the following platforms supported by Xamarin.Forms:

• Android
• iOS
• UWP
• WPF
• macOS
• GTK

Static views

Fabulous.StaticView is a good way to gently move from an existing application to an F# MVU one, or make apps with heavy and complex UIs while benefiting from the advantages of Fabulous.

The concept is very similar to Elmish.WPF. You define the whole state of the application using MVU but the UI keeps getting declared in its native language (XAML for Xamarin.Forms, Storyboard for iOS, etc.).

In the view function, you expose a set of values and event handlers to the UI.
With Xamarin.Forms, this is done through bindings.

// Binding.oneWay exposes a value from the current model
// Binding.msg creates a command that will send a message when executed
let view () =
    [ "CounterValue" |> Binding.oneWay (fun m -> m.Count)
      "IncrementCommand" |> Binding.msg Increment
      "DecrementCommand" |> Binding.msg Decrement ]

<ContentPage>
    <StackLayout>
        <Label Text="{Binding Path=[Count]}" HorizontalOptions="Center" />
        <Button Text="Increment" Command="{Binding Path=[IncrementCommand]}" />
        <Button Text="Decrement" Command="{Binding Path=[DecrementCommand]}" />
    </StackLayout>
</ContentPage>

Now that our view function is declared, we can start our application with our previously declared program.

type FabulousApp() as this = 
    inherit Xamarin.Forms.Application ()

    let runner =
        program
#if DEBUG
        |> Program.withConsoleTrace
#endif
        |> Program.runWithStaticView
    
    do this.MainPage <- runner.InitialMainPage

Notice the Program.withConsoleTrace?
This allows us to check what’s going on in our application. It’s a logging mechanism that plugs directly in the MVU loop of Fabulous.
Each time a model is initialized or a message is sent, we will see what the model was and how it was changed as well as if there was an error updating the UI.

See Fabulous.StaticView on the Fabulous repository for more information

Dynamic views

Fabulous “Dynamic Views” (shortened to Fabulous) is the most popular option of the 3.
Instead of writing views using your framework’s native view language, you write it directly in F# via a special View module that wraps all the supported controls.

let view model dispatch =
    View.ContentPage(
        View.StackLayout([
            View.Label(text = model.Count.ToString(), horizontalOptions = LayoutOptions.Center)
            View.Button(text = "Increment", command = fun() -> dispatch Increment)
            View.Button(text = "Decrement", command = fun() -> dispatch Decrement)
        ])
    )

type FabulousApp () as app = 
    inherit Application ()

    let runner =
        program
#if DEBUG
        |> Program.withConsoleTrace
#endif
        |> XamarinFormsProgram.run app

This has a lot of advantages over the previous approach:

• One language to rule them all
  Why having to learn and use 2 (or more) different languages, with uneven tooling support, to write an app? A lot of people tend to prefer to use a single language, even if it means no designer view or harder to write constructs like bindings.
  With “Dynamic Views”, you write everything in F#, including views. No more runtime errors because you provided the wrong value to a property (or mistyped that binding name once again…).
  The F# compiler will be there to help you.

• Virtual views and incremental updates
  For performance reasons, the views you write don’t directly instantiate the actual controls. Instead, Fabulous will apply a diff’ing algorithm to check what changed between the new virtual view and the previous one, and apply only the required changes.
  This is called incremental updates.

• Adapted to functional use
  Since Fabulous provides its own wrappers over the controls, it’s able to make them more functional-friendly.

/// Bindings
<Label Text="{Binding Value}" />
vs.
View.Label(text = model.Value)

/// Columns and rows
<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="Auto" />
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="2.5*" />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
        <RowDefinition Width="Auto" />
        <RowDefinition Width="*" />
        <RowDefinition Width="2.5*whoops mistyped here" />
    </Grid.RowDefinitions>
</Grid>

vs.

View.Grid(
    coldefs = [ Auto; Star; Stars 2.5 ],
    rowdefs = [ Auto; Star; Stars 2.5 ]
)

/// DataTemplate / ItemsSource / Converter
<ListView ItemsSource="{Binding Items}">
    <ListView.ItemTemplate>
        <DataTemplate>
            <ViewCell>
                <Label Text="{Binding Name}"
                       TextColor="{Binding IsMinor, Converter={StaticResource BoolToTextColorConverter}}" />
            </ViewCell>
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

public class BoolToTextColorConverter : IValueConverter { ... }

<Application xmlns:local="...">
    <Application.Resources>
        <local:BoolToTextColorConverter x:Key="BoolToTextColorConverter" />
    </Application.Resources>
<Application>

vs.

View.ListView([
    for item in model.Items ->
        yield View.ViewCell(
            View.Label(
                text = item.Name,
                textColor = if item.IsMinor then Color.Red else Color.Blue
            )
        )
])

Those are only a few examples. And F# 4.7 will remove the need for yield and prefixing with View..

As you may have seen in the last example, since this is F# code, you can easily write conditional views.

match model.UserData with
| None ->
    View.Button(text = "Log in", command = fun () -> dispatch StartLogin)
| Some user ->
    View.Label(
        text = user.Name,
        textColor = if user.IsPremium then Color.Gold else Color.Black
    )

Fabulous lets you write any kind of apps easily. Here’s a few open-source ones using dynamic views:

(From left to right: FSharp Weekly, FabulousContacts and FabulousPlanets)

Templates are available to help you start a new solution.
More information in the Getting Started guide and on the Fabulous repository.

Adaptive views

AdaptiveFabulous can be seen as a mix of the two previous approaches.

Like dynamic views, you declare the UI through a virtual representation that gets called on each update. But for increased performance (in intensive use cases, like real-time data), it also supports immediate bindings that will update the UI directly instead of waiting for a complete reevaluation.

This is achieved thanks to FSharp.Data.Adaptive.

Currently, it is completely experimental and is developed by Don Syme.

A conversion is currently needed between the “classic” model and the adaptive one. But this will be eventually automated with Adaptify.

/// An adaptive version of the model. 
type AdaptiveModel = { Count: cval<int> }

/// Initialize an adaptive version of the model.
let ainit (model: Model) = { Text = cval model.Count }

/// Update an adaptive version of the model. 
let adelta (model: Model) (amodel: AdaptiveModel) =
    transact (fun () -> 
        if model.Count <> amodel.Count.Value then 
            amodel.Count.Value <- model.Count
    )

c and cs mean that the values are constants and won’t change dynamically so there’s no need to listen to their changes. amodel.Count on the other hand will change.

let view amodel dispatch =
    View.ContentPage(c
        View.StackLayout(cs [
            View.Label(text = amodel.Count, horizontalOptions = c LayoutOptions.Center)
            View.Button(text = c "Increment", command = c (fun() -> dispatch Increment))
            View.Button(text = c "Decrement", command = c (fun() -> dispatch Decrement))
        ])
    )

See the AdaptiveFabulous repository for more information

Testing the application

Our application is composed of 3 major parts: init, update and view.
They’re all functions, even more, they are pure, making them perfect candidates for unit testing!

Before we start testing them, we need to set identifiers to let our tests know which control is which. This is done through automationId.

let view model dispatch =
    View.ContentPage(
        View.StackLayout([
            View.Label(automationId = "CountLabel", text = model.Count.ToString())
            View.Button(automationId = "IncrementButton", text = "Increment", command = fun() -> dispatch Increment)
            View.Button(automationId = "DecrementButton", text = "Decrement", command = fun() -> dispatch Decrement)
        ])
    )

Then, it’s fairly typical unit testing for init and update (using FsUnit and NUnit).

open NUnit.Framework
open FsUnit
open FabulousApp
open Fabulous.XamarinForms

module ``Init tests`` =
    [<Test>]
    let ``Init should return a valid initial state``() =
        let initialState = { Count = 0 }
        App.init () |> should equal initialState

module ``Update tests`` =
    [<Test>]
    let ``Given the message Increment, Update should increment Count``() =
        let initialModel = { Count = 5 }
        let expectedState = { Count = 6 }
        App.update Increment initialModel |> should equal expectedState

    [<Test>]
    let ``Given the message Decrement, Update should decrement Count``() =
        let initialModel = { Count = 5 }
        let expectedState = { Count = 4 }
        App.update Decrement initialModel |> should equal expectedState

Testing view is a bit special.

Fabulous (dynamic views) stores your virtual view in a ViewElement, which is a glorified key-value dictionary.
So, first we need to find our controls with the helper function findViewElement by providing it the previously declared AutomationIds.
Then we feed the retrieved ViewElement to an helper class that will provide a nicely typed wrapper for a specific control.
Each control has its matching Viewer helper class.

module ``View tests`` =
    [<Test>]
    let ``View should generate a valid interface``() =
        let model = { Count = 5 }
        let actualView = App.view model ignore

        let countLabel = actualView |> findViewElement "CountLabel" |> LabelViewer
        let incrementButton = actualView |> findViewElement "IncrementButton" |> ButtonViewer
        let decrementButton = actualView |> findViewElement "DecrementButton" |> ButtonViewer

        countLabel.Text |> should equal "5"
        incrementButton.Text |> should equal "Increment"
        decrementButton.Text |> should equal "Decrement"

    [<Test>]
    let ``Clicking the button Increment should send the message Increment``() =
        let mockedDispatch msg =
            msg |> should equal Increment

        let model = { Count = 5 }
        let actualView = App.view model mockedDispatch

        let incrementButton = actualView |> findViewElement "IncrementButton" |> ButtonViewer

        incrementButton.Command ()

    [<Test>]
    let ``Clicking the button Decrement should send the message Decrement``() =
        let mockedDispatch msg =
            msg |> should equal Decrement

        let model = { Count = 5 }
        let actualView = App.view model mockedDispatch

        let decrementButton = actualView |> findViewElement "DecrementButton" |> ButtonViewer

        decrementButton.Command ()

But what if I don’t want to use Xamarin.Forms?

Fabulous.StaticView and AdaptiveFabulous are not currently meant to be used without Xamarin.Forms.
If you really want the same static views experience with another framework, take a look at other existing libraries that do it really well, like Elmish.WPF.

Fabulous (dynamic views), on the other hand, is platform-agnostic meaning you can plug your favorite framework, at the condition you or someone else wrote the corresponding adapter library (with the appropriate control wrappers).

This is greatly simplified by Fabulous.CodeGen which will generate most of the code for you, if you provide it with the target framework dlls and instructions on what you want it to generate.
This generated code can then be embedded in the adapter library.

Example of the “Bindings” file - Example of the generated code

A few libraries are already making use of it:

• Fabulous.XamarinForms for Xamarin.Forms
• Fabulous.WPF for WPF (Proof of Concept)
• Fabulous.iOS for Xamarin.iOS (Proof of Concept)
• Uno.Fabulous for Uno Platform by Jérôme Laban (Proof of Concept)

There are similar alternatives to Fabulous targeting other frameworks, like Elmish.WPF.Dynamic and Avalonia.FuncUI.

Accelerating the development process with LiveUpdate

Fabulous (dynamic views) has a tool called LiveUpdate, which is similar to Hot Reload (of React, Flutter and Xamarin.Forms).
Just like Fabulous, LiveUpdate is technically compatible with all frameworks, though it will need an adapter for the specific framework you use.

With it, you can experience faster development feedback. After enabling it and starting a debug session (either on an emulator or an actual device), every time you make changes to the source code and save, the code is recompiled and injected in the running app. This allows you to quickly see the impact of your changes (1 to 2 seconds of wait), instead of stopping the app, rebuilding it, and once again debug.

To enable it, it’s really simple.
You’ll need to install fabulous-cli if you haven’t already via the command line.

dotnet tool install -g fabulous-cli

Then, add the corresponding NuGet package (here it’s Fabulous.XamarinForms.LiveUpdate) to all projects in the solution.
After that, in your shared project (where your app code is), add the following lines after the declaration of the runner.

open Fabulous.XamarinForms.LiveUpdate

#if DEBUG
    do runner.EnableLiveUpdate ()
#endif

When debugging, a message will be printed in the output window of your IDE.

LiveUpdate: Ready for connection. Will show this message 3 more times.

LiveUpdate: Connect using:
   fabulous --watch --webhook:http://192.168.1.53:9867/update

Execute the given command line and you’re ready to go!

What’s next?

The new way of writing apps using patterns like MVU and virtual views is getting a lot of traction recently. Well known frameworks like Elm, React-Redux or Flutter are making use of it. Even major actors want to provide their own (Apple with SwiftUI, Google with Android Jetpack Compose).

One thing to note is that such patterns are perfectly adapted to functional languages.

In the .NET world, Fabulous achieves this with F#.
A really great language, an easy - reliable - maintainable architecture, an ultra-complete .NET ecosystem; perfect recipe for an awesome app!

Even more, Fabulous lets you choose the way you want to write your views with your framework of choice: static, dynamic or adaptive views.
All that with useful tools like LiveUpdate.

For the future, we’re working on getting Fabulous to a v1.0 production ready release.
We’re also working on adding more support for other frameworks, beyond Xamarin.Forms.

If you want to get started today, please read the documentation of your preferred way: static views, dynamic views, or adaptive views.

Contributing

If you’re interested to contribute to Fabulous, you can head to the Fabulous repository on GitHub. There, you will be able to participate through issue reports, pull requests, code reviews and discussion.

Also if you want to stay updated, follow me on Twitter @Tim_Lariviere.

I wish you a happy Christmas, and a lot of other awesome #FsAdvent posts!

Setting up a graph database is really easy thanks to Azure Cosmos DB. Azure Cosmos DB is a multi-model database hosted on Microsoft Azure with lots of cool features such as a Graph API (with support for the popular Gremlin language) and turn-key worldwide distribution. For more information on Azure Cosmos DB, head to the documentation.

In this post, I will show you how to make a .NET Core app written in F# that will use the Graph API of Azure Cosmos DB.

Azure Cosmos DB Graph SDK

Microsoft made an SDK to interact with the Graph API, available on NuGet : Microsoft.Azure.Graphs It’s currently in preview, so to find it, you’ll have to make sure to enable preview versions.

This SDK contains methods for most of the things we’ll need for the graph database. It handles connecting to it, querying it, and even dynamically creating new graphs.

It comes with its own Gremlin driver (the thing that handles the connection). That’s what I call the Cosmos DB driver. It has some limitations compared to the Gremlin.NET driver (for instance, named parameters are missing). I will explain how to use Gremlin.NET instead in a next post.

Before we’re able to use the SDK, we’ll need some configuration from the Azure portal.

Getting the configuration parameters

Creating a new Azure Cosmos DB resource on the Azure portal is really simple. Just select “Azure Cosmos DB account”, click “Create” and fill out the form (and make sure to select “Gremlin (graph)”)

Wait until Azure is done creating the resource.

To use the SDK, we will need the following values :

• Endpoint
• AuthKey
• DatabaseName
• GraphName
• OfferThroughput

Endpoint and AuthKey can be found in the Keys tab. Endpoint is the URI field and AuthKey is either the Primary or Secondary Key.

For the last 3 parameters, DatabaseName will be the name of the database (much like a database server in SQL Server) that will contain the graphs (the real databases). GraphName will be the name of our graph, and OfferThroughput is an indicator of the level of service you want for your graph (measured in Request Units per second, each request has its own RU cost).

For the sample, we’ll go with DatabaseName = "sample-cosmosdb-database", GraphName = "sample-cosmosdb-graph" and OfferThroughput = 400 (the minimum). We’ll store those settings in a json file named appsettings.json that our app will read.

appsettings.json

{
    "AzureCosmosDb": {
        "Endpoint": "https://[YOUR-AZURECOSMOSDB-ACCOUNT-NAME].documents.azure.com:443/",
        "AuthKey": "[YOUR-PRIMARY-KEY]",
        "DatabaseName": "sample-cosmosdb-database",
        "GraphName": "sample-cosmosdb-graph",
        "OfferThroughput" : 400
    }
}

Creating the project

Making a .NET Core app in F# is as simple as running a single command line: (Of course, you can also create the project using Visual Studio) dotnet new console -lang F# -n AzureCosmosDbSample

This creates 2 files (AzureCosmosDbSample.fsproj and Program.fs) for a working Hello world console in F#/.NET Core.

Before going on, we will need a few NuGet packages:

• Microsoft.Azure.Graphs: Obviously
• FSharp.Control.AsyncSeq: We will use it to asynchronously retrieve the query results
• Microsoft.Extensions.Configuration.Json: To read our settings file
• FSharp.Core: Because you should always reference it explicitly

Add the latest version of each using the NuGet GUI of Visual Studio, or if you prefer command lines:

dotnet add package Microsoft.Azure.Graphs -v 0.3.1-preview
dotnet add package FSharp.Control.AsyncSeq -v 2.0.21
dotnet add package Microsoft.Extensions.Configuration.Json -v 2.0.1
dotnet add package FSharp.Core -v 4.3.4

Now we can start writing code in the Program.fs file.

Using the Azure Cosmos DB SDK

The key class in the Azure Cosmos DB SDK is DocumentClient, so let’s make a function to instantiate it. The constructor takes our previously defined Endpoint and AuthKey.

let createClient endpoint (authKey: string) =
    new DocumentClient(
        new Uri(endpoint),
        authKey,
        ConnectionPolicy.Default
    )

Next, as we didn’t created the database and graph manually, we need to ensure that the database is properly created before querying the graph. Lucky for us, DocumentClient has a CreateDatabaseIfNotExistsAsync method that takes only our configured DatabaseName. Note that the code below doesn’t return the database. That’s because the database instance is not required to run queries.

let createDatabaseAsync databaseName (client: DocumentClient) =
    new Database (Id = databaseName)
    |> client.CreateDatabaseIfNotExistsAsync
    |> Async.AwaitTask
    |> Async.Ignore

Same goes for the graph (using CreateDocumentCollectionIfNotExistsAsync). Except this time, we need to return the graph’s instance to be able to run queries afterwards.

We provide our DatabaseName, GraphName, and OfferThroughput.

let createGraphAsync databaseName graphName offerThroughput (client: DocumentClient) =
    let throughput = Nullable<int>(offerThroughput)
    
    client.CreateDocumentCollectionIfNotExistsAsync(
        UriFactory.CreateDatabaseUri(databaseName),
        new DocumentCollection (Id = graphName),
        new RequestOptions (OfferThroughput = throughput)
    )
    |> Async.AwaitTask
    |> (fun asyncResult -> async { let! result = asyncResult return result.Resource })

And now for the crucial part, running queries. Queries are made by calling client.CreateGremlinQuery with the previously created client, graph and the actual Gremlin request (as a string). This returns a Reader that exposes ExecuteNextAsync to get the next page of results. To ease its usage, the call to ExecuteNextAsync is wrapped into an asynchronous sequence. So enumerating that sequence will give all the query’s results, in an asynchronous manner.

Note that ExecuteNextAsync is generic. Behind the scene, every results retrieved from Azure Cosmos DB (sent as a JSON payload, known as GraphSON) will be converted to the given type via Newtonsoft.Json. The SDK already has some predefined types for that task, such as Vertex and Edge.

let runGremlinQuery<'T> (dq: IDocumentQuery<'T>) =
    asyncSeq {
        while (dq.HasMoreResults) do
            let! items = dq.ExecuteNextAsync<'T>()
                         |> Async.AwaitTask
            
            for item in items do
                yield item
    }

let runQueryWithClient<'T> (client: DocumentClient) graph query =
    client.CreateGremlinQuery<'T>(graph, query)
    |> runGremlinQuery<'T>

Last step, read our settings file using Microsoft.Extensions.Configuration.Json.

type AzureCosmosDbConfiguration =
    { Endpoint: string
      AuthKey: string
      DatabaseName: string
      GraphName: string
      OfferThroughput: int }

let getConfiguration() =
    ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json")
        .Build()

let readAzureCosmosDbConfiguration (configuration: IConfigurationRoot) =
    { Endpoint = configuration.["AzureCosmosDb:Endpoint"]
      AuthKey = configuration.["AzureCosmosDb:AuthKey"]
      DatabaseName = configuration.["AzureCosmosDb:DatabaseName"]
      GraphName = configuration.["AzureCosmosDb:GraphName"]
      OfferThroughput = (configuration.["AzureCosmosDb:OfferThroughput"] |> int) }

We have all our tooling ready, now we can move on and actually run the sample.

Running the sample

First step is to initialize our environment.

// Get the configuration
let configuration = getConfiguration() |> readAzureCosmosDbConfiguration

// Create the client
let client = createClient configuration.Endpoint configuration.AuthKey

// Ensure that the database is created
do! createDatabaseAsync configuration.DatabaseName client

// Ensure that the graph is created
// and store its instance
let! graph =
    createGraphAsync
        configuration.DatabaseName
        configuration.GraphName
        configuration.OfferThroughput
        client

To have a code easier to read, I partially applied the call to runQueryWithClient to always use the same client and graph.

// Prepare a query runner that won't
// return results
let executeQuery = runQueryWithClient<obj> client graph >> AsyncSeq.iter ignore

// Prepare a query runner that will
// return a list of vertices
let getVertices = runQueryWithClient<Vertex> client graph >> AsyncSeq.toListAsync

// Prepare a query runner that will
// return a single vertex
let getSingleVertex = getVertices >> List.head

Now we’re all done, and can start running our queries.

// Add data
do! executeQuery
    "g.addV('person')
      .property('id', 'thomas')
      .property('firstName', 'Thomas')
      .property('age', 44)"

// Retrieve data
let! thomas = getSingleVertex "g.V('thomas')"

But why such an exception? When running the function locally, all was fine.

That’s because when Azure runs your function, it runs it inside a process that is already using an older version of FSharp.Core. And when it tries to load the FSharp.Core.dll from the /bin folder, it fails. The F# Core Engineering team warns us about it: Some systems supporting F# (e.g. Azure Functions, Azure Notebooks, F# Interactive) may assume a fixed FSharp.Core

So what should you do? As of now, there’s no way to use a version of FSharp.Core higher than 4.4.1.0 (nuget version 4.2.3). The only way is to force NuGet to restore the FSharp.Core package 4.2.3.

If you’re using .NET Standard 2.0 and the new fsproj format, you should have the following project file:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
    </PropertyGroup>
</Project>

FSharp.Core is included by default when using Microsoft.NET.Sdk If you’re deploying from Mac, your function will run fine, but not if you’re deploying from Windows. That’s because the default FSharp.Core included is not the same.

Microsoft.FSharp.NetSdk.targets on Mac

<PropertyGroup Condition=" '$(FSharpCoreImplicitPackageVersion)' == '' ">
    <FSharpCoreImplicitPackageVersion>4.2.*</FSharpCoreImplicitPackageVersion>
</PropertyGroup>

Microsoft.FSharp.NetSdk.targets on Windows

<PropertyGroup Condition=" '$(FSharpCoreImplicitPackageVersion)' == '' ">
    <FSharpCoreImplicitPackageVersion>4.3.*</FSharpCoreImplicitPackageVersion>
</PropertyGroup>

To ensure that your function will run whatever OS you’re deploying from, just set the value of FSharpCoreImplicitPackageVersion.

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
        <FSharpCoreImplicitPackageVersion>4.2.3</FSharpCoreImplicitPackageVersion>
    </PropertyGroup>
</Project>

As previously, a sample is available on GitHub: https://github.com/TimLariviere/Sample-XamarinAuth-Facebook

Facebook authentication with Xamarin.Auth

Unlike Google, Facebook doesn’t require us to use native SDKs to authenticate users. So we can let the IsUsingNativeUI flag of Xamarin.Auth disabled, which is hopeful because restrictions on the Redirect URL would have prevented us to enable it.

Facebook exclusively wants HTTP/HTTPS redirect URLs thus not allowing us to use the deep link technique as we’ve done in the previous post (well to be fair, we could but it would require us extra work).

With that in mind, configuring Facebook with Xamarin.Auth is essentially much simpler than Google.

Configuring the Facebook for Developers portal

Before starting, we’ll need to declare our app in the Facebook for Developers portal. Go to https://developers.facebook.com/apps

If you haven’t already, create a new App ID.

Once created, we’ll need to enable the OAuth feature by adding Facebook Login to our app declaration. For that, click “+ Add Product” in the left menu and then set up Facebook Login.

There’s only one thing that we need to configure in Facebook Login: the redirect URL that we will use to let Xamarin.Auth know that the authentication flow has ended.

That Redirect URL can be any valid HTTP/HTTPS URLs, it’s just an indicator that the authentication has completed and won’t be visible to your users. Facebook provides a default URL that you can use: https://www.facebook.com/connect/login_success.html

By default, our application is in development mode, only allowing members of our team (defined under Roles) to authenticate. Any other account will see a message stating that they can’t connect due to the development mode.

If you want anyone to access your app, you’ll need to switch to production. There’s a switch for that under App Review.

Notice that there’s already a few permissions given to our app including the authorization to retrieve the user’s email address. We’re lucky!

Make sure to note down the App ID as we’ll need it in our Xamarin apps.

And we’re done for the declaration part. Android and iOS will use the exact same configuration, so there’s nothing more to do.

Implementing Facebook authentication in the PCL project

1-2. NuGet Packages & Using Xamarin.Auth

I won’t go into details here, as I’ve already described it on the previous post.

For the sake of this post, here’s the 2 packages we’ll need:

• Xamarin.Auth (version used 1.5.0.3)
• Newtonsoft.Json (version used 10.0.3)

Like Google, Facebook authentication is done using OAuth2, so we will use the OAuth2Authenticator class provided by Xamarin.Auth. Facebook will automatically provide the Access Token once we’re authenticated, so there’s no need for an AccessTokenUrl.

This time, we will use this constructor signature.

new OAuth2Authenticator(
    string clientId,
    string scope,
    Uri authorizeUrl,
    Uri redirectUrl,
    GetUsernameAsyncFunc getUsernameAsyncFunc = null,
    bool isUsingNativeUI = false)

• ClientId: the id of our app on the Facebook for Developers portal
• Scope: magic string telling which permission to grant on authentication
• AuthorizeUrl: Facebook’s URL required when authenticating
• RedirectUrl: custom url (doesn’t need to exist)
• GetUsernameAsyncFunc: we won’t be using it
• IsUsingNativeUI: flag to use the device’s web browser instead of an embedded webview. We won’t be using it.

Xamarin.Auth will query the AuthorizeUrl with our ClientId and Scope. Once the user is authenticated in his browser, Facebook will call our RedirectUrl with a bunch of parameters. Xamarin.Auth will catch this RedirectUrl and parse it.

The AuthorizeUrl should have the value “https://www.facebook.com/dialog/oauth/”, according to the Facebook documentation. The Scope we will use is “email”. You can find the one you need in the Facebook documentation.

If you need to use a specific version of the Facebook OAuth API, you can specify it in the URL (like this “https://www.facebook.com/v2.10/dialog/oauth/”). You can find the oldest version allowed on the Facebook for Developers portal, next to the App ID.

Here’s the result for my sample app:

_auth = new OAuth2Authenticator(
    "1919579418305741",
    "email",
    new Uri("https://www.facebook.com/dialog/oauth/"),
    new Uri("https://www.facebook.com/connect/login_success.html"));

The OAuth2Authenticator class comes with two events: Completed and Error
They’re quite simple to understand. The first one will call our handler when the authentication has completed (with the user authenticated or not) and the latter will allow us to react to an error (bad network, etc.)

_auth.Completed += OnAuthenticationCompleted;
_auth.Error += OnAuthenticationFailed;

When the authentication ends, OnAuthenticationCompleted is called and we can check if the user is authenticated and retrieve the precious OAuth token that we need to call other APIs.

private void OnAuthenticationCompleted(object sender, AuthenticatorCompletedEventArgs e)
{
    if (e.IsAuthenticated)
    {
        var token = new FacebookOAuthToken
        {
            AccessToken = e.Account.Properties["access_token"]
        };
        
        // Do something
    }
    else
    {
        // The user is not authenticated
    }
}

N.B.: FacebookOAuthToken is part of the sample.

That’s all for our Facebook implementation.

For a more detailed implementation, you can find the whole FacebookAuthenticator file used in the sample.

3. Retrieving the user’s email address

Now that we have our Access Token, we can simply call the Facebook Graph API to retrieve the user’s email address: https://graph.facebook.com/me?fields=email&access_token=[ACCESS_TOKEN]

As you can see, Facebook requires the access token as a query param instead of an HTTP Authorization header.

public async Task<string> GetEmailAsync(string accessToken)
{
    var httpClient = new HttpClient();
    
    var json = await httpClient.GetStringAsync(
        $"https://graph.facebook.com/me?fields=email&access_token={accessToken}");
    
    var email = JsonConvert.DeserializeObject<FacebookEmail>(json);
    
    return email.Email;
}

N.B.: FacebookEmail is also part of the sample.

And we’re done for the PCL part!

Implementing Facebook authentication in the Android project

1. Installing NuGet packages

This is the part where Facebook with Xamarin.Auth is way simpler to set up than Google. Facebook didn’t asked for our package name, so it is not a required part of the sample (of course, set up your app’s package name when going for production).

As we don’t use the IsUsingNativeUI flag, there’s no need to update the CustomTabs Support Library and set up redirection interceptors.

All we have to do here is to install the Xamarin.Auth package to our Android project. N.B.: In case you plan to integrate Google login to your app later, follow the Google post instead.

2. Running our project

All that is left is to run the authenticator. By calling GetUI and StartActivity, we will tell Xamarin.Auth to display a webview to let the users authenticate.

// "this" is the current activity
var intent = authenticator.GetUI(this);
StartActivity(intent);

In order to make it easier to reuse the FacebookAuthenticator class from the sample, I’ve extracted the ClientId and Scope in a configuration file that I’ve put into the PCL project. Here’s the configuration I’ll be using for both Android and iOS

public class Configuration
{
    public const string ClientId = "1919579418305741";
    public const string Scope = "email";
}

And we can finally integrate Facebook in our Android app.

[Activity (Label = "Xamarin_FacebookAuth.Android", MainLauncher = true, Icon = "@drawable/icon")]
public class MainActivity : Activity, IFacebookAuthenticationDelegate
{
    private FacebookAuthenticator _auth;
    
    protected override void OnCreate(Bundle bundle)
    {
        base.OnCreate(bundle);
        
        SetContentView(Resource.Layout.Main);
        
        _auth = new FacebookAuthenticator(
            Configuration.ClientId,
            Configuration.Scope,
            this);
            
        var facebookLoginButton =
            FindViewById<Button>(Resource.Id.facebookLoginButton);
            
        facebookLoginButton.Click += OnFacebookLoginButtonClicked;
    }
    
    private void OnFacebookLoginButtonClicked(object sender, EventArgs e)
    {
        // Display the activity handling the authentication
        var authenticator = _auth.GetAuthenticator();
        var intent = authenticator.GetUI(this);
        StartActivity(intent);
    }
    
    public async void OnAuthenticationCompleted(FacebookOAuthToken token)
    {
        // Retrieve the user's email address
        var facebookService = new FacebookService();
        var email = await facebookService.GetEmailAsync(token.AccessToken);
        
        // Display it on the UI
        var facebookButton =
            FindViewById<Button>(Resource.Id.facebookLoginButton);
            
        facebookButton.Text = $"Connected with {email}";
    }
    
    public void OnAuthenticationCanceled()
    {
        new AlertDialog.Builder(this)
            .SetTitle("Authentication canceled")
            .SetMessage("You didn't completed the authentication process")
            .Show();
    }
    
    public void OnAuthenticationFailed(string message, Exception exception)
    {
        new AlertDialog.Builder(this)
            .SetTitle(message)
            .SetMessage(exception?.ToString())
            .Show();
    }
}

Implementing Facebook authentication in the iOS project

1. Installing NuGet packages

Same as Android, just install the Xamarin.Auth package to our iOS project.

2. Running our project

Same as Android, we run the actual authenticator.

var viewController = authenticator.GetUI();
PresentViewController(viewController, true, null);

Also when you’re handling both Completed and Error events from the authenticator, you will need to manually call DismissViewController because Xamarin.Auth won’t dismiss the webview itself.

And we glue everything together, this time for iOS!

public partial class ViewController : UIViewController, IFacebookAuthenticationDelegate
{
    public ViewController(IntPtr handle)
        : base (handle) { }
        
    public override void ViewDidLoad()
    {
        base.ViewDidLoad();
        
        FacebookLoginButton.TouchUpInside += OnFacebookLoginButtonClicked;
    }
    
    private void OnFacebookLoginButtonClicked(object sender, EventArgs e)
    {
        var auth = new FacebookAuthenticator(
            Configuration.ClientId,
            Configuration.Scope,
            this);
            
        var authenticator = auth.GetAuthenticator();
        
        var viewController = authenticator.GetUI();
        
        PresentViewController(viewController, true, null);
    }
    
    public async void OnAuthenticationCompleted(FacebookOAuthToken token)
    {
        DismissViewController(true, null);
        
        var facebookService = new FacebookService();
        var email = await facebookService.GetEmailAsync(token.AccessToken);
        
        FacebookLoginButton.SetTitle( $"Connected with {email}", UIControlState.Normal);
    }
    
    public void OnAuthenticationFailed(string message, Exception exception)
    {
        DismissViewController(true, null);
        
        var alertController = new UIAlertController
        {
            Title = message,
            Message = exception?.ToString()
        };
        
        PresentViewController(alertController, true, null);
    }
    
    public void OnAuthenticationCanceled()
    {
        DismissViewController(true, null);
        
        var alertController = new UIAlertController
        {
            Title = "Authentication canceled"
            Message = "You didn't completed the authentication process"
        };
        
        PresentViewController(alertController, true, null);
    }
}

After quite a bit of struggle, I decided to share every single steps that led me to successfully implement authentication and getting the user’s email address.

In this post, I will focus on integrating Google authentication in your app.

If you’re eager to see some code, here is a sample app: https://github.com/TimLariviere/Sample-XamarinAuth-Google

Google authentication with Xamarin.Auth

Previously Google allowed the use of in-app webviews to handle the authentication flow, like what Facebook and Twitter do. But at the start of the year, Google changed its policy for native apps.

It now requires the use of native browsers through libraries (CustomTabs on Android and SFSafariViewController on iOS) Xamarin.Auth uses by default an in-app webview, but it also supports CustomTabs/SFSafariViewController by enabling the IsUsingNativeUI flag. While it is fully supported, it can be quite complex to compile and run successfully.

Configuring the Google Developer Console

Before coding, we first need to properly declare a new project in the Google Developer Console to get the identifiers required by Xamarin.Auth.

For that, go to https://console.developers.google.com

There, you will be able to create a new project.

Once it’s done, go to “Credentials” and configure the “OAuth consent screen”. You will need to set at least the “Product name shown to users”, otherwise Google won’t let you create keys for Android and iOS.

Now we need two OAuth client ID, one for each platform. The information needed differs from Android and iOS.

Let’s look at Android first.

• Name: It can be anything you want
• Signing-certificate fingerprint: the SHA-1 fingerprint of your keystore certificate that will sign your APK
• Package name: the package name of your app

You can find the signing-certificate fingerprint using the command shown.

You will need as many OAuth Client ID as you have Keystore files to sign your app (Debug, Production, etc.).

For iOS, it’s a little simpler.

• Name: It can be anything you want
• Bundle ID: the package name of your app
• App Store ID: the id of your app on the App Store
• Team ID: the id of your team on developer.apple.com

The last two fields are optional and allow you to retrict the usage of the OAuth Client ID to only your app.

Upon creation, Google will give you the client IDs that we need.

And that’s all for the Google Developer Console part. Let’s see how to actually implement Xamarin.Auth in a PCL library, shared by Android and iOS.

Implementing Google authentication in the PCL project

1. Installing the NuGet packages

First, we’ll need to add the Xamarin.Auth NuGet package to our PCL project. For this sample, I’ve downloaded the latest version on NuGet which is 1.5.0.3.

Then, as we plan on getting the user’s email address, we’ll need to call some REST APIs that will reply in JSON. Just add a reference to the latest Newtonsoft.Json package (10.0.3 at the time of writing).

2. Using Xamarin.Auth

As Google authentication is OAuth2, we will use the OAuth2Authenticator class provided by Xamarin.Auth. This class comes with several constructors but only one interests us.

new OAuth2Authenticator(
    string clientId,
    string clientSecret,
    string scope,
    Uri authorizeUrl,
    Uri redirectUrl,
    Uri accessTokenUrl,
    GetUsernameAsyncFunc getUsernameAsyncFunc = null,
    bool isUsingNativeUI = false);

• ClientId: the id that we’ve generated on Google Developer Console (Android/iOS)
• ClientSecret: not needed by Google
• Scope: magic string telling which permission to grant on authentication
• AuthorizeUrl/AccessTokenUrl: Google’s URLs required when authenticating
• RedirectUrl: custom url (doesn’t need to exist)
• GetUsernameAsyncFunc: we won’t be using it
• IsUsingNativeUI: the famous flag to enable in order to comply to Google’s new policy

Xamarin.Auth will query the AuthorizeUrl with our ClientId and Scope. Then, when the user will be authenticated in his web browser, Google will call our RedirectUrl with a bunch of parameters. Xamarin.Auth will catch this RedirectUrl (with our help, we’ll see that later) and parse it. Then it will call the AccessTokenUrl to get the actual token that will allow us to call APIs as the authenticated user.

AuthorizeUrl and AccessTokenUrl can be retrieved in the Google documentation. The Scope can be also retrieved in the Google documentation. Though we will use the “email” scope for our sample.

I’ve extracted the ClientId and RedirectUrl from the PCL project, as it will differ from Android and iOS.

Here’s the result for my sample app:

Auth = new OAuth2Authenticator(
    Configuration.ClientId,
    string.Empty,
    "email",
    new Uri("https://accounts.google.com/o/oauth2/v2/auth"),
    new Uri(Configuration.RedirectUrl),
    new Uri("https://www.googleapis.com/oauth2/v4/token"),
    isUsingNativeUI: true);

The OAuth2Authenticator class comes with two events: Completed and Error They’re quite simple to understand. The first one will call our handler when the authentication has completed (with the user authenticated or not) and the latter will allow us to react to an error (bad network, etc.)

Auth.Completed += OnAuthenticationCompleted;
Auth.Error += OnAuthenticationFailed;

When the authentication ends, OnAuthenticationCompleted is called and we can check if the user is authenticated and retrieve the precious OAuth token that we need to call other APIs.

private void OnAuthenticationCompleted(object sender, AuthenticatorCompletedEventArgs e)
{
    if (e.IsAuthenticated)
    {
        // The user is authenticated
        // Extract the OAuth token
        var token = new GoogleOAuthToken
        {
            TokenType = e.Account.Properties["token_type"],
            AccessToken = e.Account.Properties["access_token"]
        };
        
        // Do something
    }
    else
    {
        // The user is not authenticated
    }
}

N.B.: GoogleOAuthToken is part of the sample.

While Xamarin.Auth usually doesn’t need anything else to work, Google authentication is a bit more tricky because it uses NativeUI. Xamarin.Auth will not be able to react to the redirection to RedirectUrl made by Google. For that, we will need to intercept the redirection ourselves (inside the Android and iOS projects) and provide the URL to Xamarin.Auth in order for it to ends the authentication flow. That requires us to keep the OAuth2Authenticator instance somewhere. I usually stores it as a static field, and clean it when I’m done.

public static OAuth2Authenticator Auth;

That’s all for our Google implementation.

For a more detailed implementation, you can find the whole GoogleAuthenticator file used in the sample.

3. Retrieving the user’s email address

We have done the hardest part. Things are quite simple once we have the OAuth token.

There’s a Google REST API that allows us to retrieve the user’s email address: https://www.googleapis.com/userinfo/email?alt=json

public async Task<string> GetEmailAsync(string tokenType, string accessToken)
{
    var httpClient = new HttpClient();
    
    // Provide the OAuth token as an Authorization header
    httpClient.DefaultRequestHeaders.Authorization =
        new AuthenticationHeaderValue(tokenType, accessToken);
        
    // Query the API
    var json =
        await httpClient.GetStringAsync("https://www.googleapis.com/userinfo/email?alt=json");
    var email = JsonConvert.DeserializeObject<GoogleEmail>(json);
    return email.Data.Email;
}

N.B.: GoogleEmail is also part of the sample.

And we’re done for the PCL part!

Implementing Google authentication in the Android project

1. Setting the package name

First, make sure to set your package name properly. It needs to be the same as the one we declared for Android on the Google Developer Console. Here, I will set it to “com.woodenmoose.xamarin.googleauth”

AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest (...) package="com.woodenmoose.xamarin.googleauth">
    (...)
</manifest>

2. Installing the correct NuGet packages

The Xamarin.Auth package is required by the Android project as well, as we need it to actually run an activity using CustomTabs. Fortunately the CustomTabs Support library is a required dependency and will be installed automatically.

A bit of warning
If you continue and run the app now, you will end up with the following runtime exception:

System.MissingMethodException: Method 'Android.Support.CustomTabs.CustomTabsIntent.LaunchUrl' not found.

That’s because Xamarin.Auth with IsUsingNativeUI will rely on CustomTabsIntent.LaunchUrl, which is only present in v25 and beyond.

You’ll need to make sure that you have installed at least the version v25.1.0. For that, just update the Xamarin.Android.Support.CustomTabs package. The sample uses the latest version which is v25.4.0.2. (CustomTabs v23 comes with Support.v4 library which is not required anymore with v25, you can remove it if you want)

3. Intercepting the redirection

As I’ve said earlier, we need to intercept in place of Xamarin.Auth the redirection made by Google.

But first, we need to create that RedirectUrl. It can be anything you as long as it is a valid URL or respect the following scheme (protocol:/somedata). But as we don’t have control over the web browser, we need to make sure that Android warns us of the redirection.

For that, we will use deep linking. If our URL starts with our package name and the web browser tries to navigate to it, Android will launch our app, passing the URL as a parameter. The second part of the URL is just an identifier to differentiate other deep links that we may be using.

Here, our URL will be: “com.woodenmoose.xamarin.googleauth:/oauth2redirect”

Deep linking in Android requires an Activity with an IntentFilter.

[Activity(Label = "GoogleAuthInterceptor")]
[IntentFilter(actions: new[] { Intent.ActionView },
              Categories = new[] { Intent.CategoryDefault, Intent.CategoryBrowsable },
              DataSchemes = new[]
              {
                  // First part of the redirect url (Package name)
                  "com.woodenmoose.xamarin.googleauth"
              },
              DataPaths = new[]
              {
                  // Second part of the redirect url (Path)
                  "/oauth2redirect"
              })]
public class GoogleAuthInterceptor : Activity
{
    (...)
}

When the redirection happens, Android will create a new instance of the GoogleAuthInterceptor activity. In the OnCreate method, we can get the URL and pass it to our OAuth2Authenticator. Make sure to finish the activity as we don’t need it anymore.

protected override void OnCreate(Bundle savedInstanceState)
{
    base.OnCreate(savedInstanceState);
    
    Android.Net.Uri uri_android = Intent.Data;
    
    // Convert Android Url to C#/netxf/BCL System.Uri
    var uri_netfx = new Uri(uri_android.ToString());
    
    // Send the URI to the Authenticator for continuation
    MainActivity.Auth?.OnPageLoading(uri_netfx);
    
    Finish();
}

4. Running our project

The last step is to run the actual authenticator. This will launch the native web browser and initiates the authentication.

// "this" is the current activity
var intent = authenticator.GetUI(this);
StartActivity(intent);

All that is left is to glue together all the pieces to make the Google authentication works on Android and retrieve the user’s email address

Configuration.cs

public static class Configuration
{
    public const string ClientId = 
        "723962257721-ql0tki3si3s22l1lsovimivkmnrfm6rr.apps.googleusercontent.com";
        
    public const string Scope = "email";
    
    public const string RedirectUrl =
        "com.woodenmoose.xamarin.googleauth:/oauth2redirect";
}

MainActivity.cs

[Activity(Label = "Xamarin_GoogleAuth", MainLauncher = true, Icon = "@drawable/icon")]
public class MainActivity : Activity, IGoogleAuthenticationDelegate
{
    // Need to be static because we need to access it
    // in GoogleAuthInterceptor for continuation
    public static GoogleAuthenticator Auth;
    
    protected override void OnCreate(Bundle bundle)
    {
        base.OnCreate(bundle);
        
        SetContentView(Resource.Layout.Main);
        
        Auth = new GoogleAuthenticator(
            Configuration.ClientId,
            Configuration.Scope,
            Configuration.RedirectUrl,
            this); // Completed/Error events
            
        var googleLoginButton =
            FindViewById<Button>(Resource.Id.googleLoginButton);
            
        googleLoginButton.Click += OnGoogleLoginButtonClicked;
    }
    
    private void OnGoogleLoginButtonClicked(object sender, EventArgs e)
    {
        // Display the activity handling the authentication
        var authenticator = Auth.GetAuthenticator();
        var intent = authenticator.GetUI(this);
        StartActivity(intent);
    }
    
    public async void OnAuthenticationCompleted(GoogleOAuthToken token)
    {
        // Retrieve the user's email address
        var googleService = new GoogleService();
        var email =
            await googleService.GetEmailAsync(
                token.TokenType,
                token.AccessToken);
                
        // Display it on the UI
        var googleButton =
            FindViewById<Button>(Resource.Id.googleLoginButton);
        
        googleButton.Text = $"Connected with {email}";
    }

    public void OnAuthenticationFailed(string message, Exception exception)
    {
        new AlertDialog.Builder(this)
            .SetTitle(message)
            .SetMessage(exception?.ToString())
            .Show();
    }
}

N.B.: GoogleAuthenticator is a PCL wrapper for OAuth2Authenticator that you can find in the sample.

Implementing Google authentication in the iOS project

1. Setting the package name

First, make sure to set your package name properly. It needs to be the same as the one we declared for iOS on the Google Developer Console. Here, I will set it to “com.woodenmoose.xamarin.googleauth”

Info.plist

<key>CFBundleIdentifier</key>
<string>com.woodenmoose.xamarin.googleauth</string>

2. Installing NuGet packages

Unlike Android, it can be done in a single step. Just install the Xamarin.Auth package in the iOS project.

3. Intercepting the redirection

Just like Android, we will set up deep linking.

For that, we need to declare a URL type in the Info.plist file. We only have to declare our package name as a potential URL scheme that will launch our app.

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>Google Auth</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>com.woodenmoose.xamarin.googleauth</string>
        </array>
        <key>CFBundleURLTypes</key>
        <string>Viewer</string>
    </dict>
</array>

Or with the editor of Visual Studio:

Then every time Safari tries to navigate to a URL like “com.woodenmoose.xamarin.googleauth:/”, it will run our app and call the OpenUrl method of the AppDelegate class. Like we’ve done on Android, get the URL and pass it to our authenticator.

public override bool OpenUrl(
    UIApplication application, 
    NSUrl url, 
    string sourceApplication, 
    NSObject annotation)
{
    // Convert iOS NSUrl to C#/netxf/BCL System.Uri
    var uri_netfx = new Uri(url.AbsoluteString);
    AuthViewController.Auth?.OnPageLoading(uri_netfx);
    
    return true;
}

4. Running our project

The last step is to run the actual authenticator. This will launch the native web browser and initiates the authentication.

var viewController = authenticator.GetUI();
PresentViewController(viewController, true, null);

Also when you’re handling both Completed and Error events from the authenticator, you will need to manually call DismissViewController because the SFSafariViewController doesn’t dismiss itself.

And we glue everything together, this time for iOS!

Configuration.cs

public static class Configuration
{
    public const string ClientId = 
        "723962257721-lcjvps5ag42butfd44tojo01cuj85d8t.apps.googleusercontent.com";
        
    public const string Scope = "email";
    
    public const string RedirectUrl =
        "com.woodenmoose.xamarin.googleauth:/oauth2redirect";
}

AuthViewController.cs

public partial class AuthViewController : UIViewController, IGoogleAuthenticationDelegate
{
    public static GoogleAuthenticator Auth;
    
    public AuthViewController (IntPtr handle)
        : base (handle) { }
        
    public override void ViewDidLoad()
    {
        base.ViewDidLoad();
        
        Auth = new GoogleAuthenticator(
            Configuration.ClientId,
            Configuration.Scope,
            Configuration.RedirectUrl,
            this); // Completed/Error events
            
        GoogleLoginButton.TouchUpInside += OnGoogleLoginButtonClicked;
    }
    
    private void OnGoogleLoginButtonClicked(object sender, EventArgs e)
    {
        var authenticator = Auth.GetAuthenticator();
        var viewController = authenticator.GetUI();
        PresentViewController(viewController, true, null);
    }
    
    public async void OnAuthenticationCompleted(
        GoogleOAuthToken token)
    {
        // SFSafariViewController doesn't dismiss itself
        DismissViewController(true, null);
        
        var googleService = new GoogleService();
        var email =
            await googleService.GetEmailAsync(
                token.TokenType,
                token.AccessToken);
                
        GoogleLoginButton.SetTitle($"Connected with {email}", UIControlState.Normal);
    }
    
    public void OnAuthenticationFailed(string message, Exception exception)
    {
        // SFSafariViewController doesn't dismiss itself
        DismissViewController(true, null);
        
        var alertController = new UIAlertController
        { 
            Title = message, 
            Message = exception?.ToString()
        };
        
        PresentViewController(alertController, true, null);
    }
}

And that concludes this really lengthy post. Hope it helps.

In part 1, we saw what possibilities in terms of hardware are available when developing for iOS with Xamarin (if you missed it, it’s still time to read it).

Today, I will explain how to leverage a single Mac for a small team, and how to enable simultaneous debugging between developers. This post is applicable to every Mac machines. A good candidate for such a setup would be either a Mac mini or a Mac Pro.

I won’t go into details about developer certificates and provisioning profiles.

Contents:

• The Mac Side
  1. Prerequisites
  2. Create the accounts
  3. Enable remote access
• The Developer Side
  1. Prerequisites
  2. Remote access and configuring Xcode
  3. Configuring Visual Studio
  4. Building, debugging, and simulating for iOS
• Limitations
• Conclusion

The Mac Side

Prerequisites

Before we start, make sure you have the following already set up.

• A Mac, with the latest OS if possible. (at the time of writing: macOS Sierra)
• Xcode installed (at the time of writing: Xcode 8.2.1)
• Xamarin Studio/Visual Studio for Mac installed

You won’t have to install all these softwares on each account as they will be globally available. And lastly, the Mac should be connected to your network and be reachable by any of your team mates.

Create the accounts

The first step to allow several developers to use the Mac simultaneously, to build and debug on both simulator and real devices, is to create each of them an account on the Mac. We can achieve that by manually creating those accounts or automate their creation by connecting the Mac to an Active Directory.

Both solutions take place in the “Users & Groups” section of System Preferences.

If you’re manually creating the account, just add a standard account. Like this:

Repeat that step for each of your team mates and you’re done.

If you decide to let an Active Directory manage the accounts, you can join it in the “Login Options” tab. Click the “Join…” button of Network Account Server. To complete this step, you will need to have the login and password of one of the AD administrators.

Note: macOS is currently not able to join an Azure Active Directory. If you’d like such feature, vote for it on feedback.azure.com.

Make sure the “Allow network users to log in at login window” is ticked on. That way, anytime a new AD user connects to the Mac, his account will be automatically created.

Enable remote access

Now that we have created every accounts (or that we delegated their creation), we need to allow the users to connect to the Mac both through Visual Studio’s Xamarin Mac Agent and VNC.

The former requires us to activate the “Remote Login” service that allows for ssh access. To do that, we need to go to the “Sharing” section of System Preferences and tick on “Remote Login”. Make sure “Allow access for all users” is also ticked on (“Only these users” is also a valid option, as long as you add every of your team members’ accounts).

In order to allow developers to access the Mac and configure their Xcode with an Apple Developer account so that they can download provisioning profile, we need to put a remote desktop service in place. OS X has a really great feature for this: it can natively be a VNC server without anything to install.

We can activate this feature by going in the “Sharing” section of System Preferences. There, just turn on the “Screen Sharing” service and allow access for all users (again use “Only these users” if you want).

Now whenever someone wants to access the Mac through a VNC client, he will be asked of his credentials. When done, he will access his own account.

OS X is capable of handling several sessions running simultaneously when using VNC, so each developer can use it independently.

And that’s all for the global configuration part! Now we’ll see how each developer needs to configure his Mac account and Visual Studio so that he can build and debug iOS apps directly from Visual Studio.

The Developer Side

Prerequisites

I will only talk about Visual Studio on Windows. So here’s the prerequisites :

• Visual Studio 2015/2017 installed
• Xamarin for Visual Studio installed
• VNC client (like RealVNC)

The computer needs to have access to the same network as the Mac, and be able to communicate with it.

Remote access and configuring Xcode

Before doing anything, we should connect to the Mac via VNC. The important part here is to use your own account to access it so that it will open your own session.

If you have set up an Active Directory, it will be at the time of the first connection that the account will be created.

Now is a good time to configure Xcode to use your Apple developer account and download any provisioning profile that you will need. The Xamarin.iOS compiler (and by extension Visual Studio) will rely on those configurations to actually build your app.

You’re also free to do whatever you want on the Mac. You could, for example, install git and clone your repository. That way, you could make your storyboards directly on the Xcode designer!

Remember, you’re on your own session with its own home directory!

A warning though: VNC can be quite sluggish so it can be a little frustrating to work through remote access.

Configuring Visual Studio

Lastly, we need to configure Visual Studio. This part is simple. Xamarin also helps you with a tutorial right inside Visual Studio.

With a Xamarin.iOS project loaded, you will be able to access the Xamarin Remote Agent icon.

Click on it and just search for the Mac, either by its name or by its IP address.

To connect, Visual Studio will ask for the credentials to use. It’s important to give your own credentials! That way, it will connect to your session to build and debug. It’s the key to allow several developers to debug at the same time.

Visual Studio will be able to connect only if your session is currently running, so remember to log in through VNC beforehand. Otherwise you will end up with the following console output:

Starting connection to Mac mcnmac002.local....
The user must be logged in on the Mac in order to execute an SSH command.
Disconnected from the Mac mcnmac002.local.

This will be true every time you start Visual Studio and try to build/debug a Xamarin.iOS app.

Building, debugging and simulating for iOS

And that’s it for the Developer side! You can now build, debug, and use the simulator simultaneously on a single Mac.

If you want to deploy on a real device, you will still need to plug it into one of the Mac’s USB ports. Xamarin has announced some time ago an iOS USB Remoting feature, but as of the time of writing, we’re still waiting for it.

Make sure to try out the Remote iOS Simulator for Visual Studio! It will be a little easier to use than the iOS Simulator on the Mac through VNC.

Limitations

There’s some drawbacks when using this setup.

• You will need a slightly more powerful machine, compared to when you have your own Mac, as it will need to handle remote access and simultaneous build/debug/simulators.
• Disk space will quickly vanish due to how Xamarin Studio works (huge caches per user, Android SDK installed once per user by default).
• Remote builds are noticeably longer than direct builds
• The Visual Studio’s Mac Remote Agent needs a running session on the Mac, and it can be quite erratic (this was especially true some months back on VS2015)
• Remote access with VNC is not optimal.
  • There could be some delay for the screen to refresh.
  • Even worse, if there’s no screen plugged in the Mac, VNC will only stream a resolution of 640x480. Huge black rectangles will appear on the screen making it near unusable. I recently bought a small HDMI plug that emulates the presence of a screen (you can find it here on Amazon) and it solved those issues (1080p stream, no black rectangle).

Conclusion

Despite the length of this post, we saw that configuring a Mac to allow several developers to work it simultaneously is quite simple and straightforward. It even works remarkably well!

It can be a good solution if you’re low on budget or the number of iOS projects don’t justify the cost of buying every single developer a Mac. But if you can, prefer to equip everyone of your team mates with a MacBook Pro or equivalent. It will spare you a lot of misadventures.

In this post, I will explain how to leverage Azure Active Directory to protect our WebAPI without any code, and how to call this WebAPI from our mobile apps.

So, how do we do that?

In order, we will :

1. Enable Azure AD authentication on our API
2. Declare our apps in the Azure AD in order to allow them to authenticate their users and give them access to our API
3. Implement ADAL.NET in our apps to authenticate the user and retrieve an access token for our API
4. Call our API with the access token
5. ???
6. Profit

Before we begin

For this post, I will use the default ASP.NET Core WebAPI that I will host in an Azure App Service. The mobile apps will be made with Xamarin.iOS, Xamarin.Android and UWP, core logic will be implemented inside a .NETStandard 1.4 project.

I made a sample containing the WebAPI and the mobile apps, it’s available on Github : https://github.com/TimLariviere/WoodenMoose.Samples.Xamarin_Authentication

If you want to run the sample, you will need to have an active Azure subscription with an Azure Active Directory. Then you will need to declare your apps in the Azure AD like we will see in this post.

Configuring Azure AD for the WebAPI

Before we can do anything with Xamarin or UWP, we need to set up our WebAPI and configure the authentication against Azure Active Directory. This used to require lots of setup code in our WebAPI in order to allow only authenticated requests, most of the times specific to only one identity provider. Well, this time Azure really make it easy on us with a “turn key” feature that require no code at all!

I have already created an Azure App Service named “woodenmoose-authsample-api” and published in it an ASP.NET Core WebAPI, generated from the default template.

To enable authentication with Azure AD, I just need to go into the “Authentication / Authorization” panel, turn the feature on and configure it to create a new Azure AD app representing my WebAPI. Like this :

That’s it! As promised, we protected the WebAPI with no code whatsoever, as you can see when asking for the Index action of the ValuesController.

Configuring Azure AD for the mobile apps

Our API is now protected by Azure AD and we can authenticate ourselves directly in the browser, but our mobile apps aren’t ready yet to query the API. This is because Azure AD won’t issue access tokens to unknown clients.

So there’s a little more configuration to do.

First, we’ll create a new native app entry into the Azure AD apps registry. I have named it “woodenmoose-authsample-mobileapp”.

The RedirectUri will be used in the mobile apps to notify the success of the authentication. It can be any URI that you want. But if you’re going for multitenancy authentication, Azure requires you follow a specific pattern : https://yourtenantname.com/what_you_want

I have set the value to “https://mcnext.com/woodenmoose-authsample-mobileapp”

Next, we’ll need to allow users connected to woodenmoose-authsample-mobileapp to access the web API. For this, we have the “Required permissions” panel in the native app entry. In it, we will select the api entry from the Azure AD.

Like this :

And then, we set the permission needed. In our case, simply “Access woodenmoose-authsample-api”.

And finally, the last step in configuring Azure AD is to tell our api registration that if our native app registration want to issue a token to access the API, it’s ok.

So we have to change our api registration and fill the “knownClientApplications” array in the manifest with the ApplicationId of our native app registration.

We have to use the manifest, because there’s no other interface that will allow us to do so.

And that’s it for the configuration! You’re still there? Great, because now we’re finally going to write some code!

Implementing ADAL.NET

Now that all the configuration part on Azure is done, we can implement the authentication process in our apps before we can make a call to our API. For that, we will use ADAL.NET (standing for Active Directory Authentication Library for dotNET) which is compatible with our 3 platforms.

ADAL.NET will take care of everything. It will display a screen where the user will log in, handle every error cases (wrong account, wrong password, account disabled, etc.) and it will handle the OAuth process. At the end, you receive the access token that you need to query the API. Really simple!

So, to use ADAL.NET we need to add to our core library the nuget package “Microsoft.IdentityModel.Clients.ActiveDirectory” (version 3.13.8 at the time of writing)

A few tips so NuGet will accept to install ADAL :

• If you’re making a PCL project, you’ll need to target the PCL Profile 7 (see image below for which platforms to select)
• If you’re making a .NETStandard project, you’ll need to target at least .NET Standard 1.4

The reason is that the ADAL package is only compatible with those versions.

Here are the required platforms if you’re making a PCL.

Once ADAL installed, we have access to the AuthenticationContext class. With it, we can ask for the user to log in.

public class AuthenticationManager
{
    private string _authority;
    private string _resource;
    private string _clientId;
    private Uri _redirectUri;
    private static IPlatformParameters _platformParameters;
    private string _accessToken;
    
    public async Task LoginAsync()
    {
        var authContext = new AuthenticationContext(_authority);
        var authResult =
            await authContext.AcquireTokenAsync(
                _resource, _clientId, _redirectUri, _platformParameters);
                
        var connectedUser = authResult.UserInfo;
        _accessToken = authResult.AccessToken;
    }
    
    public static void SetParameters(IPlatformParameters platformParameters)
    {
        _platformParameters = platformParameters;
    }
}

Our LoginAsync method needs some parameters, let me explain them :

For the Resource parameter, it seems that some Azure AD will accept that you give an URI (App ID) instead of a Guid. But I recommend that you give the Guid anyway so there won’t be any surprises.

So for my case, I’ll use those values

• Authority = https://login.windows.net/mcnext.com/
• Resource = c21a38b2-54bb-4027-b5e4-257f7d10f3f9
• ClientId = 150526ad-75ee-44d5-a6e1-091ef0900d77
• RedirectUri = https://mcnext.com/woodenmoose-authsample-mobileapp

We are still missing the PlatformParameters instance for ADAL.NET to work. Instanciating PlatformParameters is different for each platform so we will see how to do so for iOS, Android, and UWP.

Implementing iOS

The first step (after adding a reference to our core project) is to add a reference to the NuGet package “Microsoft.IdentityModel.Clients.ActiveDirectory” like in our core projet. The reason is that this package will come with a platform specific DLL (for instance Microsoft.IdentityModel.Clients.ActiveDirectory.Platform) which contains the iOS implementation of the IPlatformParameters interface.

Then all that remains is to give our core project an instance of the iOS PlatformParameters

public partial class MainViewController : UIViewController
{
    public override void ViewDidLoad()
    {
        var platformParameters = new PlatformParameters(this);
        AuthenticationManager.SetParameters(platformParameters);
    }
}

ADAL.NET requires that you give it the instance of the currently displayed UIViewController, so it can resume our application once the authentication is complete. And we’re done for iOS.

Implementing Android

Android is mostly the same as iOS, to a slight exception. We need to reference the NuGet package “Microsoft.IdentityModel.Clients.ActiveDirectory”.

And we need to pass our Android implementation of PlatformParameters the instance of our currently displayed Activity.

public class MainActivity : Activity
{
    protected override void OnCreate(Bundle bundle)
    {
        var platformParameters = new PlatformParameters(this);
        AuthenticationManager.SetParameters(platformParameters);
    }
    
    protected override void OnActivityResult(
        int requestCode, Result resultCode, Intent data)
    {
        base.OnActivityResult(requestCode, resultCode, data);
        
        AuthenticationAgentContinuationHelper
            .SetAuthenticationAgentContinuationEventArgs(requestCode, resultCode, data);
    }
}

Notice that I have overridden the OnActivityResult method. AuthenticationAgentContinuationHelper.SetAuthenticationAgentContinuationEventArgs needs to be called on OnActivityResult, otherwise ADAL.NET will not be able to resume our application on authentication success.

Implementing UWP

Like iOS and Android, UWP needs to reference the NuGet Package “Microsoft.IdentityModel.Clients.ActiveDirectory”. If you try to build now, you may notice that the build fails. Just update your “Microsoft.NETCore.UniversalWindowsPlatform” package to version 5.2.2 minimum.

Unlike iOS and Android, UWP doesn’t need to access the currently displayed Window. So instead, we can just set up our PlatformParameters in the App.xaml.cs file.

public partial class App : Application
{
    public App()
    {
        this.InitializeComponent();
        this.Suspending += OnSuspending;
        
        var platformParameters = new PlatformParameters(PromptBehavior.Auto, false);
        AuthenticationManager.SetParameters(platformParameters);
    }
}

What about Xamarin.Forms?

Well, it works the same way as we saw for iOS, Android, and UWP. The only thing that differ is how to retrieve the current UIViewController and Activity. See the blog post from Xamarin “Put Some Azure Active Directory in Xamarin.Forms” for more information.

Calling the API

Now that we finally have the access token, we can use it with HttpClient. To use it, we just have to set the Authorization header.

Like this:

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", _accessToken);

var result =
    await client.GetAsync(new Uri("https://woodenmoose-authsample-api.azurewebsites.net/api/values"));

That way, Azure AD will allow our request to be answered by our WebAPI.

Conclusion

Setting up authentication and authorization can be quite a challenge, but ADAL and Azure Active Directory simplified it for us, especially since we’re targeting 3 different platforms. Of course, we only saw the bare minimum. ADAL.NET has plenty more features to help you deliver secured and easy to use apps like token cache, refresh session, and so on. See the ADAL.NET GitHub for more information : https://github.com/AzureAD/azure-activedirectory-library-for-dotnet

Also I have made a sample on Github demonstrating everything I showed in this post : https://github.com/TimLariviere/WoodenMoose.Samples.Xamarin_Authentication

Happy coding!

• This post is only about Visual Studio 2015. In Visual Studio 2017, you can find the option “Hide from Solution Explorer” in the context menu.
• Also this post is only about xproj-based projects. It applies to .NET Core libs and apps like ASP.NET Core. The next version of .NET Core (2.0) will revert back to csproj files.

Unlike csproj-based projects where files need to be referenced in the csproj, with xproj-based projects Visual Studio will list by default every files in the project folder in the Solution Explorer.

To avoid cluttering your Solution Explorer with unneeded files, you will need to edit the xproj file to add files or folders to exclude.

Here the available options :

A limitation with these tags is that there no pattern available. It needs to be a specific file or folder name.

These tags needs to be written inside an ItemGroup tag which in turn need to be put inside the Project root of the xproj file. Like this :

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <DnxInvisibleContent Include="nuget.exe" />
        <DnxInvisibleFolder Include="node\_modules" />
    </ItemGroup>
</Project>