New Open Source Projects

I’m working on a new application that’s going to be open source.  Once it’s a bit further along I’ll provide more details, but essentially it’s a paperless forms solution that encompasses a WPF desktop app, a self-hosted ASP.NET WebAPI service and a Xamarin Forms mobile app all working together.

In the process of getting the foundation up and running, I’m moving a lot of stuff over to Github, but more importantly I’m updating, extending, and creating whole new libraries that can be used for other stuff.  These, too, are open source.

What’s being updated?

    I’m primamrily working with SQLite, but I’ve already uncovered and fixed some issues around one-to-many entity relationships
  • OpenNETCF.IoC
    Work and updates to make it more Xamarin/PCL friendly
  • OpenNETCF Extensions
    This thing has been stable and in heavy production use for years.  Support continues for it with some minor changes and improvements in the Validation namespace so far.

What’s New?

  • OpenNETCF.Xamarin.Forms
    Adding things that I’m finding missing or hard in Xamarin’s BCL.  Things like “hey, scale this label to the right size depending on my screen resolution, on any platform”.  Thanks go out to Peter Foot for pointing me in the right direction there.
    No idea why Xamarin didn’t provide a basic navigation framework.  I created one.  Is it awesome?  I don’t know – but it works for my use case (plus 3 other apps I’ve done with it).
  • OpenNETCF.Google.Analytics (moving to it’s own repo soon)
    Again, seems like low-hanging fruit here.  Why isn’t it in the box?  I don’t know, but there’s now a simple, open source library for it.

One note – these are all in active development, so don’t expect a NuGet package updates on them for at least a little while (end of May?).  I’d like to get features in and stable before rolling them out.

Feedback welcome. Testers wanted.  Enjoy.

IoC Navigation Sample for Xamarin Forms

The OpenNETCF IoC Library provides a simple and lightweight MVVM Navigation framework for Xamarin Forms application navigation (along with a lightweight DI container).  I’ve blogged a couple examples on how it can be used, but I thought that a more complete example, with full downloadable source code would be a bit friendlier and easier to get your brain around.

With that, I decided to build out a very simple framework for a fairly typical application scenario.  I didn’t make the views complex, nor did I do work to add graphics or anything fancy.  I wanted it to show just what is necessary to show how you might go about creating the application framework and all of the navigation that would be associated.

Some highlights of what the application contains:

  • A Login view that accepts a Username and Password
  • A Home view that has
    • A button for a menu (typically it would be a hamburger icon)
    • A Summary data item that when clicked navigates to a Details view
  • A slide-out left Menu that:
    • Is activated by a left-to-right swipe or clicking on the menu button
    • Has a button that, when clicked, navigates over to a Settings view

The application launches to a Login view.  Once logged in, you end up on a Home view that has a slide-out menu in the left and a “summary” item on the main view.

In the menu is a “settings” button that will take you over to a settings screen.  Clicking on the summary item in the Home View takes you over to a details view.

The source code for the example can be found in source control under the Examples/NavigationExample folder.

This sample required a couple updated to the IoC library, so you’d need to have 1.0.16215 as a minimum (which is what is in source control anyway).  You can get the IoC Library right from NuGet.

Xamarin Forms Navigation with OpenNETCF IoC

The OpenNETCF IoC library has been around for a long time.  I needed a DI container that was simple and fast that provided some cool features like event aggregation and module plugins.  I still use it heavily in every project I work on.

When I started working with Xamarin Forms, I still needed a DI container.  Now I know that Xamarin provides one, but I already know how to use OpenNETCF’s IoC and the syntax for it is pretty much muscle memory for me at this point.  I didn’t want to learn a new paradigm when the one I have solves the problem just fine and it will let me continue to use the same syntax on Windows desktop, Web APIs, Xamarin and still the occasional Windows CE project.

The lack of Reflection support in a PCL assembly forced me to rework things a bit, so I lost event aggregation and plug-ins, but it’s still a really simple and fast DI container that supports both singletons and named instances.

What was missing, however, was a navigation structure.  So I created one and added it to the Xamarin build of IoC.  Here’s a very, very quick overview of how you can use it.

The NavigationService class is the root of what you’ll you and it’s a static to make it easier to use.  I don’t want or need to create or find an instance of it every time I want to use it.

The first step is to create a View/ViewModel pair.  The View must derive from Page.  The ViewModel must implement the provided IViewModel interface (which simply implements INotifyPropertyChanged and nothing else at this point).  Basically it’s a near drop-in for any Xamarin Forms project.

So let’s assume I have a simple app with two pages: Home and Detail.

I’d create the following classes: HomeView, HomeViewModel, DetailsView and DetailsViewModel.  The Views are just the out-of-the-box Pages.  The ViewModels would simply derive from IViewModel and add in the PropertyChanged event (which you probably have already).

Setting things up for using the Navigation service is straightforward.  You simply register the View/ViewModel types.  Note that you don’t actually create any instances of the Views or ViewModels:

NavigationService.Register<HomeView, HomeViewModel>();
NavigationService.Register<DetailsView, DetailsViewModel>();

This registration tells the NavigationService the relationship so that when you need to display a View, it can ensure that the ViewModel also exists and then it can inject it as the BindingSource for you.

Once we’ve registered our Views and ViewModels, we can start up the app like this:


Things to note here are that we don’t directly set the Application.MainView, we simply tell the navigation service the Type we want to use.  We also pass in true here as a parameter to tell the service we want it to wrap the Page in a NavigationPage for us.  If your MainView already derives from NavigationPage, you’d pass in false. Yes, this could probably be made automatic, but for now it’s not.

Now that you have you main page, you can navigate between pages forward and back.  For example, to go from the MainView to the DetailsView, you’d use this (true telling the NavigationService to show animation for the navigation):


And if you’re on the DetailsView and you want to go back?  That’s as simple as this:


On Software Development: Moving from statics or instances to a DI container

I’ve recently started refactoring a customer’s code base for a working application.  They recognize the need to make their code more extensible and maintainable so I’m helping to massage the existing code into something that they will be able to continue shipping and upgrading for years to come without ending up backed into a corner.

One of my first suggestions was to start eliminating the abundance of static variables in the code base.  In this case, static classes and methods abound, and it looks like it was used as a quick-and-dirty mechanism to provide singleton behavior.  Now I’m not going to go into depth on why an actual singleton might have been better, or the pitfalls of all of these statics.  Write-ups on that kind of thing about in books and on line.

Instead, let’s look at what it means to migrate from a static, an instance or a singleton over to using a DI container, specifically OpenNETCF’s IoC framework.

First, let’s look at a “service” class that exposes a single integer and how we might consume it.

   1: class MyStaticService

   2: {

   3:     public static int MyValue = 1;

   4: }

And how we’d get a value from it:

   1: var staticValue = MyStaticService.MyValue;

Simple enough.  Some of the down sides here are:

  • There’s no way to protect the Field value from unwanted changes
  • To use the value, I have to have a reference to the assembly containing the class
  • It’s really hard to mock and cannot be moved into an interface

Now let’s move that from a static to an instance Field in a constructed class:

   1: class MyInstanceService

   2: {

   3:     public MyInstanceService()

   4:     {

   5:         MyValue = 1;

   6:     }


   8:     public int MyValue { get; set; }

   9: }

Now we have to create the class instance and later retrieve the value.

   1: var service = new MyInstanceService();


   3: // and at a later point....

   4: var instanceValue = service.MyValue;

We’ve got some benefit from doing this.  We can now control access to the underlying value, making the setter protected or private, and we’re able to do bounds checking, etc.  All good things.  Still, there are downsides:

  • I have to keep track of the instance I created, passing it between consumers or maintaining a reachable reference
  • I have no protection from multiple copies being created
  • The consumer must have a reference to the assembly containing the class (making run-time plug-ins very hard)

Well let’s see what a Singleton pattern buys us:

   1: class MySingletonService

   2: {

   3:     private static MySingletonService m_instance;


   5:     private MySingletonService()

   6:     {

   7:         MyValue = 1;

   8:     }


  10:     public static MySingletonService Instance

  11:     {

  12:         get

  13:         {

  14:             if (m_instance == null)

  15:             {

  16:                 m_instance = new MySingletonService();

  17:             }

  18:             return m_instance;

  19:         }

  20:     }


  22:     public int MyValue { get; set; }

  23: }

And now the consumer code:

   1: var singleTonValue = MySingletonService.Instance.MyValue;

That looks nice from a consumer perspective.  Very clean.  I’m not overly thrilled about having the Instance accessor property, but it’s not all that painful.  Still, there are drawbacks:

  • The consumer must have a reference to the assembly containing the class (making run-time plug-ins very hard)
  • If I want to mock this or swap implementations, I’ll got to go all over my code base replacing the calls to the new instance (or implement a factory).

How would all of this look with a DI container?

   1: interface IService

   2: {

   3:     int MyValue { get; }

   4: }


   6: class MyDIService : IService

   7: {

   8:     public MyDIService()

   9:     {

  10:         MyValue = 1;

  11:     }


  13:     public int MyValue { get; set; }

  14: }

Note that the class is interface-based and we register the instance with the DI container by *interface* type.  This allows us to pull it back out of the container later by that interface type.  The consumer doesn’t need to know anything about the actual implementation.

   1: // Note that the Services collection holds (conceptually) singletons.  Only one instance per registered type is allowed.

   2: // If you need multiple instances, use the Items collection, which requires a unique identifier string key for each instance

   3: RootWorkItem.Services.AddNew<MyDIService, IService>();


   5: // and at a later point....

   6: var diValue = RootWorkItem.Services.Get<IService>().MyValue;

Mocks, implementation changes based on environment (like different hardware) and testing become very easy.  Plug-in and run-time feature additions based on configuration or license level also are simplified.

New IoC Feature: Shell Replacement

One limitation with using the SmartClientApplication as a basic for your IoC application is that it locks you in to the type of Form that’s going to be displayed when your app starts up.  In most cases that’s really not an issue, but sometimes you’d like to decide at runtime what UI to display.  You might even want that UI to come from a dynamically loaded DLL.

Well I just added a new capability to the SmartClientApplication.  During the startup process, the framework now looks in the Services collection to see if you’ve already registered a Form deriving from the new ShellReplacement base class.  If it finds one, that form will be shown instead of the type passed into the SmartClientApplication.  The effectively gives you a “default” main shell form, with the ability to dynamically load a different one based on whatever criteria you want.  We’re using it to support vertical-specific UIs for the Solution Engine, meaning that if you have the HVAC module installed you’ll get one UI but if you have the Telematics module installed you’ll get another.

The implementation details are as trivial as I could think of making them.  First, create your new shell Form like this:

   1: public partial class HVACMainView : ShellReplacement

   2: {

   3:     public HVACMainView()

   4:     {

   5:         InitializeComponent();

   6:     }

   7: }

Then register it as the replacement when your Module loads:

   1: public class Module : ModuleInit

   2: {

   3:     public override void AddServices()

   4:     {

   5:         RootWorkItem.Services.AddNew<HVACMainView, ShellReplacement>();

   6:     }

   7: }

That’s all there is to it.  You can disable the feature by using the EnableShellReplacement property (defaults to true) of the SmartClientApplication.  Get the latest change set (69942 or later) to try out the new feature.

OpenNETCF IoC Update

I’ve released version 1.0.12221 of the OpenNETCF IoC framework.  Not a whole lot new going on – it was primarily bug fixes – but binaries for all supported Platforms (Full framework, Compact Framework, Windows Phone and Mono for Android) are included.  If you’re using it, how about showing me some love and rating it (other than “Have not used it yet” – what kind of review is that?).