{"version":"https://jsonfeed.org/version/1.1","title":"Dan Siegel | Building Better Apps","home_page_url":"https://dansiegel.net","feed_url":"https://dansiegel.net/feed.json","description":"Practical writing about .NET, .NET MAUI, Uno Platform, Prism, developer tooling, open source, and building maintainable software.","authors":[{"name":"Dan Siegel","url":"https://dansiegel.net/about/","avatar":"https://dansiegel.net/images/dan-siegel.webp"}],"language":"en-US","items":[{"id":"https://dansiegel.net/post/2023/10/07/prism-9-0-preview-1","url":"https://dansiegel.net/post/2023/10/07/prism-9-0-preview-1","title":"Prism 9.0 Preview 1","summary":"Ok I know I might start sounding like Tim Cook \"This is the biggest release yet\". But seriously, Prism 9.0 just may be the biggest release the Prism team has...","content_text":"Ok I know I might start sounding like Tim Cook \"This is the biggest release yet\". But seriously, Prism 9.0 just may be the biggest release the Prism team has done to date. Despite some people claiming Prism is dead because there wasn't a recent release, the fact is we were hard at work on this release. Prism 9.0 is the sum of 2 years of work and I think you're going to really like some of the changes. It grew to a point for many reasons that meant there would be no 8.2 and instead we had to bump to 9.0. So what is so different in this release? \n \n\n## The License\n\nOk this may not quite fall under the category of we were super hard at work. But at the same time it actually kind of does. The license has changed from previous versions of Prism. First and foremost I'd like to address the \".NET Foundation issue\". Both Brian and I love the idea of the .NET Foundation. We have always been big believers in it's initial vision and goals. Over the years though we simply realized that the vision of the .NET Foundation and it's actual practices (where it's really going) are two very different places. We believe in Open Source Sustainability, and fostering healthy relationships of trust between maintainers and the .NET Community. Unfortunately for a number of reasons we felt it was time to leave. \n\nAs I mentioned, we believe in Open Source sustainability. As you may be aware Brian and I were also early adopters of the GitHub Sponsors program and have tried for the last several years to build a sustainability model around Prism with it. GitHub Sponsors had amazing promise, unfortunately it just isn't something that is working. After years of going back and forth on this issue, we have finally decided to change the license to a Dual License model. If you are familiar with the Community License program that is available from Syncfusion then you will already feel at home with what we are doing. If you qualify for the Community License you do not need to sign up for anything and you can continue to use Prism for personal or commercial purposes completely for Free! For more information on the licenses please visit [prismlibrary.com](https://prismlibrary.com/).\n\n## One API To Rule them All\n\nPrism 9.0 represents a major shift for us moving forward. In the past we had Regions, and Modularity duplicated in WPF and Xamarin.Forms. Then of course we introduced Dialogs and duplicated these as well. To make it more fun we added support for Uno Platform and you had the community project for Prism.Avalonia each with their own interface definitions for what these APIs should look like and going from one to another you ultimately had some small breaks in the API. While we had actually moved the Modularity interfaces to Prism.Core in Prism 7.1, Dialogs and Regions have now moved to Prism.Core as well. This means for the first time you can write ViewModels for your Dialogs or Regions and reuse them from your WPF application to your .NET MAUI application or even your Uno Platform application. We believe this will greatly empower some amazing scenarios for developers who may want to reuse legacy code from their WPF applications and bring it forward to mobile platforms.\n\nNote that this also represents a break in namespaces as we are now sharing the NavigationParameters between Xamarin.Forms/.NET MAUI Page Navigation and Region Navigation. We have also moved the IDialogService to a new namespace as well.\n\nAlso well worth noting is that the IEventAggregator has been moved into a separate package which is now referenced by Prism.Core. This will enable people to make use of the IEventAggregator even outside of a Prism Application. Similarly we have moved our Dependency Container abstractions out of the Prism repo to a new private repo where the containers are maintained. This results in better sharing of DI Containers between platforms because they are now implemented independent from the platform meaning if you need specific container access without adding a framework dependency on WPF or .NET MAUI, etc... you now have this ability. This move also gave us the space to provide support for 2 new Dependency Injection Containers which will be available to Commercial Plus license holders ONLY.\n\n\\- Microsoft.Extensions.DependencyInjection \n\\- Grace\n\n## .NET MAUI\n\nPrism 9.0 represents the first real release to support .NET MAUI. I know many people have wanted to see this a lot sooner, but truth be told .NET MAUI just wasn't production ready prior to .NET 8. With .NET 8 we finally got some of the API updates that we needed to properly support .NET MAUI and I think you are going to like it. For those who haven't yet had a chance to play with the earlier previews, Prism.Maui represents a change in paradigm where you no longer have a PrismBootstrapper or PrismApplication. We met the MAUI API where it made the most sense, with the MauiAppBuilder. This means that the flow is natural and you get a PrismAppBuilder with a fluent API that just makes sense. This also brings a number of changes to the table including a new NavigationBuilder that gives you more power and flexibility in creating your Page Navigation Uri's and even adds support for ViewModel navigation.\n\n## Uno Platform\n\nThis release adds support for Uno Extensions out of the box targeting the latest stable release of Uno Platform.","date_published":"2023-10-07T09:36:00.000Z","date_modified":"2023-10-07T09:10:45.000Z","tags":[".NET",".NET MAUI","Prism"]},{"id":"https://dansiegel.net/post/2022/06/02/prism-for-net-maui-public-beta","url":"https://dansiegel.net/post/2022/06/02/prism-for-net-maui-public-beta","title":"Prism for .NET MAUI - Public Beta","summary":"Ok the name kind of gives it away, but Prism for .NET MAUI is now available as a Public Beta! We've been working hard the past year on Prism for .NET MAUI, and...","content_text":"Ok the name kind of gives it away, but Prism for .NET MAUI is now available as a Public Beta! We've been working hard the past year on Prism for .NET MAUI, and at times it felt almost impossible as every time I would catch up with the MAUI team there would be new breaking changes that made it all pointless... The great news is that .NET MAUI has finally reached a certain level of API stability and we've been able to make some incredible process along the way. You might be asking, \"Isn't this really just Prism for Xamarin.Forms but built against .NET MAUI?\"\n\nThe answer to that is a little complex, but in short the answer is Yes... and No... The Prism.Maui initiative started with the Prism.Forms codebase and then over the past year we've made one improvement after another really in one of two categories:\n\n1) .NET MAUI had a change in API or Paradigm that required a change in how Prism handles \"....\"\n\n2) Prism.Forms was great but we really wish that we could have made \"....\" change\n\n![Prism for .NET MAUI - Public Beta](/images/blog/prism-for-net-maui-public-beta/01-image.webp)\n\n## Application Startup\n\nOne of the first things that you'll notice when you create a new .NET MAUI project is that you no longer have multiple Platform Heads with a common core project that contains your shared business logic. Single Project is here and it really cleans some things up. With Single Project we also get the MauiAppBuilder which is modeled after the App Builder pattern we've seen across the .NET Ecosystem from Console Apps to AspNetCore. This change is rather significant for developers coming from Prism.Forms as it moves the App Startup Logic outside of the PrismApplication and into the new PrismAppBuilder. One of the great things about the AppBuilder is that you get the opportunity to easily see what configuration options Prism offers and even get a few overloads to match what you need to do. In fact this gives you the opportunity to even write your own extension methods for the PrismAppBuilder as you can potentially call methods on the App Builder multiple times allowing you to split up your logic around what you might need to Register or Initialize. \n\n```csharp\n// It's as easy as...\nMauiApp.CreateBuilder()\n .UsePrismApp(prism =>\n prism.RegisterTypes(c => {\n // register your types\n })\n .OnAppStart(\"MainPage\"))\n .Build();\n\n// Or take control of your navigation\nMauiApp.CreateBuilder()\n .UsePrismApp(prism =>\n prism.RegisterTypes(c => {\n // register your types\n })\n .OnAppStart(async (container, navigationService) => {\n var result = await navigationService.NavigateAsyc(\"MainPage\");\n if(!result.Success)\n {\n // use the container to resolve a logger\n }\n })\n .Build();\n```\n\nThe `PrismAppBuilder` doesn't stop there though as we also make it easier to maintain a fluent API and try to meet you where you want to be. This means that instead of having to access the `ILoggingBuilder` or `IServiceCollection` off of the `MauiAppBuilder`, we give you easy to use extensions to provide your delegate. Not only did we do that, but we also made sure that if you need to use the `IServiceCollection` to register your services, you can easily access the same registration methods to register your Views for Navigation with the IServiceCollection.\n\n### Service Registration\n\nFor years Prism simply relied on 3rd party DI Containers. Due to issues surrounding different APIs with different containers, we began creating a robust container Abstraction layer that was powerful enough for most power users without needing to directly use the underlying container. We're rather proud of what this has unlocked for many developers. MAUI though brings Microsoft.Extensions.DependencyInjection into the Application Framework as a First Class citizen for the first time. While the Prism DI Abstraction layer isn't going anywhere, we did feel it was important to support both IContainerRegistry and IServiceCollection for registering your services. \n \n**NOTE:** Prism does not at this time directly support Microsoft.Extensions.DependencyInjection. There are limitations of the container which currently make it incompatible with Prism.\n\n## Navigation\n\nOver the years I've been incredibly blessed to travel to some amazing places and meet developers around the world. Without a doubt no matter where I go, everyone's favorite feature is Prism's awesome URI based Navigation for Prism.Forms. This was something that had to just work, but I also knew there was some room for improvement here as well. One of the first things was that the interface was cleaned up exposing only 3 methods with everything else being an extension method.\n\n### ViewModelLocator\n\nPrism has long had an Attached Property from the ViewModelLocator which allows you to optionally provide a boolean to Autowire the ViewModel. In early versions of Prism 6 this was required, however it was later made a Nullable Boolean with an assumption that if you had not set the property you probably wanted to Autowire the ViewModel. Prism.Maui changes this ever so slightly by introducing a ViewModelLocatorBehavior enum. You can either leave it Automatic and Prism will Autowire the ViewModel once the View is ready, or you can disable it entirely. It's important to note that if Prism detects that your View has a Binding Context that isn't itself or a Parent we will not Autowire your ViewModel.\n\n### Navigation Builder\n\nThe Navigation Builder is brand new for Prism.Maui and something I think you'll really love. It is easy to use as an extension method on the INavigationService. The Navigation Builder has a number of helper methods to help you create complex Navigation URI's which can include parameters that are specific to individual Pages in your route, add a NavigationPage, or build a custom TabbedPage on the fly. Of course that's probably all things you've come to expect from Prism. For years I've often had developers request one thing over and over again with Navigation. They know that they shouldn't reference the View from the ViewModel as this breaks the MVVM pattern, and Prism hadn't offered ViewModel Navigation. This is something that you can now do with the NavigationBuilder.\n\n```csharp\nnavigationService.CreateBuilder()\n .AddNavigationSegment(\"ViewA\") // use classic names\n .AddNavigationSegment() // use ViewModel First API\n```\n\n### Overloaded Registrations\n\nPrism's classic `ViewModelLocationProvider` has long had a limitation where a Single View can only be registered against a single ViewModel. This was something that I set out to solve with Prism.Maui. As a result, Prism.Maui is the first platform from Prism to support Registering a single View with different names each mapped to a different ViewModel. This will unlock so many possibilities particularly in the Enterprise and I'm excited to hear how this helps some of you create some incredible experiences.\n\n```csharp\ncontainer.RegisterForNavigation(\"MonthlyBilling\");\ncontainer.RegisterForNavigation(\"Subscriptions\");\n```\n\n### Global Navigation Events\n\nOne of the frustrations with the Navigation Service is that it has to be tied to a specific Page for context of where it will need to Navigate from. Over the years this has been transformed from a Transient to a Scoped Service which opens up a lot of possibilities when it comes to sharing the instance across types which may be resolved at different times such as the View, ViewModel, or even ViewModel for a Region within the Page. It also makes it harder to wire up a single handler to try to track the actual navigation stack or handle Navigation Errors. Prism.Maui has introduced a `NavigationRequestEvent` using Prism's tried and trusted `IEventAggregator`. You can hook up to this out of the box, or install the Prism.Maui.Rx package and get access to an `IObservable` as part of the PrismAppBuilder pipeline.\n\n```csharp\nMauiApp.CreateBuilder()\n .UsePrismApp(prism =>\n prism.RegisterTypes(c => { })\n .AddGlobalNavigationObserver(x=>\n x.Subscribe(context => {\n // Check for Navigation Errors\n // Update a local context for your current Navigation Uri\n })\n ));\n```\n\n## Region Navigation\n\nIt might seem odd to some, certainly it always has to me. Regions ARE how you navigate with Prism.WPF, and this was missing API for a very long time from Prism.Forms. When we finally did offer it, it was in a separate package. Region Support in Prism.Maui is built in from the start and its really first class as a result. A lot of work has been given to ensure that Scoped Services such as the INavigationService will be injected into your Region Views and ViewModels the same as they are in the parent Page's ViewModel. In fact if you Register a View with a Region and it is an Active View within the Region, the Region's ViewModel can even participate in classic Prism Navigation ViewModels getting the INavigationParameters for the Initialize, OnNavigatedFrom, OnNavigatedTo, and even Page Lifecycle events with Prism's IPageLifecycleAware interface.\n\n## F.A.Q\n\nQ. Is this Production Ready? \nA. In general I would say anything serious with MAUI should wait for .NET 7. This is absolutely great for POCs. \n \nQ. Is Prism.Maui API complete? \nA. No, it's probably about 90%+ but we are still missing a few things like our XAML Navigation Extensions, & the newer Dialog Service \n \nQ. Do I have to register my services with Prism's IContainerRegistry? \nA. NO! You can choose whether to use IContainerRegistry or IServiceCollection... and ultimately you can use both if its easier for you. \n \nQ. There is a flash of the Splash Screen when I do an Absolute Navigation. Is this normal? Will it be fixed? \nA. Yes that is due to a known bug in .NET MAUI. Hopefully it will be fixed and we won't have to hack to make Absolute Navigation work in the near future. \n \nQ. Is the API likely to change? \nA. It's matured quite a bit, but I do think we're mostly stable. It is still a beta package so things could still change. \n \nQ. Will there be a Template? \nA. Yes there will be... but as of this post there currently is not one. It is coming though and soon!\n\n## Where To Get It\n\nThe public beta is available now on [nuget.org](https://www.nuget.org/packages?q=prism.maui). For those who have stepped up as a GitHub sponsor you can access the latest CI packages on [Sponsor Connect](https://sponsorconnect.dev/).\n\nPlease help keep Prism a sustainable Open Source project and [become a GitHub Sponsor](https://xam.dev/sponsorDan) today.","date_published":"2022-06-02T07:22:00.000Z","date_modified":"2022-06-02T16:05:56.000Z","tags":[".NET",".NET MAUI","Prism","Xamarin","maui","Xamarin Forms",".net maui"]},{"id":"https://dansiegel.net/post/2021/07/07/making-devops-easy-with-mobile-buildtools","url":"https://dansiegel.net/post/2021/07/07/making-devops-easy-with-mobile-buildtools","title":"Making DevOps Easy with Mobile.BuildTools","summary":"It's been quite a journey if I'm honest. In fact as I look back over the last several years it's really crazy too look at what the Mobile.BuildTools has...","content_text":"It's been quite a journey if I'm honest. In fact as I look back over the last several years it's really crazy too look at what the Mobile.BuildTools has transformed into from it's humble origins as a collection of PowerShell scripts I was tired of rewriting every time I started a new app. The Mobile.BuildTools have continued to make developers lives easier with the last major release being exactly 3 years ago. Spoiler, the Mobile.BuildTools 2.0 does so much for you over what 1.x could do, I cannot hope to cover it all in a single blog post. It also means I had to put together a full docs site and json schemas for the configuration so that I could remember it all. If you haven't started using the Mobile.BuildTools yet, this package really is a must add for all of your Xamarin apps. While most of my followers know me for maintaining Prism, what you may not realize is that I also have a passion for proper DevOps. One of the beautiful things about the Mobile.BuildTools is that at the end of the day it just a collection of MSBuild Targets which means that everything that you do on your Local dev machine just works in CI without any special scripts or extensions to install into your Azure DevOps org, and it doesn't even matter which CI platform you want to use because it will just work! Of course before you ask, this is a build reference meaning that there are no extra assemblies getting added to your app bloating the compiled app size (unless you want app.config).\n\n## What is in 2.0?\n\nWhile Mobile.BuildTools 1.4 is awesome, truthfully there were a lot of processes that I still found to be a struggle, or at least more of a process than what they really needed to be. Perhaps one of the single greatest changes is that while the Mobile.BuildTools continues to be a collection of MSBuild extensions that make the build pipeline tailored to the DevOps processes that make your life easier whether you're building on your local machine or in CI, you don't need to understand anything about MSBuild, or csproj properties. With 2.0, you can now leverage a json first approach to configuring the Mobile.BuildTools.\n\n![Making DevOps Easy with Mobile.BuildTools](/images/blog/making-devops-easy-with-mobile-buildtools/01-image.webp)\n\nThe Mobile.BuildTools 2.0 is a nearly complete rewrite from version 1.4, and while certain features could probably get their own dedicated blog posts I thought it might be good to give a brief introduction to some of the amazing features and how they can help you out.\n\n## Application Settings\n\nFor those upgrading from 1.4, you're already familiar with the secrets.json and Secrets class generation. Over the years I've had a lot of discussions with developers using the Mobile.BuildTools and how they're using it. Obviously I've also had a lot of experience with my own projects and how I've needed to use the BuildTools to help my processes. It became apparent to me that this really needed a name change to more properly reflect how people use this class generation. There may be some client secrets that you want access to, but often times it's not super sensitive \"secret\" information like what scopes you're requesting from the OAuth provider, or the url for the mobile app service layer. \n\nAs I hinted earlier the configuration is all done with json. When you install the Mobile.BuildTools it will generate a buildtools.json in your solution root. The default configuration will enable a bunch of things for you, however Application Settings will not be one of them out of the box. So let's take a look at how this works.\n\n```js\n{\n \"$schema\": \"https://mobilebuildtools.com/schemas/v2/buildtools.schema.json\",\n \"appSettings\": {\n \"AwesomeApp\": [\n {\n \"properties\": [\n {\n \"name\": \"SampleProp\",\n \"type\": \"String\"\n }\n ]\n }\n ]\n }\n}\n```\n\nIn the configuration we can establish 1 or more settings classes to be generated in 1 or more projects within our solution. There is a lot of great content further explaining how to configure this on the [docs site](https://mobilebuildtools.com/config/appsettings/configuration/ \"Mobile.BuildTools Application Settings Configuration\"). A distinct advantage that this provides is that you are now able to define what properties belong in a generated class, what the data type is, and circumvent the problems encountered on certain build hosts like Azure DevOps Windows agents which like to cast all environment variables ToUpper... Additionally because it's described here, this gives other developers that you may onboard a single place to go to to see what they will need to setup.\n\n## The classic app.config\n\nIn the early days as I began prepping for the Mobile.BuildTools 2.0 I had a discussion with Chase Florell about some DevOps issues that he had been facing with his team at the time. To be honest it's not an uncommon issue. The issue was effectively there was an easter egg in the app where you tap 5 times, spin around on one leg, while whistling dixie... if you've been around building Xamarin apps for a while you may have seen or implemented this exact sort of thing. The easter egg was there to allow testing with production builds so that you could effectively take a build for QA and test against production, or take a production build from the store and make sure that it won't break against some Dev / QA version of the app's service layer. In this scenario an app.config makes a lot of sense to use, particularly when you have the ability to perform live transformations in the app. While there are some other very valid reasons to want to use app.config, whatever your reason, the Mobile.BuildTools 2.0 now makes this possible with it's own implementation of the ConfigurationManager. This is entirely interface based meaning that for those of you who love DI as much as I do, you'll be able to register the current instance with your container and work against the interface making it easier to test your code. To use this you will need to install the [Mobile.BuildTools.Configuration](https://www.nuget.org/packages/Mobile.BuildTools.Configuration/) package.\n\n## Image Management\n\nOk a dirty little secret of Mobile app development... you will likely hate whenever someone says you need an image because you need about 40,000 different resolutions of that one \\*\\*\\*\\*\\*\\*\\* image. Interestingly both [Jon Dick (@Redth)](https://github.com/redth) and I seemed to have gotten fed up with this and began pushing for a better user story on these features about the same time. While Resizetizer is fantastic and built into Maui, there are some issues that I still saw that could be a lot better. The first issue is that most developers I talk to share with me that they either just don't understand MSBuild properties at all or they feel intimidated editing a csproj file. This of course circles back to why I created a json configuration file to begin with. Again for an in depth look at what the Mobile.BuildTools can do for you, be sure to [checkout the docs](https://mobilebuildtools.com/images/). In short some highlights you get with the Mobile.BuildTools are:\n\n- Images do not need to live in any project\n- You can include one or more folders containing image assets\n- You can conditionally include images/image configurations based on the build Configuration or target platform (iOS/Android/UWP)\n- Supports JPEG, PNG, & SVG source images\n- Generate 1 or more output images. (handy for having thumbnail and full size versions)\n- Add a padding to any image (handy for those circle icons on Android)\n- Configure an image globally or have per platform overrides\n- Image source and target names do not need to match\n- You can add background colors to transparent source images (handy for those app icons)\n- You can add a watermark graphic to any image (they don't even need to be the same size, the Mobile.BuildTools will resize appropriately for you!)\n- You can add a custom text graphic to any image, with support for gradients, and full control over your colors and even what font you want to use (handy for having app icons with a banner like Dev, QA, or Lite, Pro, etc)\n\nBelow you'll see a sample of an image configuration for an app icon. When we build for iOS it will automatically pick up the AppIcon.appiconset, and generate all of the outputs defined in the json file for us. When we build for Android though it will generate 3 images for us. The first will be called icon and will be added as a mipmap resource. Next we'll get a launcher\\_foreground image, which will have a padding on it so that it displays nicely as a round image. Finally we'll get a copy of our original icon, but called notifications and will be available as a drawable resource instead.\n\n```js\n{\n \"$schema\": \"http://mobilebuildtools.com/schemas/v2/resourceDefinition.schema.json\",\n \"name\": \"AppIcon\",\n \"android\": {\n \"resourceType\": \"Mipmap\",\n \"name\": \"icon\",\n \"scale\": 0.1875,\n \"additionalOutputs\": [\n {\n \"name\": \"launcher_foreground\",\n \"resourceType\": \"Mipmap\",\n \"scale\": 0.28125,\n \"padFactor\": 1.5\n },\n {\n \"name\": \"notifications\",\n \"resourceType\": \"Drawable\",\n \"scale\": 0.1875\n }\n ]\n }\n}\n```\n\n## App Manifests\n\nFor your AndroidManifest.xml and Info.plist there are a couple of common issues I've always wished that could be easier. Luckily the Mobile.BuildTools makes it super simple now. By far the most common scenario every developer needs to address is App Versioning. Now with the Mobile.BuildTools you have a way to get your app to bump the version with every build. You can set this up to work only in CI environments, only outside of known build environments (your local machine), or everywhere. You can also set it up to use prefer a build number when available or use a timestamp. This means no extra build steps are required to bump the app version and no extensions like the [Mobile App Tasks from James Montemagno](https://marketplace.visualstudio.com/items?itemName=vs-publisher-473885.motz-mobile-buildtasks) for Azure DevOps. All you need to do is build and your app will automatically get a fresh app version!\n\nApp manifest manipulation doesn't always end there. There can be a variety of reasons why you might need to update values in your app manifest such as updating the app id based on the build environment (Dev, Stage, Prod). Other reasons could include scenarios where you're using Azure Active Directory B2C or similar OAuth library for user authentication and you either want to just make sure you're following good development practices by keeping the client id out of source control, or you need to specify different client id's based on build environment. Whatever your reason you can say goodbye to managing multiple copies of the manifest, or dealing with scripts and accidently checking in those changes to source control. The Mobile.BuildTools now allows you to tokenize your app manifest, and we will automatically search for and replace them based on values from your appsettings.json & environment variables. \n\n```xml\n\n\t\n\t\n\t\n\n```\n\nFor scenarios like this which clearly are not sensitive in nature the Mobile.BuildTools has another helpful feature in the config. You have the ability to define constants for the build environment which exist within the buildtools.json and will be used in the event that they do not exist in the system Environment or appsettings.json, and you can even have these be conditional just like with Images!\n\n```js\n{\n \"$schema\": \"https://mobilebuildtools.com/schemas/v2/buildtools.schema.json\",\n \"environment\": {\n \"defaults\": {\n \"AppId\": \"com.avantipoint.buildtoolssample\"\n },\n \"configuration\": {\n \"Debug\": {\n \"AppId\": \"com.avantipoint.buildtoolssampledev\"\n }\n }\n }\n}\n```\n\n## Next Steps\n\nLike I said there's a lot jammed packed into the Mobile.BuildTools, more than I could hope to go into depth on in a single blog post. It's designed to help simplify your DevOps processes by making it seamless between your local dev machine and CI build agent. Ultimately the best way to learn more is to get started by taking a look at the docs and adding the Mobile.BuildTools to your app.\n\n- [Mobile.BuildTools docs](https://mobilebuildtools.com/)\n- [Sample Apps](https://github.com/dansiegel/Mobile.BuildTools/tree/master/samples)","date_published":"2021-07-07T08:59:00.000Z","date_modified":"2021-07-07T18:20:03.000Z","tags":[".NET","Xamarin","DevOps","Xamarin Forms","Mobile.BuildTools"]},{"id":"https://dansiegel.net/post/2021/03/12/shiny-all-the-things-writing-testable-code","url":"https://dansiegel.net/post/2021/03/12/shiny-all-the-things-writing-testable-code","title":"Shiny all the things - writing testable code","summary":"Shiny all the things as they say. If you aren't using Shiny for your Xamarin.Forms or Uno Platform apps, the question is why? We see a lot of people excited...","content_text":"Shiny all the things as they say. If you aren't using Shiny for your Xamarin.Forms or Uno Platform apps, the question is why? We see a lot of people excited about UI libraries these days. While UI is always an important ingredient of any successful app, no app is complete without a resilient and testable architecture. This is one of the reasons why I use Shiny in all of my apps today. But what is Shiny, and why should you be using it?\n\n![Shiny all the things - writing testable code](/images/blog/shiny-all-the-things-writing-testable-code/01-image.webp)\n\nBefore we can look at that it's perhaps important to look at that thing that so many people fail to do... test your apps. Writing loosely coupled code is an important concept to master if you ever hope to write testable code. Using Test Driven Development is an important concept to help ensure that you speed up the development loop, and eliminate bugs, particularly in your business logic early. When we use loosely coupled code, using design practices that are intentionally Testable, and marry that with Dependency Injection we end up with an app architecture that is powerful, lightweight and robust. But what is Shiny? Is it true that it has a lot of overlap with Xamarin.Essentials? Why is it better to use Shiny than Xamarin.Essentials? How does Shiny help us build apps with loosely coupled testable code?\n\nThese are all great questions. While no single blog post could ever hope to fully explain these things in detail, hopefully by the end of this one you have a better sense for how to use Shiny to improve your app, write less code, and perhaps most importantly write tests that help you achieve your goals.\n\n### What Is Shiny?\n\nShiny is a collection of lightweight API's that help with common and specific requirements that many apps end up having to write complex solutions for. Between the Shiny Core and optional NuGet packages there are around 20 or so common things that Shiny will help with including Local Notifications, Push, Geofencing, GPS tracking, network Connectivity, foreground and background Jobs, and much more. By using Shiny you end up with lightweight, platform agnostic code that is written once instead of once for each target platform, and is ultimately easier to test.\n\n### Is it true that Shiny has a lot of overlap with Xamarin.Essentials? Why is it Better?\n\nI suppose this is all in the eye of the beholder. Shiny does indeed have some overlap, though both Xamarin.Essentials and Shiny have different goals and thus expose API's for different things. For example both have helpers that allow you to get things like the app Data directory or Cache directory path. Both have API's for determining the app's network connectivity state, and even Secure Storage. However Essentials will never try to deal with Bluetooth or Push notifications, while Shiny would never try to deal with Email, the WebAuthenticator, etc. \n\nBut this really brings us to the next question, why is it \"Better\"? Ok better might be a little harsh, and in full transparency I do quite often use Xamarin.Essentials together with Shiny as you'll see when we cover testing. Seriously though, why is Shiny often \"Better\" to use over Essentials? To answer that, we have to look again at the testability. Xamarin.Essentials has always taken the approach of Static API's that are cross compiled using a NuGet packaging technique commonly referred to as \"Bait and Switch\". What this results in is theoretical gain in performance at the sub-millisecond level (we're talking extreme tech geek level looking at bytes taken up in memory). In practice there is no practical gain in performance. However by referencing Xamarin.Essentials particularly from shared code you permanently loose the ability to actually unit test your code as the result is that your Unit Tests (running say netcoreapp or full framework .net) end up with the bait and switched version of the dll that simply throws a NotImplementedException or PlatformNotSupportedException... not really useful for testing your code. Even if you are running unit tests with a device runner on iOS/Android, you still end up with the problem that you cannot mock the return values of Essentials thus negating your ability to validate how your own code say handles various values you might expect. To get around this, you could simply use Xamarin.Essentials.Interfaces a community package from Ryan Davis that is generated for each release of Xamarin.Essentials, however there are still other benefits to using Shiny.\n\nSome of the notable benefits with Shiny is that it takes an interface first design approach. Additionally because Shiny uses Dependency Injection out of the box this means that you can instantly leverage what Shiny is doing and just simply inject the interfaces you require without having to register the interface / implementation or prevent the linker from stripping out the constructor of the implementation. Shiny additionally provides API's that are rich with an understanding of Reactive programming, providing you Observables over events which is much more powerful for scenarios like determining when the app is Online/Offline. For the sake of this article we won't go into that, but I would encourage you to learn more about Reactive programming if you have not already. Finally some of the API's such as Secure Storage are just easier to use, as we will see in a moment.\n\n### How does Shiny help us to write loosely coupled, testable code?\n\nThis is perhaps one of my favorite additions to Shiny v2, and honestly a feature I've been bugging Allan for since before the world changed with Covid-19. Shiny had always supported a concept of \"Settings\". These were things that you could implement a class for and through a little DI magic from Shiny, your class was instantly a persistent data store that you could provide settings values to and access them from one launch of your app to the next. So how did this work?\n\n```csharp\npublic interface IMyAppSettings\n{\n string Username { get; set; }\n}\n\npublic class MyAppSettings : ReactiveObject, IMyAppSettings\n{\n [Reactive]\n public string Username { get; set; }\n}\n```\n\nThe first thing we're doing here is providing an interface that simply provides some setting like the Username of the user for the app. The interface is basic, it describes the properties we care about without any care in the world of the fact that we might be storing these values with some persistence. Next we implement this, and choose a base class that also implements INotifyPropertyChanged. For this example I'm using ReactiveUI's ReactiveObject, and adding the Reactive attribute to the property, because I'm lazy, and the ReactiveUI.Fody package will update at build with the actual getter and setter. Now in our Startup we simply can register this with the IServiceCollection calling AddSingleton and provide the interface and implementing class. Shiny does the rest ensuring that it is properly bound so that IMyAppSettings will persist from one launch to the next with our app.\n\nYou might also note here that this is quite different from using Preferences in Xamarin.Essentials, as our class is simply a normal class implementing INotifyPropertyChanged. There is literally nothing special about it.\n\nThis is great but sometimes we might want to protect the setting. An example of this could be with the user's session token that we'll use to authenticate with our app's API. We might normally want to use the platform Secure Storage, but using something like this with Xamarin.Essentials would be difficult to implement as easily. For starters Xamarin.Essentials exposes this with an async API which doesn't mesh well with binding to Getters and Setters. There is technically a reason for this, and one that to be transparent doesn't work well for those targeting UWP in particular. As a result the Secure Store isn't supported by Shiny on UWP (but you could write your own provider and submit a PR to Shiny), however if you're targeting iOS, watchOS, tvOS, macOS, or Android this will work for you. So how do we do this with Shiny v2? The answer is with a completely re-architected concept of Settings to Stores. This allows us to similarly bind our implementation like we did with Settings in v1, but now we can choose a specific Store for Shiny. Let's look at how we might do this with Shiny v2.\n\n```csharp\npublic interface ISessionStore\n{\n string Token { get; set; }\n}\n\n[ObjectStoreBinder(\"secure\")]\npublic class SessionStore : ReactiveUI, ISessionStore\n{\n [Reactive]\n public string Token { get; set; }\n}\n```\n\nJust like with Settings from Shiny v1, we setup our interface and implementing class. Where it changes ever so slightly, is that by adding the ObjectStoreBinder attribute to our implementation and specifying the `secure` store Shiny will now transparently bind this to the SecureKeyValueStore when we register this with Shiny like:\n\n```csharp\npublic override void ConfigureServices(IServiceCollection services, IPlatform platform)\n{\n services.AddSingleton();\n}\n```\n\n### How this helps us write tests and be more productive?\n\n\"Test driven development\", it's one of those phrases that we have all heard, but all too often fail to do. If you've been around the Mobile Development world for more than 5 minutes you've probably figured out that it can take significantly more time to build for your device than to simply build a netstandard or netcoreapp project. Since our code is generally in a netstandard project and our tests are likely a netcoreapp this means that when we're writing tests we can much more rapidly build and execute tests to validate that our business logic is executing as expected. For the purposes of this post, I will be showing some code examples with xunit, but any test framework is fine. I will also be showing this using Moq, which is another fantastic Open Source library for helping you write unit tests that I encourage you to learn more about.\n\nNow let's assume that we have an Authentication Service that will need to use the SessionStore we created earlier. The Authentication Service has a Login method, and will use the WebAuthenticator from Xamarn.Essentials. Remember we want our code to remain testable so we instead need to reference Xamarin.Essentials.Interfaces and inject IWebAuthenticator instead of calling the WebAuthenticator directly. Our Authentication Service might look like:\n\n```csharp\npublic class AuthenticationService : IAuthenticationService\n{\n private ISessionStore _sessionStore { get; }\n private IWebAuthenticator _webAuthenticator { get; }\n private IAuthenticationConfiguration _authConfig { get; }\n\n public AuthenticationService(ISessionStore sessionStore, IWebAuthenticator webAuthenticator, IAuthenticationConfiguration authConfig)\n {\n _sessionStore = sessionStore;\n _webAuthenticator = webAuthenticator;\n _authConfig = authConfig;\n }\n\n public async Task Login()\n {\n if (!string.IsNullOrEmpty(_sessionStore.Token))\n {\n // We might also want to validate the session hasn't expired...\n return true;\n }\n\n var result = await _webAuthenticator.AuthenticateAsync(\n _authConfig.AuthUrl,\n _authConfig.CallbackUrl);\n\n _sessionStore.Token = result.AccessToken;\n return !string.IsNullOrEmpty(_sessionStore.Token);\n }\n}\n```\n\nNow when we go to test this there might be a few things we want to validate. Because this is using an interface instead of the WebAuthenticator explicitly, we now have the ability to leverage the Moq library to create a mock implementation that can provide callbacks into our code, and even allow us to simulate different responses, or even exceptions such as the TaskCancelledException. Let's get started with our first test. For this we want to validate that when we have a token our Login method will immediately return a true value and not call the WebAuthenticator.\n\n```csharp\n[Fact]\npublic async Task DoesNotCallWebAuthenticatorWithValidToken()\n{\n var store = new SessionStore\n {\n Token = \"SampleToken\"\n };\n\n var wasCalled = false;\n var webAuthMock = new Mock();\n webAuthMock.Setup(x => x.Login())\n .Callback(() => wasCalled = true)\n .ReturnsAsync(new WebAuthenticatorResult());\n\n var authService = new AuthenticationService(store, webAuthMock.Object, Mock.Of());\n\n Assert.True(await authService.Login());\n Assert.False(wasCalled);\n}\n```\n\nYou will notice that we can write a very clean test to continually validate that our AuthenticationService is ONLY calling the WebAuthenticator when we need. We've done with without any single reference to Secure Storage. While the Secure Storage may be a business requirement this is done in a loosely coupled way that does not impact or complicate our test in any shape way or form. Additionally because we're are creating our test cases here we can rapidly see if a change in code breaks our business logic, we can debug the test, and do so at a much faster pace than build, launch and stepping through out app just to hit our break point.\n\n![Shiny all the things - writing testable code](/images/blog/shiny-all-the-things-writing-testable-code/02-image.gif)\n\n### How you can get started with Shiny\n\nFirst and foremost I would encourage you to look at the sample app that is part of the [Shiny repo](https://github.com/shinyorg/shiny) (currently in the dev branch for v2). As you'll probably notice the sample leverages the power of building a loosely coupled app by additionally working with Prism and ReactiveUI/Rx principles. This shows how easy it is to build apps that combine the power of each of these libraries and frameworks to more quickly develop incredibly powerful apps. You can additionally choose to leverage the [Prism Container Extensions](https://github.com/dansiegel/Prism.Container.Extensions) with Shiny.Prism. For those who want to help make Open Source more sustainable you might also consider becoming a [GitHub Sponsor](https://github.com/sponsors/dansiegel) and leverage the incredible power of the Prism Magician via the Sponsor Connect package feed and additionally gain various code generators and Roslyn Analyzers to help you keep from making common mistakes while writing less code (since I do it for you). \n\n- Check out the [Shiny repo](https://github.com/shinyorg/shiny)\n- [Become a GitHub Sponsor](https://github.com/sponsors/dansiegel)\n- [Inquire](https://avantipoint.com/?utm_source=dansiegel.net&utm_medium=shiny-all-the-things-writing-testable-code) about Enterprise support for your Prism apps","date_published":"2021-03-12T08:30:00.000Z","date_modified":"2021-03-22T14:45:16.000Z","tags":[".NET","Xamarin"]},{"id":"https://dansiegel.net/post/2020/12/22/source-generators-an-exercise-in-futility","url":"https://dansiegel.net/post/2020/12/22/source-generators-an-exercise-in-futility","title":"Source Generators an Exercise in futility","summary":"Some time ago I did a live stream with Jérôme Laban from the Uno Platform team on Source Generators. This actually predated a lot of the more recent excitement...","content_text":"Some time ago I did a live stream with Jérôme Laban from the Uno Platform team on Source Generators. This actually predated a lot of the more recent excitement with the Roslyn based Source Generators that are now generally available as part of Visual Studio 16.8. As I got to learn more about Source Generators I quickly learned just how powerful they are.. because I'm lazy and dislike manually doing more than I have to (most developers I know are the same way).\n\n\n\nAmusingly out of our sheer laziness, we often have defaulted to falling back to runtime reflection. Of course there is a performance cost, that we generally like to dismiss because we can't build much more dynamic applications. To be fair this tradeoff also comes with some benefits for maintainability. With Source Generation though we can shift this reflective cost from the runtime to the build time. This means if we're going to pay a 1-2 second cost, let the developer or CI build take the hit instead of the app user every time they use our app. \n\nAs you may have noticed some of the runtime reflection that we added to Prism 7, rather suddenly was stripped out by Brian in Prism 8 after he learned about my side project the [Prism Magician](https://prismmagician.com/). The Magician was built using the techniques that I learned from Jérôme, along with a few other tricks I had up my sleeve. But hey the Roslyn team finally brought us Source Generation out of the box, so if we can get rid of a dependency why wouldn't we want to do that? Well get ready for the good the bad and the utterly WTF moments that come with that...\n\n## The Good!\n\nNaturally being something that is out of the box that just works is always a great thing. It's also fantastic that this builds on what we've already been doing, as we can now ship Source Generators as part of the same Roslyn Analyzers package that we may already be shipping, and at the very least we have a technique for packing these or including them in our project that is already being widely used. So far so good, no complaints right....\n\n![Source Generators](/images/blog/source-generators-an-exercise-in-futility/01-Picture1.webp)\n\n## The Bad...\n\nActually much to the Uno Platform team's credit with their Source Generation package, there is a recognition that there are a lot of common extensions you'll want/need when writing Source Generators. These come standard as part of the Uno.SourceGeneration package and are obviously not present when working directly with the Source Generators from the .NET team.\n\nNext up is actually just one of the general issues with Source Generation, which is that you're ultimately just using a string builder. While the Uno Platform team does give you an IndentedStringBuilder that you can use to more easily manage code indentation and blocks such as for namespaces, classes, methods, etc... again this is totally missing from the .NET team so you get an out of the box string builder. The good news on this front is that I do have a [CodeGenHelpers library](https://github.com/dansiegel/CodeGenHelpers) that you can include that really helps to more dynamically build your source code and generate clean output with a fluent builder approach.\n\n## WTF!!!!\n\nAs is often the case, docs and the actual API's are a bit out of sync to a point where the documentation literally says that you should expect behavior that was specifically dropped during the previews. Have fun with that one... So what is the behavior anyway? Well the behavior is that by default the Generators will not actually output the generated source to the disk. While the theory is that you can always navigate to reference, not all references will be in your code, and it can actually often be far more difficult than it should be to see what was generated, even where there are errors Visual Studio will generally not navigate to the Generated code. You can of course fix it if you know to add the following undocumented property to your project (the one consuming the generator). Note that adding this will add a generated folder in the temporary output (obj\\\\{targetframework}).\n\n```xml\n\n true\n\n```\n\nOk that's it, right??? Nope, not by a long shot... I did say earlier who wouldn't want to use the approach from the .NET team right... and after all as much as I love the work from the Uno Platform team, it's always nice to get rid of a dependency when you can (and when it makes some sense)... So I've spent the last few weeks working on a fairly significant rewrite of the Prism Magician so that it would do all of the Source Generation using the new Roslyn approach. It works marvelously on .NET Standard, and for both Xamarin.iOS and MonoAndroid targets.\n\nIt might seem like I've skipped a few targets. If you've been following me for a while you know I'm a maintainer for the Prism Library, and we love WPF and Uno Platform projects, and not just Xamarin.Forms. The Prism Magician is a fairly beefy solution, not so much because there are a ton of projects that need to get packed, but because there are about 16 test projects that test the Magician for Prism.Forms, Prism.Wpf, & Prism.Uno. So what happened?\n\nAfter finally completing the migration and getting all of the Prism.Forms projects stable, I was immediately blocked. While the generators did run for netstandard2.0 and Xamarin.iOS and MonoAndroid targets, no source was added for the UWP target in the Uno Platform test projects (although a generated folder was created). What's worse though is that the generators fail to run completely for WPF (you can track the issue [here](https://github.com/dotnet/wpf/issues/3404#issuecomment-682609361)). The issue has actually been know about since August but, hasn't exactly been discussed openly as a known short coming.\n\n## Final Thoughts\n\nSource Generators are amazing. For those of you building apps with Prism and who are able to target Prism 8, you should absolutely consider using the Prism Magician it will solve a ton of issues for you, and gives you a lot more than Source Generators. For everyone else look at areas that you currently fall back on runtime reflection and consider replacing it with a Source Generator. \n\nFor now though, it appears that the next release of the Prism Magician will have to include some shims to take the reworked generators and make them work with the Uno Source Generators.","date_published":"2020-12-22T12:26:00.000Z","date_modified":"2020-12-13T21:26:04.000Z","tags":[".NET","Prism","Xamarin","source generators","Roslyn","Uno Platform"]},{"id":"https://dansiegel.net/post/2020/05/07/icon-fonts-made-easy","url":"https://dansiegel.net/post/2020/05/07/icon-fonts-made-easy","title":"Icon Fonts made Easy","summary":"Coming from a Pre-Xamarin background of web development, I have always loved fonts like Font Awesome. Naturally I was pretty excited that Xamarin.Forms finally...","content_text":"Coming from a Pre-Xamarin background of web development, I have always loved fonts like Font Awesome. Naturally I was pretty excited that Xamarin.Forms finally added a FontImageSource to make it easier to use Font based Icons, but it still frankly was a pain to use. \n\n## Why Out of Box Is Terrible\n\nOk this might sound a little harsh, but to be honest even the geekiest among us don't go around memorizing and quoting unicode characters, so if you want to be able to use your custom icons you almost certainly need to create some sort of Mapping class.\n\n```csharp\npublic static class FontAwesomeBrands\n{\n public const string FontFamily = \"fa-brands-400.ttf\";\n\n public const string TwitterSquare = \"\\uf081\";\n public const string FacebookSquare = \"\\uf082\";\n public const string Linkedin = \"\\uf08c\";\n}\n```\n\nNow this is a little better because at least now we have made it human readable for which icon we're using and which font we've used... but it's still pretty verbose...\n\n```xml\n