Xamarin.Forms Plugin – Unobtrusive FluentValidation

Xamarin.Forms Plugin – Unobtrusive FluentValidation

Background

One of my all time favorite libraries is FluentValidation, Jeremy Skinner has done a great job at producing a library that is easy to use and just works.  Whether it is trivial validation or complicated databases access validation, FluentValidation has the means to get it done; while keeping your validation away from your view.  I won’t go into depth on why one would need/want to separate validation from a view in this post, but I might make another post in future describing in detail why that is important.

This post will assume a basic understanding of MVVM and ASP.NET’s MVC Framework with a little common knowledge of javascript.

The Problem

During my expedition as a Xamarin developer, I’ve seen and tried many different forms of validation.  Some were great and some were just good, but they all seemed have different approaches on when or where the validation gets triggered.

From my experience the best user-interface one can offer when validation is a small and effective means of communication.  Not multiple popups with fancy emoticons of sad faces.  People already don’t like to click on their phones (just look at the most popular apps, they just scroll), so why force them to click an ‘X’ or an ‘okay’ button?  Just tell the user what they should do to correct the form and move on.

The Solution

So one night I decided to blend what FluentValidation.MVCX has to offer with Xamarin.Forms.

Enter the first Unobtrusive FluentValidation Plugin for Xamarin.Forms!

Now this plugin is built on top of the latest FluentValidation NuGet published version.  There isn’t anything that is specific with this version, just needed a starting place. If you need an older version, please let me know and I’ll do my best to support older versions.

Check out the code on GitHub and get the latest version from NuGet!

 

Take care and have a great day!

MSBUILD vs. Web Deploy & Automation

So you’re here, probably on your third or fourth cup of coffee and struggling to automate the deployment of your web site(s). Don’t worry you’re not alone, I alone went threw an entire box of K-cups by the time I finally found the answer! You probably started out with using MSBUILD and the “DeployOnBuild=true” parameter for your publish profile and at first all was great! Your files were in the right location (maybe) and the site was up and running in IIS with no issues, minus the whole authentication hole you created (our secret). So you tried your mad Google skills and stumbled upon Web Deploy which looked extremely promising; but long story short, it fell short or your thinking there has to be a better way of doing this!?!?

And your right there has to be a better way! But first lets understand what MSBUILD and WebDeploy are…

Continue reading “MSBUILD vs. Web Deploy & Automation”

SignalR, Autofac, OWIN, and MediatR — How to play nice

If you’re finding this post odds are that you’ve found some of the latest greatest (as of now) tools and concepts storming through the .NET world, but you’ve stumbled upon something that just doesn’t seem right.  Congratulations, you’re a developer now!  But seriously lets get to why you’re here.  This post will be an ever-evolving documentation of the issues I’ve stumbled upon and hope it helps you in quest to greatness!  Grab another cup of coffee and lets start stirring up our code.

OWIN Integration

So OWIN (Open Web Interface for .NET) is all the craze for ASP.NET web developers and it is for a good right.  Not to get into the specifics of why you should use it and the whole mantra behind it, just use it in any new applications.  So that is were I was a few days ago, I started a new application for fun and began integrating all the normal NuGet packages I did two years ago (been a while for web development).  I quickly learned how much I was left behind; it was time to put some mud boots on and begin digging around.  Lets see what was dug up!
Below is the basic of a Startup class for OWIN.

public class Startup
{
     public void Configuration(IAppBuilder app)
     {
     }
}

Everything we do to setup our site is basically an extension method off IAppBuilder; which allows us to do some pretty neat things. So starting from the top, we’ll want to register SignalR and we’ll end up doing the simplest registration to get it up and running:

public void Configuration(IAppBuilder app)
{
     app.MapSignalR();
}

Pretty easy right!

Autofac & SignalR

Awesome, now lets register Autofac as our dependency resolver using OWIN. Majority comes from Autofac’s documentation on SignalR found here.

public void Configuration(IAppBuilder app)
{
     app.MapSignalR();

     var builder = new Builder();
     //For us lazy people:
     builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());

     var config = new HubConfiguration();

     // Register your SignalR hubs.
     builder.RegisterHubs(Assembly.GetExecutingAssembly());

     // Set the dependency resolver to be Autofac.
     var container = builder.Build();
     config.Resolver = new AutofacDependencyResolver(container);

     // OWIN SIGNALR SETUP:

     // Register the Autofac middleware FIRST, then the standard SignalR middleware.
     app.UseAutofacMiddleware(container);

     app.MapSignalR("/signalr", config);

     var builder = container.Build();
}

Looks good right? In fact it does, so you run it but your not able to access your SignalR hubs.   Getting an error with resolving something like:

“Microsoft.SignalR.IMessageBus messageBus can not be resolved”

WHAT IN THE WORLD!?!? Yea very bizarre issue, but that’s how you found this post!

The issue is actually with our registration calls (go figure).  The culprit is (drum roll)…

builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());

That’s right our awesome AnyConcreteTypeNotAlreadyRegisterSource is causing an internal conflict with SignalR’s resolver.  Now I’m not sure (yet) why this is happening under the hood, but I’ve managed to figure out a solution.  AnyConcreteTypeNotAlreadyRegisterSource has an overloaded parameter that takes in a delegate which can solve this issue:

public void Configuration(IAppBuilder app)
{
...
     builder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource(TypeRegistation));
...
}

private bool TypeRegistation(Type type)
{
    if (type.FullName.StartsWith("Microsoft.AspNet.SignalR"))
         return false;
    return true;
}

That’s the ‘magic’ to make it work. When ever Autofac tries to resolve a concrete type, it will pass the type through this method and expect a boolean on whether or not it may instantiate that type. Since, we do not wish for it to resolve anything with SignalR, we simply check that FullName starts with “Microsoft.AspNet.SignalR”.

I hope this section helps save some hair in the world!

Till next time!

Microsoft & ETL (SSIS)

So this post is a bit different as it doesn’t relate to mobile or web development particularly, but is more of a conceptualization and analysis.  Recently, I’ve been tasked to move and summarize large sets of data; we’re talking tens of millions of records, resulting in hundreds of gigabytes of space needed.  At first I took a rudimentary approach which involved in writing a console app in C# using ADO.NET.  I won’t even going into using an ORM (Object Relational Mapper) like Entity Framework, lets just say: they’re not efficient in this scenario.

Continue reading “Microsoft & ETL (SSIS)”