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?).

OpenNETCF IoC Project Templates

I’m trying my hand at making using some of our stuff a bit easier.  Today I burned some time trying to understand the project template infrastructure and the result was the creation of a couple VSIX files for installing IoC templates into Visual Studio. 

Right now it only supports desktop projects (IoC supports Windows Phone, Mono for Android, Monotouch and Compact Framework). I’ve also not figured out how to actually deploy the IoC and Extensions binaries with the templates, so when you create your project, the References section will contain IoC references, but they’ll be broken.  Still, as a first cut it greatly simplifies setting up a new IoC UI (SmartClientApplication) or IoC Module project.

You can install the templates in one of three ways:

OpenNETCF IoC now supports Mono for Android (MonoDroid)

In my push to get our fundamental libraries up and working on Mono for Android we’ve added support for OpenNETCF Extensions and OpenNETCF IoC.  What that means is that now you can have a common code for a lot of application infrastructure that works on the Compact Framework, the desktop, Windows Phone, MonoTouch for iOS and Mono for Android.  So you can now create a single, common code base for your applications that includes data access, event aggregation, dependency injection and inversion of control.

Get the latest code over on Codeplex.

Compact Framework and the Visual Studio Designer

Lately it seems that I’m been doing a lot of posts referring to “a customer”.  Often they are different customers, but it really sounds impersonal, so in this one I’m going to name names and point fingers – in a friendly way, of course.

Last week Nicolas emailed me to get some advice on the Visual Studio 2008 Forms designer and the Compact Framework.  Specifically he wanted to know if it’s possible to get a custom TabControl to be designable.  My assumption is that either he’s inheriting from the stock version or they’ve created a fully custom control inheriting from ContainerControl – I didn’t ask because in either case the answer is simple: it’s not going to work in the designer.

I told him that it won’t work, but in retrospect I feel I’ve short-changed him a bit.  As a developer, I like to hear a bit more than an “abandon all hope, ye who sail here for there be sea monsters” kind of response.  Why doesn’t it work?  More importantly, what are my options for a workaround?

In this case it’s interesting to note that even if he could get the designer to work for this control, I’d recommend that he not do it.  And they why to that recommendation is far more interesting.

So, Nicolas, here’s the longer answer to your question.

First, you have to understand that the Studio Designer is very, very brittle.  Any little quirkiness tends to send it into fits, and once broke you often spend large amounts of time unloading things, resetting the toolbox, restarting Studio or even restarting the PC.  This is a huge time drain, so avoiding situations that break the designer is the first order of business.

Getting the designer working for a CF component is even worse.  CF controls often make use of things that the desktop doesn’t even have, which the designer really hates.  You also have to build the Controls for both versions of the CF (for Nicolas this is important since, at least last time I was with his team, they had versions of the application targeting CF 2.0 and CF 3.5).  A control built against CF 3.5 will never show up in the designer of a CF 2.0 project.  There’s also a major bug in the designer that limits CF 3.5 controls that I’ve written about before.

For designer support you also have to maintain an XMTA file and often end up having condition compiler statements which really make the code less readable.  Workarounds for most of these issues exist.  You can create separate set of “designer” assemblies that provide only stuff for the designer and minimal actual control logic.  The problem with this is that you then have to maintain these things, which sucks up developer time that should be spent actually solving your business problem.

You can’t create a desktop assembly and use it for the designer because the designer will then suck in the full .NET framework as a reference and attempt to deploy that to the device when you want to debug.

So if the designer is so brittle and worthless, what’s a developer to do?  Well, my general attitude is to provide “support” only for basic Controls, and by “support” I mean the inherent capability of the designer to show a box with the location and bounds of your control.  No rendering.  No styling.  No collection editing. 

Really the designer’s primary use for me is to aid in basic layout.  I need to put a Control on a Form, set it’s location and Size and that’s it anyway.  Anything else is done via code, and there’s nothing wrong with this.  Embrace it as how you must work and your life becomes much simpler.

That’s all well and good for a simple Control, but what about a container like Nicolas is after?  His team would like to be able to drop on a Tab control and design each individual Tab, right?  So what are they to do?

Well, I think they’re looking at the problem wrong to begin with.  I don’t blame them, people have been looking at this wrong for some time, and the simple existence of the TabControl tend to push people to look at it wrong.  In general, my recommendation is to not use the TabControl in the first place. 

First of all, it’s 2011.  That ass-looking TabControl would have been ok back in 1995 (if the devices had existed then) since it looks just like the ass-looking Windows 95 interface. 

It’s was an ok solution in 2000 when these devices were new and people thought of them as just “mini PCs” so extending the desktop paradigm to the device was what we did.    Yes, we wished we could do a little more to make it pretty by adding icons and custom drawing, but it worked and users really didn’t expect anything more.

But it’s 2011.  Users don’t use a stylus if they can avoid it.  They know an elegant UI when they see one because they’ve been using a smartphone.  Just because they have no choice in the app they use (this is an LOB app, so the user is locked in) is no excuse to not deliver something that is actually nice to use.  The TabControl does not meet that.  It’s tiny, it scrolls weird, and it’s ugly with no options to make it non-ugly.  Plus it’s  Tab motif.  Name the last mobile app you used on a phone that used tabs.  That’s what I thought. Abandon the piece of crap.

So what would I use?  Obviously this will be subjective, as it’s what I would personally do given a blank slate.  Nicolas is trying to put something into an already-existing, very large code base, so his mileage may vary, but I’m betting it won’t be too bad, and implementing this might actually do a lot toward getting other gains they really need like better transition time between views.

I’d start using the OpenNETCF IoC project.  I’d split each of the existing “tabs” into individual SmartParts, which are now fully designable since they’re just UserControls.  So there you are – the designer requirement is solved.  I’d then place on the Form a pair of DeckWorkspaces.  One would display the “selected” view and the other would replace the “tabs” of old with buttons or clickable images that would be used to select the current view.  It would look something like this in the designer for the Form:


And then the SmartPart that goes into the bottom workspace might be something like this in the designer (well it would probably be a bit different, but you get the idea):


See, the designer works.  It meets the business requirement that it provides a “tab-like” capability where the user selects an item across the bottom and the upper view changes.  But now it’s not just usable with a stylus but it’s also likely to be usable with a finger (gasp!) and aesthetically it doesn’t make my want to poke my own eyes out.  It’s a win-win.  Plus now you can lazy-load the views *on demand* rather than loading up every damned control on every tab when the Form is brought up, so the user is going to be pleasantly surprised there too.  Oh, and now it’s easy to change out “tabs” based on user rights or workflow and probably other benefits that I’m not thinking of.

Occasionally we’ve got to break out of the “what we know” and the “what we’ve always done” routine and look out at the horizon.  By doing so we can often make some simple changes and make things easier for both the developer and the user, and that is how we make progress.