DEV Community: Mike James

WPF App Modernisation: A Pragmatic Approach

Mike James — Fri, 13 Oct 2023 08:37:55 +0000

In the world of desktop application development, continuity and stability often trump the allure of new frameworks. Notably, 58% of professional desktop developers stick with the familiar, avoiding radical changes to their applications. The predominant drive is maintaining or modernising applications within the familiar confines of their existing UI technologies. This preference is not without merit; developers find comfort in the known, and a lower developmental cost comes with familiarity. Rewriting an application is a significant financial and operational risk.

Cross-Platform UI Toolkits

That's not to say some teams aren't seriously considering their modernisation strategy. While WPF is stable and proven, it is limited to Windows at a time when more and more applications need to run on various operating systems and form factors. Before Avalonia XPF, WPF developers had limited options. One option would be to migrate to a cross-platform UI toolkit, such as Avalonia, Qt or Flutter, with the best-case scenario enabling some code reuse and the worst case requiring a complete application rewrite.

Web

The alternative to a cross-platform UI toolkit has been embracing Web technologies, whether Electron or moving to the cloud. It's hard to ignore the allure of web technology's ease of deployment, albeit at the potential expense of performance and productivity.

Why modernise

With so many mission-critical WPF applications in active development, the discussion of modernisation is buzzing. Why the discourse on modernisation, you ask? The answer is twofold: new platforms equate to an expanded target market and a resilient, future-proof application portfolio. The pathway to modernisation, however, is a strategic decision. Rewriting is an expensive endeavour, irrespective of the technology chosen. The crossroads broadly split into native cross-platform (embodied by Flutter, QT, Avalonia, etc...) or the web. Amongst the native cross-platform contenders, Avalonia emerges as the frontrunner in facilitating code reuse, a significant cost and time efficiency advantage. That isn't to say that Avalonia (our open-source, cross-platform UI toolkit) doesn't require some changes to your WPF app. It's WPF-inspired but not binary-compatible.

Avalonia XPF

If you need WPF binary compatibility, then Avalonia XPF has emerged as a solution to modernisation. It offers a path to new platforms without necessitating a seismic shift and rewriting existing applications. We typically see customers running their complex WPF application on new platforms within only a few hours of receiving a trial license! The attraction towards Avalonia XPF stems from a pragmatic standpoint; it's a fast and affordable conduit to broader market reach without the enormous risk of rewriting applications from scratch in a different technology.

Avalonia XPF shines distinctly, enabling full reuse of existing WPF code and 3rd party controls while providing performance improvements and new platforms. It's a proposition of extending the life and reach of your applications without a daunting overhaul.

There isn't a one-size-fits-all answer to app modernisation. It's a journey tailored to individual applications and a team's long-term vision. Engaging in a dialogue on modernisation, understanding the nuances and making informed decisions is the essence of staying ahead. We at Avalonia are at the helm to discuss, advise, and help you navigate the modernisation maze.

Next Steps

If you'd like to test your WPF applications on macOS or Linux, then sign up for a 30-day trial of Avalonia XPF.

Remember to download our XPF Sample app, FamilyShow. The classic WPF sample app is now available on macOS and Linux!

Introducing Avalonia XPF Trials and the Startup License

Mike James — Thu, 27 Jul 2023 11:00:09 +0000

At Avalonia, we embarked on the ambition project of Avalonia XPF with the aim of extending the reach of Windows Presentation Foundation (WPF) to a broader range of platforms. Today, as we witness numerous companies finding success with Avalonia XPF, we are proud of the progress we’ve made. The fruits of our labor are visible, and we’re thrilled to announce that we’re being XPF Trials and added a license specifically targeting small businesses.

Avalonia XPF Trials

After rigorous testing and refinement over many months with a select group of companies, we are now ready to extend Avalonia XPF trials to the broader community. Avalonia XPF has seen exponential improvements since the start of the year. We are now proudly supporting a significant proportion of major WPF control vendors. Collaborations with esteemed vendors like Actipro and SciChart are enabling us to ensure that controls function seamlessly across all supported platforms.

This exciting expansion of our testing phase is organized into four straightforward steps to ensure a seamless onboarding experience.

Step 1:
Users interested in exploring the potential of Avalonia XPF can apply for a trial through our website.

Step 2:
Our team will set up a short initial call to verify the compatibility of the user's app, discuss timelines, and understand specific requirements. This step allows us to personalize your trial experience.

Step 3:
Once we've established the app’s suitability and your readiness, we help set you up with the Avalonia XPF trial. Our dedicated team is on standby to assist should any issues arise while using Avalonia XPF.

Step 4:
After a successful trial, users can purchase a license to officially bring their WPF application to macOS and Linux, opening up their products to a significantly wider user base.

Startup License

The launch of Avalonia XPF trials signifies a new phase in our journey. But we're not stopping there. We've always aimed to make Avalonia's robust solutions accessible to a diverse range of developers and businesses, which is why we are thrilled to introduce the new Startup license.

Our initial vision for Avalonia XPF was to offer large enterprises a way to conserve valuable resources while extending their application's reach. We wanted to help companies save months, or even years, of work rewriting applications. To our delight, we found that the appeal of Avalonia XPF extended beyond large corporations. Many smaller companies have also expressed a keen interest in our technology. To accommodate these smaller companies and startups, we're offering an Startup license.

With significantly reduced costs, the Startup license is designed for companies with no more than five employees and annual revenues not exceeding 1 million USD. This license, while highly affordable, includes up to ten support tickets per year. We are confident that the Startup license will enable many more businesses to experience the transformative benefits of Avalonia XPF.

With Avalonia XPF and the introduction of the Startup license, we're not just expanding platforms and licensing options; we're expanding horizons, possibilities, and opportunities. We believe that with the right tools, developers and companies, regardless of their size, can build upon their existing WPF investments and increase their reach.

If you have a WPF application and are interested in exploring what Avalonia XPF can do for you, we would love to hear from you. Reach out to us, and let's embark on this exciting journey together.

To the future of WPF, we say: the future is here, the future is Avalonia XPF.

Avalonia for Visual Studio Code (Early Access)

Mike James — Thu, 27 Jul 2023 07:09:15 +0000

Two weeks ago we showed a sneak peak of Avalonia for Visual Studio Code. The extension will significantly enhance the Avalonia development experience in Visual Studio Code. It features our XAML code completion and integrated XAML previewer, making it easier than ever to build beautiful Avalonia apps.

Today, we are excited to invite you, the sponsors and the members of OpenCollective to try the (extremely) early build of the extension!

Please sign up for the early access here, we will start sending out instructions from the 27th of July.

What’s in the extension?

The extension aims to bring the most common workflows for Avalonia developers. However, the preview will enable the two most common scenarios to kick off the support for VSCode

Integrated XAML Previewer

The Avalonia XAML Previewer is a powerful tool that allows you to visualise XAML code in real-time. It enables you to efficiently design and fine-tune user interfaces, helping to identify potential issues and visualise the impact of changes instantly.

XAML Code completion

The Avalonia XAML in the VS Code is powered by the same code completion engine available for Visual Studio on Windows.

Rich syntax highlighter and contextual code complete will make it lot easier to read and write XAML files

Feedback

Please share your suggestions, feature requests and report issues for the extension through VS Code’s Help > Report Issue dialog

You can follow all the suggestions and issues the extension here.

Welcome to the New Era of App Development: Introducing Avalonia v11

Mike James — Wed, 05 Jul 2023 10:26:52 +0000

Today, we are thrilled to announce the release of Avalonia 11.0!

After nearly a year in preview and countless thousands of hours of dedication, it is time to unleash a game-changer in cross-platform application development. Avalonia v11 embodies a huge leap forward in our goal to provide developers with an efficient, feature-rich, and seamless experience to create exceptional UIs across all major platforms.

What makes Avalonia v11 a milestone in our journey? Here's a peek into the wealth of features we have packed into this revolutionary version:

Broadened Horizons with New Platforms

The broadened platform support is one of the most significant updates in v11. With this release, we've included iOS, Android, and WebAssembly support, taking our cross-platform capabilities to new horizons.

Looking to the future, we’ve also previewed support for Apple's visionOS and seen our incredible community work to enable Avalonia UI on Samsung's TizenOS! Our unique architecture enables us to add new platforms with ease, which we wrote about last year.

New Composition Renderer

Our new composition renderer is a significant advancement in visual capability and performance. At its core, the composition renderer brings new animation possibilities to the table. With support for implicit animations, connected animations and render thread animations, the visual dynamism of your application can reach new heights. These features allow for smooth, high-performance animations that can enrich your user interfaces and provide engaging user experiences.

Beyond the animation enhancements, the composition renderer provides substantial performance improvements. It’s designed to be highly efficient, reducing memory pressure and enabling high frame rates even on low-powered embedded devices. A testament to Avalonia's efficiency is its widespread use in embedded systems. Our architecture enables delivering a seamless user experience, even when operating on 20-year-old embedded CPUs. This level of performance optimization is rare, demonstrating Avalonia's ability to adapt to diverse hardware configurations while maintaining smooth, responsive applications.

Advanced Text Rendering and Layout

Avalonia v11 ushers in a new era of text rendering capabilities, significantly enhancing control and flexibility over the visual elements in your UI. We’ve introduced rich text rendering that supports inline elements. This feature allows for dramatic variations in a single TextBlock, from changing font styles to adding hyperlinks, or even embedding controls - something that wasn’t previously achievable.

These improvements and capabilities set the foundation for full rich text editing, a feature we’re excited to explore in the upcoming versions of Avalonia.

IME Support

Our commitment to global reach and inclusivity has led to the introduction of Input Method Editor (IME) support in v11. This vital feature assists users in entering characters and symbols not found on their input devices. IME support also enables seamless integration with on-screen keyboards on mobile and web platforms. This means that Avalonia apps now play nicely with features such as auto-completions and other OS provided text features. As a result, Avalonia apps are become even more user-friendly and adaptable to a range of input methods.

Accessibility Support

We believe that technology should be inclusive and accessible to all. Therefore, we're excited to introduce our new accessibility support, which ensures that Avalonia applications can be used and enjoyed by everyone, including those with disabilities.

We've laid the groundwork for full accessibility support, implementing critical features that make apps more accessible to users with visual, motor, or cognitive disabilities. These enhancements comply with industry standards and guidelines, making Avalonia a more attractive choice for developers concerned with building accessible software.

We've made strides in keyboard navigation, screen reader support, and high-contrast themes. And while we're proud of our progress, we consider this to be just the beginning. We're committed to continuously improving the accessibility of Avalonia, making it easier for everyone to use the applications built with our framework.

Automated Testing

We’ve overhauled our automated testing capabilities to ensure you can develop robust and reliable applications with ease. This release introduces support for automated testing that extends beyond the Avalonia test environment to include traditional testing frameworks like Appium. With v11, you can take advantage of the testing tools you’re already familiar with to ensure your application runs flawlessly across platforms.

But the enhancements to our testing capabilities go even further. With the introduction of a ‘Headless’ mode, you can run your entire application and execute tests on it at incredibly high speed. This headless mode streamlines the testing process, enabling you to validate functionality and detect bugs more efficiently than ever before. This is a monumental leap forward in our testing capabilities, and we believe it will dramatically improve your development workflow.

Control Themes

One of the notable enhancements in v11 is the significant improvements made to our control themes. While we've always prided ourselves on the customizability offered by Avalonia, in this version, we've taken it a step further to provide developers with even more flexibility and control over the look and feel of their applications.

Control themes in v11 have been restructured for easier customization, which is particularly beneficial if you have a precise, consistent visual identity you'd like to maintain across your applications. This ease of customization also increases efficiency, enabling you to achieve the desired aesthetic with less time and effort.

Additionally, we've improved our support for theme switching, allowing your users to switch between light and dark modes or other custom themes you provide seamlessly and dynamically.

AOT & Trimming

We're excited to announce that v11 fully supports Ahead-of-Time (AOT) compilation and trimming, resolving issues from previous versions. The updated trimming functionality eliminates unused code during the publishing process, dramatically reducing application sizes. With v11, developers can now experience ~60% smaller application sizes, providing faster downloads, quicker startup times, and less end-user storage used.

Revamped Developer Documentation

Your feedback has been invaluable, and we’ve heard you loud and clear about improving our documentation! We’re thrilled to reveal that we’ve transitioned our documentation from GitBook to a new custom platform that aligns more precisely with our evolving needs.

This significant step forward offers us enormous flexibility for future enhancements. The goal is to continually adopt and refine the documentation to better serve our expanding community.

We’ve also worked on creating quick-guides, which are focused example applications that demonstrate specific functionalities.

We hope to see more participation from the community to help us improve documentation. This doesn’t necessarily mean writing documentation yourself - although that would be welcome. Equally important is sharing your experiences. Tell us about the areas where you encountered hurdles, or where our current documentation fell short in supporting your journey. This kind of feedback is immensely valuable and helps us understand where to focus our improvement efforts. Every contribution, whether big or small, goes a long way in refining Avalonia into an even more developer-friendly framework.

Template Studio

We’ve released our first version of Template Studio for Avalonia - a streamlined solution designed to accelerate the creation of new Avalonia apps using an intuitive, wizard-based UI.

Getting started with Template Studio for Avalonia is a breeze. Simply install the extension and select the Template Studio project template when creating a new project in Visual Studio.

Ecosystem Growth

We've had the privilege of working closely with a range of pro-control vendors who have been developing specifically for Avalonia.

This marks an important milestone in Avalonia's journey as it signals a shift in the broader ecosystem - attracting commercial interest from vendors who have previously dedicated their efforts to supporting WPF, Xamarin and other Microsoft UI toolkits.

We’ve examined various .NET-based cross-platform UI frameworks for our next set of UI controls, but none of them capture the magic of WPF in the way that Avalonia does. Avalonia has a very strong community, offers pixel-perfect rendering on a multitude of platforms, is easy to customize, and frankly is a joy to work with.
Bill Henning, President, Actipro Software

It's exciting and humbling to observe this growth and be part of the vibrant community that is driving it. We're immensely grateful for the collaboration of these vendors and their belief in Avalonia's potential. As we move forward, we're enthusiastic about future collaborations and the continuing growth of Avalonia's ecosystem.

Thank you!

Avalonia has always been a labour of love, a community-driven project open to all. Over the past decade, more than 300 contributors worldwide have shaped Avalonia into what it is today. Avalonia v11 is not just a new version; it embodies our vibrant community's collective hard work and ambition to create the best cross-platform UI framework.

We invite you to join us on this exciting journey and help shape the next decade of Avalonia and the future of cross-platform .NET app development.

Getting Started

Ready to dive into Avalonia v11 and explore all the amazing new features? Head over to our Get Started guide to begin building with Avalonia.

If you’re already developing with Avalonia and want to upgrade to v11 then check out our upgrade guide.

First Release Candidate of Avalonia UI v11 Now Available!

Mike James — Thu, 01 Jun 2023 05:10:03 +0000

We're excited to announce that the first Release Candidate (RC) of Avalonia UI v11 is now available for you to try out!

This RC marks a significant milestone for us as it stabilises the API. It's been a journey of intense work, learning, and collaboration. And now, we can confidently say that we're closer than ever to the final release of v11

Now is the perfect time for you and your teams to test drive v11. As we progress, the only changes we're looking at are bug fixes. We believe this makes the RC a safe and exciting option to explore, especially if you're considering the upcoming production releases.

With a keen focus on maintainability, Avalonia UI v11 carries the most substantial changes in our API to date, setting the project up for a thriving future. We've poured considerable thought, time, and resources to ensure these changes pave the way for a more robust and reliable Avalonia UI. While this release represents our most substantial set of breaking changes, we expect future major releases will see significantly fewer breaking API changes.

As part of these breaking API changes, some previously public classes are now marked as 'Internal'. This change has been done to safeguard the integrity of applications by allowing us to modify implementations without introducing future breaking changes. While we've taken every measure to ensure a smooth transition, we acknowledge that you might encounter scenarios where a critical class is no longer visible. If you encounter such instances, we strongly encourage you to contact us. We're open to a dialogue about changing certain classes back to public visibility based on your valuable feedback.

We encourage everyone to try out the RC, provide your feedback, and help us make Avalonia UI v11 the best. We sincerely thank all our users, contributors, and the entire Avalonia community for your ongoing support.

Head over to nuget to get started. Let's build the future of cross-platform .NET UI technology together!

Happy coding!

Avalonia UI and MAUI - Something for everyone

Mike James — Wed, 29 Mar 2023 11:40:11 +0000

In the world of cross-platform .NET development, two popular frameworks have emerged as strong contenders: Avalonia UI and .NET MAUI (Multi-platform App UI). Both are powerful tools designed to solve different problems, making it essential to understand their key differences to make an informed choice for your project.

This blog post will delve into the primary distinction between these two technologies and the benefits of each approach.

Let's start with a brief overview of both Avalonia UI and MAUI.

Avalonia UI

Avalonia UI is an open-source, cross-platform UI framework that allows developers to create beautiful, responsive applications using a single codebase for multiple platforms, including Windows, macOS, Linux (desktop and embedded), WebAssembly and even mobile platforms. Avalonia UI leverages XAML for creating the UI, making it familiar to those with experience in WPF, UWP, WinUI or Xamarin.Forms.

While Avalonia UI is free and OSS, it is backed by a small, independent company formed by the core team responsible for the development of Avalonia UI. We offer development services, support agreements and recently announced our first product, Avalonia XPF. The goal of the company is to generate revenue to enable the core team to work on Avalonia UI full-time and to better serve enterprises building apps with Avalonia.

MAUI

MAUI (Multi-platform App UI) is an evolution of Xamarin.Forms. It's an open-source, cross-platform framework for building native UIs for iOS, Android, macOS, and Windows. MAUI simplifies creating apps with native user interfaces by enabling developers to develop in a single project. It uses the native UI toolkit of each platform, which allows developers to leverage platform-specific capabilities and build applications that feel native to each platform.

Developed by Microsoft, it has a large and dedicated community of users to lean on for support.

Now that we have a basic understanding of Avalonia UI and MAUI, let's dive deeper into their differences.

UI Drawing

Native vs Custom Rendering:

The primary difference between Avalonia UI and MAUI lies in how they draw the user interface. Avalonia UI employs a custom drawing engine powered by Skia (like Flutter), while MAUI uses native UI toolkits for each platform.

Let's explore these approaches in more detail.

MAUI

MAUI uses the native UI toolkit of each platform, resulting in an application that feels native to the platform it's running on. This means that a MAUI app on Android will use the native Android UI toolkit, while on iOS, it will use UIKit. This approach ensures that your application will have a look and feel that users expect on their devices. This approach offers several benefits:

Performance: By utilising native UI toolkits, MAUI can offer good performance, especially on mobile devices. It should be noted that on some platforms, objects will exist in both the .NET memory space and the platform UI toolkits memory. This can have a noticeable effect on performance compared to an app developed purely with the native technology. For example, on Android you will have two Garbage Collectors, one for the ART Runtime and one for the .NET runtime.

Platform-Specific Animations and Transitions: MAUI allows developers to harness platform-specific animations and transitions, giving applications a polished and native feel. By utilising the animations provided by the native UI toolkits, developers can create applications that are consistent with the design language of each platform and provide a familiar user experience.

Rapid Adoption of New Platform Features: As new features and UI components are introduced in native platforms, MAUI applications can quickly adopt these updates, ensuring that applications stay up-to-date with the latest design trends and platform improvements. This helps maintain a modern and consistent user experience while also reducing the time and effort needed to implement new features manually.

Avalonia UI

Unlike MAUI, Avalonia UI uses a custom rendering engine that draws UI elements consistently across all platforms. This means that your application will have the same appearance and behaviour regardless of the platform it's running on. Avalonia UI's custom rendering approach allows for greater control over the UI design and a consistent user experience across different platforms. This approach comes with its own set of benefits:

Consistency: Applications built with Avalonia UI have a consistent look and feel across platforms, which can be valuable for branding and user experience.

Flexibility: The custom drawing engine gives developers more control over their application's appearance and behaviour. They can create custom UI elements and styles that might not be possible or would require more effort using native UI toolkits.

Simplified Maintenance: Using a custom drawing engine means the UI code is the same across all platforms, simplifying maintenance and updates. Developers only need to change the shared codebase, reducing the time and effort required to maintain the application across multiple platforms.

Independent Evolution: Avalonia UI's custom drawing engine allows the framework to evolve independently of the native platforms it targets. This means that improvements, bug fixes, and new features can be implemented faster without having to wait for native platforms to catch up or maintain compatibility. As a result, Avalonia UI applications can benefit from continuous innovation and stay ahead of the curve in terms of UI and UX advancements.

Platform Support

While both technologies are both versatile and powerful UI frameworks, their platform support differs in some key areas.

Windows
MAUI provides support for Windows 10 and 11, depending on WinUI3, while Avalonia UI can target Windows 7 and higher.

macOS
As MAUI relies on Mac Catalyst, it supports macOS 10.15 (Catalina) and newer. Avalonia, on the other hand, supports macOS 10.13 (High Sierra) and higher.

Linux
At this time, MAUI doesn’t have any official support for Linux, though a community effort exists to enable MAUI to run on desktop Linux. Avalonia UI supports both desktop and embedded distributions of Linux, requiring no desktop environment to be installed. Officially supported distributions include Debian 9, Ubuntu 16.04 and Fedora 30 and higher.

iOS
MAUI supports iOS 11 and higher, while Avalonia UI supports iOS 13.

Android
MAUI supports Android 7.0 (API 24) and higher, while Avalonia UI supports Android 5 (API 21)

WebAssembly
It was recently announced that MAUI could be getting Web support after .NET 8, but at this time, there are no options to deploy your MAUI applications to the web. Avalonia UI supports WebAssembly today and has a fully interactive playground for exploring Avalonia UI on the web.

Solving Problems Differently

While both Avalonia UI and MAUI are powerful frameworks for cross-platform development, they are designed to address different concerns:

Avalonia UI is an excellent choice for developers who prioritise consistent branding and a uniform user experience across platforms. Its custom drawing engine provides flexibility in designing custom UI components and styles, making it perfect for creating unique and visually rich applications. Avalonia UI excels on desktop focused applications, with mobile and WebAssembly being new additions to the platform.

On the other hand, MAUI is the go-to choice for developers who need their applications to adhere to platform-specific design guidelines and provide a native look and feel. Its use of native UI toolkits ensures fantastic performance on various devices, and direct access to platform-specific APIs allows for seamless integration of native functionality. MAUI is a great choice for developing mobile centric applications, where desktop is a secondary or lower priority.

Conclusion

Avalonia UI and MAUI are both outstanding options for cross-platform development, each offering unique benefits depending on your project's requirements. The strength of the .NET ecosystem lies in its ability to provide developers with an array of options to choose from, ensuring they can select the most suitable approach for their specific project. The beauty of .NET is that a well architected application can reuse a huge amount of code, regardless of the UI framework used.

If you want to learn more about Avalonia UI and how it can help you develop visually stunning, high-performance applications for Windows, macOS, Linux, Android, iOS and WebAssembly then check out our getting started.

Avalonia platform support - why it's simple

Mike James — Fri, 03 Jun 2022 10:25:27 +0000

I recently came across a developer discussing Avalonia on Discord who was conflating the wide range of platforms Avalonia supports with a significant increase in development effort. I thought it would be interesting to briefly explore how Avalonia works and explain why bringing Avalonia to new platforms isn't nearly as involved as some might imagine.

Background

How does it compare to MAUI?
Before we go too far, it's essential to understand that Avalonia works very differently from frameworks like MAUI (or Xamarin.Forms), which uses a platform's native UI toolkit, providing a common API across all the supported platforms. MAUI is less a UI toolkit; more an abstraction layer over existing toolkits. The task of rendering the UI and handling user interactions isn't something the MAUI development team needs to worry about, as the device's UI toolkit is responsible for this. Instead, the primary problem for the MAUI development team has been creating an abstraction that conceals the wildly different UI toolkits, each with its quirks. Think of MAUI as a wrapper that provides native controls in an easy to use and lowest common denominator API.

Avalonia - Making Pixel-Perfect Apps

Having established how MAUI works, let's examine how Avalonia's architecture and approach differ. It's worth knowing that Avalonia is in good company in its design and isn't altogether unique as it shares similarities with how Google's Flutter UI toolkit works.

The most significant similarity is that Avalonia also utilises its own renderer, backed either by Skia or Direct2D. The renderer is responsible for drawing the entire application, allowing Avalonia to avoid depending on a device's UI toolkit.

To illustrate why this is significant, we should consider embedded and low-powered devices. Avalonia has become particularly popular among manufacturers producing touch-based embedded industrial devices.

We've found that they'll often use Linux, opting not to install a desktop environment, which would waste the limited storage, memory and CPU available on their low-powered devices. They can do this because Avalonia supports both accelerated rendering via Direct Rendering Manager and a software framebuffer. Given it’s using the same kernel API’s used internally by Xorg and Wayland compositors, it essentially replaces Xorg/Wayland, gaining exclusive access to the graphics hardware.

Beyond industrial device manufacturing, this approach brings countless other benefits, such as ensuring that an app looks and behaves identically across all the supported platforms. The ability to customise any part of the UI for any particular platform is maintained and is as simple as altering XAML styles. With Avalonia, creating great-looking, cross-platform apps without needing to use platform-specific UI APIs for the various devices you're supporting is easy. It's the essence of "write once, run everywhere".

Architecture

The architecture diagram below gives a good overview of how Avalonia works. Note that the majority of functionality in Avalonia resides in a netstandard2.0 project!

Rendering an application's user interface is just one piece of the puzzle. Avalonia also needs to handle elements such as wiring up the clipboard, windowing, cursors, hardware acceleration and input events. These pieces of the puzzle are required to facilitate Avalonia on a new platform.

Platform Support

Regardless of the intricacies required to create a UI toolkit, between 10 and 15 percent of the Avalonia code relates to facilitating the platforms. Most of the code is agnostic to any platform, meaning it's relatively easy for us to bring Avalonia support to new platforms when we want.

At the fundamental level, supporting a new platform with Avalonia requires two things; the ability to draw pixels and receive input events.

Avalonia VNC

To demonstrate this point, let's look at the Avalonia VNC platform support. While not typically considered a platform in its own right, in the context of Avalonia, VNC meets the prerequisites of being able to draw pixels and receive input events. It can thus be considered a platform!

What's especially surprising about the Avalonia VNC platform support is its implementation stands at less than 200 lines of code! It demonstrates just how little code is required to enable a new platform!

Why does Avalonia support VNC in the first place? Well, it's valuable for a few reasons, with my favourite being it enabled very early testing of web support. Before WASM with Blazor were viable options for enabling Avalonia in the browser, it was possible to run an embedded VNC server serving Avalonia content, delivering rudimentary web support.

Conclusion

While Avalonia has been historically focused on the desktop for almost a decade now, the recently released preview of iOS, Android and Web support represents a new milestone for the project. Supporting these platforms was never a technical problem or a matter of developer resources.

The developers contributing to Avalonia have helped create a cross-platform UI framework that industry leaders such as GitHub, Unity and JetBrains have come to trust. Given the project's remarkable success and massive growth in contributors, it presents an excellent opportunity to look to the future and consider how we can improve mobile and web development.

Learn More

Storing Desktop App Data

Mike James — Wed, 13 Jan 2021 16:51:40 +0000

I like to think of my PC’s document directory as a sacred place. As its name suggests, the documents directory is where I store my documents, in a neatly organised set of subdirectories.

It is not a dumping ground for random files and folders; this is what I use my desktop for!

I find it somewhat aggravating that so many desktop applications developers pollute the divined documents directory with their application-specific data. I hope that after reading this post, any offending developers will reconsider their choices and make better decisions on their next app.

Special Folders

Microsoft was kind enough to grace our hard drives with special folders such as My Music and My Pictures. These are just two of the 48 special directories defined in the ‘Environment.SpecialFolder‘
enum, part of the ‘System‘ namespace.

Two of my most used SpecialFolders are ApplicationData and CommonApplicationData. ApplicationData is for application-specific data for the current roaming user, and CommonApplicationData is for application-specific data that is used by all users.

So, when you build your next fantastic desktop application, I implore you to consider using one of these special folders for your application-specific content, rather than polluting your user’s document directory. It’s super easy to use!

Show me the code!

public void CreateApplicationSpecificGuff(string directoryName)
{
    var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData));
    var myAppsDataDirPath = Path.Combine(appDataPath, directoryName);
    Directory.Create(myAppsDataDirPath);
}

How to deal with existing pollution?

When I find applications that absolutely must have their app-specific data in the document’s directory, I tend to set their directories to Hidden. Out of sight, out of mind.

Distributed DMX with Apache Ignite

Mike James — Wed, 04 Mar 2020 11:42:54 +0000

A little known fact is that the original, intelligent lights and programming hardware formed a distributed system. Each light had its own on-board memory which was used to store the different states (looks) used throughout the show, and the lighting console would send a command for each light to load a particular look. I’ve heard of a show that was too large to fit on the lights on-board memory, so the operator had to split the programming into two, using the interval to upload the second half. I can’t imagine how nervous they were during this process!

This approach was a good start into the world of intelligent lighting, but had some significant drawbacks, the biggest being the impossibility of programming the show ahead of arriving at the venue. This ruled out the option of using 3D tools like Capture to program shows using a virtual representation of the venue and lighting rig.

An old Lighting Design I created many years ago, using Capture

Fast forward a little, and the advancements in consumer CPU’s allowed a single device to calculate all the required control data fast enough that distributed systems were no longer needed. This saw manufacturers adopt the architecture of using a single lighting console to calculate everything, with some providing the ability to track its state on a backup / redundant console but none offering a distributed system.

The backup console does no computation

Coming Full Circle

Only relativity recently has distributed systems come back into vogue, as shows have become more and more complex. With the complexity of shows like Eurovision, a single lighting console cannot calculate the control data fast enough. To get around this, multiple consoles are used together to control these massive shows. These console’s don’t just have ownership of a subsection of the lights, but instead create a Compute Grid, which is a high-performance computing technique to create a virtual supercomputer.

Grids are a form of distributed computing whereby a “super virtual computer” is composed of many networked loosely coupled computers acting together to perform very large tasks

https://en.wikipedia.org/wiki/Grid_computing

In this article, I’m going to discuss how I’m using Apache Ignite to develop a distributed data and compute grid in order to provide high-availability and scalablity.

Apache Ignite

What is it?

Apache Ignite is an in-memory computing platform that is durable, strongly consistent, highly available and features powerful SQL, key-value, messaging and event APIs.

Traditionally it’s used in industries such as e-commerce, banking, IoT and telecommunication it boasts companies such as Microsoft, Apple, IBM, Barclays, American Express, Huawei and Siemens as users.

Most users of Apache Ignite will be deploying it to servers either in a public cloud-like Microsoft’s Azure or into their on-premise data centers. Though servers are the usual domain for Apache Ignite, with its flexible deployment model, I can embed it as part of the Light Console .NET Core library.

I’m able to develop a distributed system that provides almost unlimited horizontal scale utilising the experience of its experts in distributed systems. The Apache Ignite codebase consists of more than a million lines of code and has 223 contributors meaning it’d be a huge effort to recreate this functionality in-house!

Contributions to Apache Ignite

Clustering

Apache Ignite is a fundamental pillar of my application architectures, providing data storage, service and event messaging capability. With being an integral part of my application, any consumer of the LightConsole.Core DLLwill either automatically connect to an existing session or create one on launch.

What this means is that anyone running the Light Console app will automatically discover existing nodes and join the cluster, thus increasing the compute and data storage resources of the overall grid.

Using this approach means that no single device is responsible for the entire system. Instead, each node (console or onPC software) takes responsibility for a subsection of data and compute.

Launching a new show create a Apache Ignite Session

Distributed Data Storage

Data Storage within the Light Console uses Apache Ignites distributed key-value store, which you can think of as a distributed partitioned hash map, with each console owning a portion of the overall data.

Each instance of Light Console owns a portion of the overall data

The above example demonstrates how Apache Ignite might distribute _Fixture _objects stored within the FixtureCache. In actuality, I define a backup property of 1, which will ensure that a fixture doesn’t only exist in one instance of Light Console. This is how I mitigate against data loss when a console (node) crashes or goes offline.

Defining a distributed Key-Value store with Apache Ignite

Affinity Colocation

As the show data is distributed across instances of Light Console, it’s important to ensure that any computations that make use of the data occur on an instance of Light Console that already has a copy of the data. This is called collocation and helps to significantly improve the performance of the application by reducing the need to move data around for the network for computation. The simplest example of a collocated computation currently within the project is the Fixture Patching mechanism. This is the process of assigning DMX Addresses to a fixtures control channels (such as pan, tilt, colour wheel, etc..).

The Compute Action is invoked using the PatchFixtureLocalCommand, _which is defined below. The _PatchFixtureLocalCommand hides the implementation details of the command and implements the _ILocalCommand _interface to support Undo/Redo functionality.

Distributed Services

Another feature of Apache Ignite that I’m using extensively is the Service Grid. Service Grid allows me to deploy services to the cluster that can be used by any of the consoles. The advantage of deploying services to the grid is that it provides continuous availability, load balancing and fault tolerance out of the box. I also have the ability to specify if a service should be a cluster-singleton, node-singleton, or key-affinity-singleton. Below you can see an example of a Node Singleton deployment, which would be deployed to each Light Console within the cluster.

Node Singleton Service Grid Deployment. Each Console get an instance of the service.

Two of the most critical services currently found within Light Console are the PlaybackEngine and the_ SyncTick_ Service. Both of these services are deployed as Cluster Singletons, which means that only one instance will be running on the cluster at any given time. If the instance of Light Console which is running the service goes offline, then Apache Ignite will automatically redeploy the service to another console.

SyncTick Service

The SyncTick service is responsible for keeping all the currently running transitions (fades) and effects in sync with each other. This is achieved by broadcasting a tick event to all the nodes with a DateTime representing when the Tick occurred. If a transition or effect is running, upon receiving the Ticked message, it’ll calculate the next value for output and notify the PlaybackEngine. With this architecture, I’m able to speed up and slow down output data / calculations across the entire grid from a single location. This makes it possible for future versions of Light Console to support Timecode.

Messaging

In the above snippet, you’ll notice that the Tick event is using the SendOrdered _method of _IMessaging. This method allows me to ensure that the subscribers receive the Tick messages in the order that they’re sent.

To subscribe to the messages, I then use the IMessaging LocalListen _method to register a message listener object which deals what to do when a message is received. To make my life easier, I ensure that I only ever call LocalListen and I use the _EventListener _class as defined below. The EventListener_ class allows me to use generics for the payload and easily attach to the EventRecieved event within the subscribing class.

Below you can see an example of a transition, which when started will create an EventListener and subscribe to the EventReceived event.

Wrapping Up

The above is just a small glimpse into how I’m using some of the feature available within Apache Ignite to power a distributed Lighting Control system. Whilst not exhaustive, I hope it gives you an idea of what’s possible and how you might also use Apache Ignite in your own projects.

It’s incredibly easy to get started with given it’s available as a Nuget package and has a rich set of documentation to help you understand features and how to add them to your apps.

Digging into App Center Data

Mike James — Tue, 18 Jun 2019 15:12:40 +0000

I recently published a blog post discussing the introduction of both authentication and data storage to App Center, which takes it from a DevOps focus to a fully-fledged Mobile Backend as a Service (MBaaS) solution. The first post was a little light on technical details as it was written on an iPad whilst on vacation, so I wanted to follow up with a little more meat. In this blog post, I’ll be showing how I’ve built a no-code backend to power a mobile app built with Xamarin.Forms 4.0.

App Center Data

App Center data allows us to quickly add data functionality to our mobile apps, providing us to ability to manage, persist and sync data across app installations. It’s backed by the incredible Azure Cosmos DB, which is Microsoft’s globally distributed, low latency, highly-available cloud born database.

Through using Cosmos DB as the underlying technology powering App Center Data, it opens up a world of opportunity to integrate our app into other services in Azure, as well as offering us a clear path to migration, should we find App Center doesn’t fit our growing needs.

Collections and Partitions

In order for Cosmos DB to meet our performance needs, we must partition our data into distinct subsets, called _logical partitions. _Logical partitions are formed based on the value of the _partition key _associated with each item found within the a collection. By default, App Center provides two partition keys within the SDK named AppDocuments and UserDocuments. These are defined in a Static Class named DefaultPartitions which can be found within the AppCenter.Data namespace. Though we’re provided with two partitions to get started with, its not a requirement for us to use the built-in partition keys for all of our data. Instead, we are able to provide a string value for creating our own partition keys.

Check out the official Cosmos DB docs to learn more about data partitions.

AppDocuments – Read Only

The AppDocuments partition is a read-only partition for storing data which can share the data across all users. Trying to write to the AppDocuments partition will cause an exception to be thrown, so its best avoided! Instead, consider building auxiliary services to manage your AppDocuments.

UserDocuments – Read & Write

UserDocuments are documents that are owned by an individual user and thus can only be read, updated and deleted by the owner . In order to enable UserDocuments, you must have first configured App Center Authentication. With Authentication enabled, calling the CreateAsync method and providing the UserDocumentspartition key will set the partition key to currently signed in users Id. This will look something like:

“PartitionKey” : “user-e831f9de-c35c-4139-ae9c-8b59b3fefc02”

Advocates App Data

I wanted the demo app to demonstrate both AppDocuments and UserDocumentsbut initially couldn’t think of what data to show that should be read-only. After some consideration, I decided to utilise existing data from our Cloud Advocate Directory.

This directory is a little like a right-of-passage for us Cloud Advocates, for every single one of us has had to write about ourselves when we joined the team. Most of the advocates have followed roughly the same format for their pages, which meant it was fairly easy (it not time consuming) to manually add my colleagues to the database.

Defining a Data Model

Below I’ve defined the Advocate model which inherits from a BaseModel. The BaseModel class in extremely simple, with only 1 public property for the ID. The App Center SDK requires that all objects contain an ID of type string, so inheriting from the BaseModel ensures that every model is compatible.

public class Advocate : BaseModel  
{  
public string Name { get; set; }  
public string GithubHandle { get; set; }  
    public string TwitterHandle { get; set; }  
    public string AvatarUrl { get; set; }  
    public string Bio { get; set; }  
    public List\<string\> Skills { get; set; }  
    //Used for location & timezone lookup  
public double Latitude { get; set; }  
public double Longitude { get; set; }  
 public List\<IgniteStop\> IgniteStops { get; set; }  

public Advocate()  
{  
Skills = new List\<string\>();  
 IgniteStops = new List\<IgniteStop\>();  
}  
 public string ClassType { get; set; }}  

public class IgniteStop  
{  
public string Name { get; set; }  
public string Image { get; set; }  
}  

//Base Model must have an ID Property of type string  
public class BaseModel  
{  
public BaseModel()  
    {  
     Id = Guid.NewGuid().ToString();  
    }  

public string Id { get; set; }  
}

You’ll note that I’ve added a ClassType property, which I later set when saving the object. I added this to make my life easier when attempting to read all data from a partition, which is not of the same type.

As previously mentioned, it’s not possible to create documents with the AppDocuments partition key, so that rules out creating these documents using the Xamarin SDK. Instead, I created dummy data manually and uploaded these manually to Cosmos DB using the Azure Portal. The first piece of dummy data was my own info, as shown below:

Reading App Data with the Xamarin SDK

Before we jump into looking at the App Center Xamarin SDK, its worth noting that this sample uses an extremely popular Mvvm framework called Prism. Prism is a rather opinionated framework which dictates that we should register services within the App.cs of our Xamarin.Forms Application for later use throughout our app. Normally for a demo, I’d put my data access code directly in the ViewModel, but given I’m trying embrace Prism, I thought I’d follow the recommended architecture and move this functionality into a separate service classes. Below is the incredibly simple ‘AdvocatesDataService‘ class, which contains just one Method.

public class AdvocatesDataService  
{  
public async Task\<IEnumerable\<Advocate\>\> GetAdvcoates()  
{  
try  
{  
var result = await Data.ListAsync\<Advocate\>(DefaultPartitions.AppDocuments);  
var unsorted = result.CurrentPage.Items.Select(a =\> a.DeserializedValue).Where(x =\> x.ClassType == "Advocate");  
 return new List\<Advocate\>(unsorted.OrderBy(x =\> x.Name));  
 }  
catch(Exception ex)  
{  
Crashes.TrackError(ex, null);  
return new List\<Advocate\>();  
}     }}

Pagination

As you may have seen, the above response is actually paginated, though I only handle the first page right now. This works at the moment because I’ve not added all of my colleagues to the database! As I get around to adding more of my colleagues, I’ll likely want to handle pagination properly. PaginatedDocuments have the following methods and properties:

HasNextPage : Boolean property indicating wether an extra page is available or not.
CurrentPage : Property that returns the current page with type being Page<T>.
GetNextPageAsync() : Method that asynchronously fetches the next page (the method returns an object of type Task<Page<T>>).
IEnumerator<DocumentWrapper> GetEnumerator() : This is an enumerator for the paginated docs, which can traverse them

App Center doesn’t currently support offline persistence when listing documents.

Service Registration with Prism

I register this service within the App.cs RegisterTypes method so that it can be used throughout my App.

<tabbedpage><span style="font-family: Menlo;"><span style="color: #222222;"><span style="color: #009695;">protected</span> <span style="color: #009695;">override</span> <span style="color: #009695;">void</span> RegisterTypes(<span style="color: #3363a4;">IContainerRegistry</span> containerRegistry)<br>{<br> containerRegistry</span><span style="color: #222222;">.</span><span style="color: #222222;">Register</span><span style="color: #222222;">(</span><span style="color: #009695;">typeof</span><span style="color: #222222;">(</span><span style="color: #3363a4;">AdvocatesDataService</span><span style="color: #222222;">));<br><br> //And a whole lot more...<br></span></span>}</tabbedpage>

Below shows how to consume the now registered AdvocateDataService from within your ViewModels.

//ViewModel Constructor  
public AdvocatesPageViewModel(INavigationService navigationService,   
AdvocatesDataService advocatesDataService)  
{  
this.navigationService = navigationService;  
this.advoatesDataService = advocatesDataService;  
}

Calling the GetAdvocates Method of the AdvocatesDataService class allows us to bind the results to a Xamarin.Forms TableView as seen below:

Creating & Reading User Data

Now we’ve seen how we can use the Xamarin SDK to read lists of AppDocuments, let’s take a look at how we can create, update, delete and read UserDocuments.

To demonstrate UserDocuments, I decided to add the ability to record what links we’ve shared with the community. The reason for recording this is because we (Microsoft Cloud Advocates) are measured on the number of users we direct to the Azure documentation. We measure this using Tracking Links which look a little like this:

"https://docs.microsoft.com/appcenter?WT.mc_id=app-center-mbaas-personalblog-mijam"

The tracking element has been bolded to make it easier to see.

Defining a Data Model

public class TrackingLink : BaseModel  
{  
public string Url { get; set; }  
public string Event { get; set; }  
    public string Channel { get; set; }  
    public string Alias { get; set; }  
    public DateTime CreatedAt { get; set; }  
    public string ShareableLink { get; set; }  
}

The TrackingLink data model like the Advocate model inherits from BaseModel in order to ensure that it has a Id property string.

Tracking Link Data Service

Having defined the data model, I set about implementing a TrackingLinkDataService class, which like our AdvocateDataService class would be responsible for interacting with App Center.

Read All

public async Task\<IEnumerable\<TrackingLink\>\> GetTrackingLinks()  
{  
try  
{  
var result = await Data.ListAsync\<TrackingLink\>(DefaultPartitions.UserDocuments);  
var unsorted = result.CurrentPage.Items.Select(a =\> a.DeserializedValue).Where(x =\> x.ClassType == "TrackingLink");  

 return new List\<TrackingLink\>(unsorted.OrderBy(x =\> x.CreatedAt));  
}  
catch (Exception ex)  
{  
Crashes.TrackError(ex, null);  
return new List\<TrackingLink\>();     }  
}

Starting with GetTrackingLinks, this method fetches all the tracking links owned by the currently signed in user. Thankfully the App Center SDK deals with ensuring the correct data is returned so we don’t even need to specify the User ID in our method call.

Create Link

public async Task\<bool\> SaveTrackingLink(TrackingLink trackingLink)  
{  
trackingLink.CreatedAt = DateTime.Now;    trackingLink.ClassType = "TrackingLink";  
 trackingLink.Alias = Xamarin.Essentials.Preferences.Get("Alias", "");  

 try  
{  
await Data.CreateAsync(trackingLink.Id.ToString(), trackingLink, DefaultPartitions.UserDocuments, new WriteOptions(TimeToLive.Infinite));  
return true;  
}  
catch(Exception ex)  
{  
Crashes.TrackError(ex, null);  
return false;  
}  
}

When saving a tracking link, I add a few extra properties such as the current DateTime, set the ClassType and then fetch the Alias using Xamarin.Essentials. Adding the optional WriteOptions means that our document will be stored locally if the user is offline, then will be persisted to the cloud as soon as the device regain connectivity. TimeToLive.Infinite causes our tracking links object to be cached indefinitely rather than the default one day if not online.

Cosmos DB Document

Creating a Tracking Link with the SDK creates a JSON document in Cosmos DB that looks like the following:

{ "document": { "CreatedAt": "2019-06-10T15:42:34.739151+01:00", "Id": "9a0f4e0e-545f-473e-ac6c-f44c2581c93a", "ClassType": "TrackingLink", "Alias": "Mijam", "Url": "https://test.co.uk", "Event": "Event", "Channel": "Channel", "ShareableLink": "https://test.co.uk?WT.mc\_id=Event-Channel-" }, "PartitionKey": "user-e831f9de-c35c-4039-ae9c-8b59b0fefc02", "id": "9a0f4e0e-545f-473e-ac6c-f44c2581c93a", "\_rid": "BcpnAIigIFdsAAAAAAAAAA==", "\_self": "dbs/BcpnAA==/colls/BcpnAIigIFc=/docs/BcpnAIigIFdsAAAAAAAAAA==/", "\_etag": "\"0000584b-0000-1100-0000-5cfe6c970000\"", "\_attachments": "attachments/", "\_ts": 1560177815 }

The important thing to note is the PartitionKey as this relates to the UserId which is returned as part of the authentication process.

Deleting Links

public async Task\<bool\> DeleteTrackingLink(TrackingLink trackingLink)  
{  
try  
{  
await Data.DeleteAsync\<TrackingLink\>(trackingLink.Id, DefaultPartitions.UserDocuments);  
return true;  
 }  
 catch (Exception ex)  
 {  
Crashes.TrackError(ex, null);  
return false;  
}  
}

Deleting data is very straight forward using the DeleteAsync method, which covers the basics of CRUD operations using the App Center SDK.

Wrapping Up

In this post I’ve explained how I’ve used the new preview features of Visual Studio App Center to build a Xamarin.Forms 4.0 app that also uses Prism. You can grab the entire project from my Github!

Hopefully by this point you’ve seen just how easy it is to get started with App Center Data. Its a very un-opinionated SDK, with no requirements on how you define your schema, which makes it a perfect fit for developers who find traditional SQL database too rigid and inflexible.

If you want to learn more about App Center Data then check out the rich documentation on over at the Microsoft Docs Portal.

Getting started with Data and Auth using Microsoft App Center

Mike James — Mon, 10 Jun 2019 09:30:42 +0000

In my first week working for Xamarin, I was flown to Austin Texas from London in order to help support Xamarin Evolve 2013. Like most conferences, we had sponsors, which included a little startup called Parse. Parse was a backend born in 2011 that allowed mobile developers to easily add cloud storage, push notifications and authentication to their apps. I was sold on the technology immediately and got started building out sample apps to demo Xamarin using parse backends.

Parse was acquired by Facebook in 2013 and lasted until 2016 before being shut down. Thankfully Facebook made Parse open-source which allowed users to migrate their Parse backends to cloud providers such as Azure with our Parse Server template.

Parse no longer having a maintainer was a problem for lots of users, who would want to bet new apps on unmaintained services? I decided that any new apps I developed would not rely on Parse but instead I’d need to find an alternative. Being a .NET Developer, it made sense to use Microsoft’s Azure Mobile App service, which consists of a .NET Framework based web API project and a client SDK.

Embracing Azure Mobile Apps saw me spending more time in Visual Studio writing generic Web APIs and broadening my experience with Web API development. These skills provided me the ability to drop the pre-built solutions and start rolling my own as seen in the Mobile Cloud Workshop I created with my esteemed colleague, Robin-Manuel.

Whilst rolling the backend offers unparalleled flexibility, it’s also no small undertaking to develop, test and maintain, which was ultimately a distraction from my core goal of building a mobile app. I’ve not reached the levels of productivity developing cloud connected apps since migrating from Parse in 2016.

App Center

This has all changed now with the latest update to Microsoft App Center. If you’ve not heard of App Center, it’s the replacement to HockeyApp or Xamarin Insights. It’s our automated build, test and analytics platform, designed specifically for mobile developers.

App Center has proved invaluable for building better apps but it wasn’t a ‘one stop shop’ for mobile dev, with me having to roll my own backends for data and authentication. This changed earlier this year at Build, with the addition of authentication and data storage features.

Authentication

Authentication is one of those features that I like to avoid as its unexciting and easy to get wrong. It’s this reason that I never roll my own authentication solution, but instead rely on 3^rd parties like Active Directory or Auth0.

When I first started using Azure Mobile Apps with its companion mobile SDK, I was able to authenticate users with only a couple of lines of code, which made it a no brainer to add to my demos. I’m super happy to say that the new Mobile Apps SDK makes it just as easy! It does this by wrapping the Microsoft Authentication Library (MSAL) which implements authentication using OAuth 2.0.

The authentication process is powered by Active Directory B2C (Business to Consumer), which makes it’s incredibly easy to setup! It also makes it possible to use a huge variety of identity providers such as Google, Twitter, Facebook and Microsoft as well as integrate with 3rd party providers. It gets all of the standard B2C functionality, such as using machine learning to detect suspicious behaviour and options for multi-factor auth.

Once a user has authenticated, they can create documents using App Center Data which are only visible to them.

Data

The biggest difference between App Center and Azure Mobile Apps has to be how we model andstore data.) With the older Azure Mobile Apps, we could pick between Microsoft Azure SQL or for testing, a SQLite Database. The only option we had was to a relational database, which was great if you had a schema that lends itself well to being normalised.

App Center uses Cosmos DB as its underlying data storage service. This is our cloud-first, global scale NoSQL database offering. Cosmos DB allows us to forget about database scaling as it promises low latency and high availability in all the regions you deploy your data to.

Partitioning Data

App Center only uses one collection which helps keeps cost down as we pay for every collection, even if empty when using Cosmos DB. Within the single collection used for App Center, you can define two types of document, private and public.

Private documents consist of user data, allowing authenticated users to have read and write access to edit the contents.

Public documents only allow for read access (using the App Center SDK) as to avoid users being able to overwrite global data.

Offline

One of my favourite features of using Azure Mobile Apps was its ability to support offline-synchronization of data between client and the backend. Offline sync not only allows apps to work offline but also makes them appear more performant when online.

App Center supports offline read and writes but the data is only cached for a day by default. It’s possible to set a time-to-live (TTL) if required. If connectivity is lost, users will still have the ability to read cached documents and write data with changes cached until connectivity is restored. One important thing to note is that conflicts are handled using “last write wins”.

Schema

If I use the App Center Data SDK then I can use plain CLR objects with the only requirement that I have an ID property of type Guid.

public Guid Id { get; set; } = Guid.NewGuid();

When the object is actually saved to App Center, you’ll see that the schema is a little different to what you might expect. This is because App Centner add a few extra properties and nests your schema into a object named “document”.

This is very important to remember if you’re going to interact with the data using other services.

Wrapping up

I’ve only just started to explore what I can build with App Center and how best to integrate it into my app development process.

With less than a week of development, I’ve already got an app built which supports push notifications, offline sync of data and authentication. This kind of productivity is a huge win in terms of my ability to add features as I focus on the app and let the App Center team focus on the backend infrastructure.

If you’ve ever used Parse, Firebase or Azure Mobile Apps then I highly recommend giving App Center a try.