Com.MarcusTS.UI.XamForms 2.0.6

.NET Standard 2.0
Install-Package Com.MarcusTS.UI.XamForms -Version 2.0.6
dotnet add package Com.MarcusTS.UI.XamForms --version 2.0.6
<PackageReference Include="Com.MarcusTS.UI.XamForms" Version="2.0.6" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Com.MarcusTS.UI.XamForms --version 2.0.6
The NuGet Team does not provide support for this client. Please contact its maintainers for support.
#r "nuget: Com.MarcusTS.UI.XamForms, 2.0.6"
#r directive can be used in F# Interactive, C# scripting and .NET Interactive. Copy this into the interactive tool or source code of the script to reference the package.
// Install Com.MarcusTS.UI.XamForms as a Cake Addin
#addin nuget:?package=Com.MarcusTS.UI.XamForms&version=2.0.6

// Install Com.MarcusTS.UI.XamForms as a Cake Tool
#tool nuget:?package=Com.MarcusTS.UI.XamForms&version=2.0.6
The NuGet Team does not provide support for this client. Please contact its maintainers for support.

Xamarin.Forms Specific

A Light-Weight Framework for Modern, Animated Apps Using Responsive Tasks

 

We have said -- more than once -- that a framework is a way of doing something very badly while pretending to save time. Projects like Prism break more rules than a guest with Tourette's Syndrome at a tea party. They claim to "take care of the coding for you". But they do it by violating design principles and coding standards. Those ideals aren't just "polite rules for nice people". They are what make an app safe, reliable, manageable, scalable, affordable, and user-friendly. Design is everything.

A real framework would leverage design principles to create a light-weight programming platform that promotes an exciting, involving user experience through an animated UI. It would cure Xamarin's limitations. It would aspire to greatness, but without trying to take over the world.

That's where our humble library comes in. It isn't a black box. It is tiny compare to so-called frameworks. You can easily modify it or combine it with other tools. Let's compare approaches to other coding paradigms:

Topic How We Handle It How They Handle It
The Task Parallel Library   Head-on; ResponsiveTasks repairs broken TPL roots. We can even wait for void without hanging your app.  "I see nothing! Nothing!" Dozens of bad threads racing constantly    
C# Fundamentals   100% compliant. No redundancy. All interface contracts.   "Magic" file names illegally glue view models to views; if they don't match, the app crashes at run-time. Extreme redundancy (2 million lines worth!) Few interface contracts.    
Navigation   Independent App State Manager identifies the app state using a set of handy string constants. View Presenter uses the app state to determine what view and view model should handle it based on run-time conditions. Flexible, open, and dynamic.   Tired, old "web" style menus and back-stack with rigid, hard-coded views and view models. Navigation occurs from a view model directly; this is illegal, since a view model cannot know what other views actually exist.    
Page Management   Simple, single-page app with views that flow in and out like actors on a stage. Elegant, powerful, and light-weight coding. Fully animated.   Heavy-weight pages are constantly shuffled in and out with disruptive, ugly transitions. Virtually no animation. Like dancing with an elephant.    
Views / Controls   Auto-generated views; can actually build an app with virtually no code in the view model except for simple attributes.   Horrid, redundant, impossible-to-maintain XAML; focus on static development. Almost no actual code re-use and no way to control code bloat.    
Editing / Input Strategy   Animated, floating placeholders for input fields. Flexible validation behaviors. Colorful cues below the field explain exactly what they must do for a proper input. All views validate as a group automatically.   Extremely tedious, verbose, old-style edit fields with clunky responses -- often through jolting modal dialogs. Extreme coding complexity.    

We Even Produced a Complete Demo App

For (a lot more detail on how we do this for you, see the Modern App Demo on GitHub. (This is not a NuGet library because it is not re-usable as a component. Just download the code and customize it as you see fit. It is 100% runnable with a few demo views.)

Yes, You Can Still Use XAML

{Sigh}

The code in this project responds to any generic type. That can be a view created in XAML or in code:

protected async Task ChangeContentView<InterfaceT, ClassT>(object viewModel)
    where ClassT : View, InterfaceT
    where InterfaceT : class
{
    { code omitted }

    await ChangeTheContent().WithoutChangingContext();

    // PRIVATE METHODS
    async Task ChangeTheContent()
    {
        var newView = _diContainer.RegisterAndResolveAsInterface<ClassT, InterfaceT>();

The Modern App Demo consumes this in the Master View Presenter:

   public class MasterViewPresenter : 
       MasterViewPresenterBase, IMasterViewPresenter
   {
      protected override async Task RespondToViewModelChange(object newModule)
      {

         if (newModule is IDashboardViewModel)
         {
            await ChangeContentView<IDashboardTitledFlexViewHost, 
            DashboardTitledFlexViewHost>(newModule).WithoutChangingContext();
         }
         else if (newModule is ISettingsViewModel)
         {
            await ChangeContentView<ISettingsTitledFlexViewHost,
            SettingsTitledFlexViewHost>(newModule).WithoutChangingContext();
         }
         else if (newModule is IAccountsViewModel)
         {
            await ChangeContentView<IAccountsTitledFlexViewHost, 
            AccountsTitledFlexViewHost>(newModule).WithoutChangingContext();
         }
         else if (newModule is ILogInViewModel)
         {
            await ChangeContentView<ILogInTitledFlexViewHost, 
            LogInTitledFlexViewHost>(newModule).WithoutChangingContext();
         }
         else if (newModule is ICreateAccountViewModel)
         {
            await ChangeContentView<ICreateAccountTitledFlexViewHost, 
            CreateAccountTitledFlexViewHost>(newModule).WithoutChangingContext();
         }
         else if (newModule is ICreationSuccessViewModel)
         {
            await ChangeContentView<ICreationSuccessTitledFlexViewHost, 
            CreationSuccessTitledFlexViewHost>(newModule).WithoutChangingContext();
         }
      }

Simply replace any of these calls to ChangeContentView with a class and interface pointing to your XAML file.

The Path from SharedForms to Here

You can still use our original SharedForms library for your apps. This library leverages some of it, but in most ways, supercedes it due to the inclusion of the Response Tasks Library. Once you have included a NuGet reference for this project, you might not need to directly reference SharedForms again.

This Project Is Open Source; Enjoy Our Entire Public Suite

Shared Utils (MAUI Ready!)

GutHub

NuGet

The Smart DI Container (MAUI Ready!)

GutHub

NuGet

Responsive Tasks (MAUI Ready!)

GutHub

NuGet

PlatformIndependentShared (MAUI Ready!)

GutHub

NuGet

UI.XamForms

GutHub

NuGet

The Modern App Demo

GutHub

 

Product Versions
.NET net5.0 net5.0-windows net6.0 net6.0-android net6.0-ios net6.0-maccatalyst net6.0-macos net6.0-tvos net6.0-windows
.NET Core netcoreapp2.0 netcoreapp2.1 netcoreapp2.2 netcoreapp3.0 netcoreapp3.1
.NET Standard netstandard2.0 netstandard2.1
.NET Framework net461 net462 net463 net47 net471 net472 net48
MonoAndroid monoandroid
MonoMac monomac
MonoTouch monotouch
Tizen tizen40 tizen60
Xamarin.iOS xamarinios
Xamarin.Mac xamarinmac
Xamarin.TVOS xamarintvos
Xamarin.WatchOS xamarinwatchos
Compatible target framework(s)
Additional computed target framework(s)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
2.0.6 63 5/16/2022
2.0.5 54 5/8/2022
2.0.4 55 5/7/2022
2.0.3 247 10/30/2021
2.0.2 136 10/29/2021
2.0.1 230 10/28/2021