Getting Started with Flow and VSCode

Normally when I do JavaScript development I leverage TypeScript, its been my goto for a few years now. But for a new project at work we are deciding to forgo Typescript and leverage pure JavaScript. As we are going to focus on using ES6 this is not a problem as much of the Typescript syntax is now available in ES6 (thanks to Babel we can transpile to ES5). But one thing that is not available is typing which sucks cause, having a type checker can really help developers avoid errors.

After much discussion we decided this is a great opportunity to play with Flow, which is a static type checker for JavaScript. The rest of this article will focus on getting flow running and VSCode validating your JS with type safety.

Let’s add Babel & Flow

Babel makes everything so nice, allows me to use the ES6 syntax in Node (v7.x has most of it but there are a few things). For Flow, it is recommended you install the following packages as dev dependencies:

babel-cli babel-preset-flow flow-remove-types

The last one can be confusing since their install docs do not call it out explicitly. In addition, you will want to add:

babel-preset-env flow-bin

Probably the trickiest thing for me was wrapping my head around flow-bin since it was not immediately clear. It basically allows you to have Flow locally in the project, which is the recommended approach over a global install.

Now, we need to update the package.json so that we can build using babel which will remove our type annotations. The command is simply:

babel src/ -d dist/

I am assuming here that all source files are in a directory called src and the transpiled final version will go into dist.

The final thing is to create the .babelrc file with the follow contents:

    "presets": ["flow", "env"]

These presets will strip out type annotations (since they are not valid JavaScript) and transpile our ES6 code into ES5 which is recognized by Node.

Integrating Flow

The absolute first thing you need to do is run the initialization script to create the default config file (.flowconfig) recognized by Flow.

yarn run flow init

You can leave this file be for the most part, wont be modifying it here.

Here is the code I wrote with flow:

/* @flow */

export default class Calc {
    static add(num1: number, num2: number): number {
        return num1 + num2;

    static sub(num1: number, num2: number): number {
        return num1 - num2;

    static mult(num1: number, num2: number): number {
        return num1 * num2;

    static div(num1: number, num2: number): number {
        return num1 / num2;

Its very simple and effectively creates a library of mathematical functions. Next, use this script as your index.js, I have included a couple type errors for flow to catch.

/* @flow */

import calc from './lib/calc';

console.log(calc.add("5", 6));
console.log(calc.sub(5, 6));
console.log(calc.mult(30, "20"));
console.log(calc.div(40, 20));

To run the follow command use yarn (or npm):

yarn run flow

You will need to invoke yarn (or npm) since, I assume, you used flow-bin package which means your Flow is packaged inside your project.

Against the code above, flow should pick out the two cases where a string was passed and the error is similar to what you would receive in a language like C# if you made the same error.

Add Some Scripts

The thing, as I said, about Flow code is its not JavaScript and so if you run it straight it will fail every time. The Flow preset from Babel stripes out the type annotations when building to leave valid JavaScript. Since this is the case, we should define an NPM script that we can run each time. Open package.json and add the following line to your scripts section.

“build”: “flow && babel src/ -d dist”

This command does two things:

1) it tells Flow to check the files with the @flow annotation for errors – if it finds any the process will fail.

2) it runs the code through Babel to both strip out type annotations (for all files under src/) and transpiles to ES5.

To execute this simply do

yarn build


npm run build

If you then examine the files under dist/ you will see a stark difference from the code you wrote; this is the power of Babel.

Let’s Configure VSCode

Ok, so at this point we can run everything from the command line, we get type checking and its all good, right? Well no. VSCode is probably going nuts because its still trying to parse the code in your .js files like its pure Javascript. We need to make it aware of Flow. Turns out, that is pretty easy.

Click the “Extensions” icon on the left hand navigation column and search for ‘Flow’. One of the items that will come up is Flow Language Support (below).


After installing you will notice the errors are still present. But why? Well, its because VSCode (correctly) assumes you are still working with pure JavaScript, we need to disable this. But because Flow is not a global part of our environment (and shouldnt be) we dont want to change settings for the editor, we want to do it for our workspace.

To do this, you need a settings.json file. Best way to create that is to indicate you want to override the default language settings.  First, click your current language from the lower right portion of the application status bar (below).


This will bring up a menu where you need to select to configure the language based settings for JavaScript (might also want to do this for JSX if you are using React and any other derivative JavaScript extensions).


This bring you into the settings.json file editor (it is a special file after all). From the right hand side of the top bar select ‘Workspace Settings‘.


You are now in your local settings.json file. Here is the absolute minimum that I recommend to support Flow.


flow.useNPMPackagedFlow just tells the extension to look in node_modules for the flow binary.

Basically, we are disable the internal JavaScript validator in favor of the Flow one. I do have a sidebar on this below since I believe you need to be aware of what this means. But regardless, after doing this, Visual Studio should cease seeing Flow type annotations as JavaScript errors. Congrats. That is it.

My Sidebar

I generally recommend that developers exclude .vscode from source control. However, there is an obvious problem in this case – without the settings.json file code will appear broken in VSCode for developers that dont have the right settings.

This goes one step further when everyone is using different editors (in our case we expect VSCode, Sublime, and WebStorm to be in play). Its not a huge deal really, you just need to make sure you communicate the usage of this library; I would really hate writing the type annotations just to get red squiggles all over my code, even though its valid.

So the point here is communicate and make sure that everyone can use Flow effectively. Its a great tool, but not something a single developer can use without the rest of the team, I feel, at least not easily or naturally.

Codestock and a New Focus

This past weekend Codestock was held in Knoxville, TN. I made my return after about 3yrs absent to present my Intro to iOS with Xamarin talk. The focus of this talk, much like when I gave it in Indianapolis for Indy.Code() was to highlight 3 fundamental competencies in iOS (View Controllers, Storyboards/Segues, and AutoLayout) and explain them as a Xamarin developer.

Overall, I was pleased with how the talk went and got great engagement from the audience about half of whom were mobile developers. Great end to the speaking year.

For those of you who do not know, I am getting married to the love of my life and my girlfriend of almost 4yrs later this year. As part of the planning, I decided I would not speak beyond August so, after being turned down for BeerCityCode and ThatConference I decided that Codestock will be my last public speaking engagement outside Chicago for 2017 as I focus on the wedding. But it goes beyond that.

Recently, I have decided to shift my focus at West Monroe Partners and return to my roots as a backend developer. It’s not that I dislike Xamarin or that I see mobile as a dead end, I just like to change it up every few years – a big reason why I stay in consulting. With that being the case, I look forward to returning to the speaking circuit in 2018 with a focus on AWS, Azure, Docker, Nodejs, C# and the other myraid of tools that are used on the backend.

Thank you to everyone who came to my talks this year and thank  you to the various conferences that allowed me to speak to their awesome attendees. Every time I get accepted it is always an honor.

See you in 2018

AWS DevOps with .NET – Part 1

I have found that DevOps is a crucial part of any development team as it takes a lot of the operational burden out of the hands of developers allowing them to focus on writing code. Additionally, it can make sure that certain testing and verification is done each time, every time, consistently, which improves the overall QA cycle.

We had a project at West Monroe about a year ago that had us deploying .NET code to Amazon AWS; as a side note the client maintained control and access to Amazon, we did not have access to this. During this process, we continued to use Azure as the main deployment engine. Thus, we had to perform communication with Amazon using Powershell scripts. It was rather painful.

As it happens, Amazon has their own suite of DevOps tools for their platform:

  • CodeCommit – A Git Repository for your projects
  • CodeBuild – A build engine for your code
  • CodeDeploy – Deploy your code to EC2 instances
  • CodePipeline – Provide end to end CI/CD for your application

So I decided I wanted to see how their products stacked up so moving forward I, and West Monroe developers, could use Amazon’s tools if the deployment target was going to be Amazon. For this first part, I will only be covering CodeCommit and CodeBuild because I have yet to get the CodeDeploy process to work.

Before I get started I would like to make a few things clear:

  1. CodeBuild does NOT support .NET Standard, but as .NET Core can run on Linux we can build .NET Core apps, but not full .NET apps, at least yet.
  2. Amazon requires a host of YML files be present in your application for these processes to work. While the documentation does mention them, I feel it could be a lot clearer.

So, lets get started.

Creating your Git Repository

Each developer on your team should have their own local account to log into the AWS console with appropriate rights set. If they are going to be developing code ensure they have the AWSCodeCommitPowerUser policy. Note: It is also acceptable to use the AWSCodeCommitFullAccess policy however, I think only one user should have this policy as normal developers should not need full access, just the ability to interact with the repository. Note: you will need to have full access to actually CREATE the repo, or you can use the root account.

Next, ensure each user has the IAMSelfManagedServiceSpecificCredentials and IAMReadonlyAccess policies. The former allows them to update the credentials for specific services (CodeCommit in this case) while the IAMReadonlyAccess policy enables them actually access IAM in their AWS console. Here is a screenshot of what my group CoreWebUser looks like:


I have also included AWSCodeBuildDeveloperAccess because, later on, I will want this account I am using to be able to start builds using AWS CodeBuild, but more on that later.

Each user who will be a developer needs to generate their Git credentials (that is what the two policies above enable). To do this, each user must login and go into IAM select their user from the Users table.

There is a tab on the subsequent page called Security credentials, the Git credential section is all the way at the bottom. Per Amazon policy, the password is going to be a lot of gibberish for security, make sure to save these credentials somewhere.

Let’s create the repository

Now, lets create that repository – head over to Services -> Developer Tools -> CodeCommit. Once you create the repository Amazon will prompt to cover the steps that we covered above. The important thing here is the clone URL which is your Git remote (or where you will push and pull remote code from).

And thats pretty much it. Poking around on my own SampleApp I have been pretty impressed, especially with the Visualizer which duplicates the branching that I have seen in both SourceTree and GitKraken on the web. A deeper look at this product is outside our scope. This is the easy step, next we move on to the moderately hard step of building the code.

For my code base, I used the default .NET Core web template by running this command

dotnet new web

I then made a simple modification to the hard coded response string. I then pushed this to CodeCommit on the master branch.

Got the Code, let’s build it

As of this writing, AWS does NOT support .NET builds meaning, you will NOT be able to select a Windows machine. This being the case ANY scenario involving .NET Standard is out. What we CAN do is leverage .NET Core which runs anywhere, including Docker and Linux which CodeBuild can support.

With any remote build process the first thing I always tell people to do is UNDERSTAND your own build process and make sure it works locally. Because if you dont understand or it doesnt build locally its MUCH harder to get it to build remotely.

To that end, I suggest building your local version first so you better understand this process. So let’s build it, run this command:

dotnet build

If you run this, you will notice the application does not build (or if it does you somehow ran the next step :)).  We need to run a restore to bring in the packages to support our app. Run this command then rerun the build command.

dotnet restore

The reason I had you do this was so the build sequence was understood because we have to create a YAML file to explain this to Amazon. Amazon’s tools rely heavily on these sorts of files. Create a new file called builldspec.yml. It has to be this name and it HAS to be at the root of your application, no exceptions. Here is an example of mine:

version: 0.1

      - dotnet restore
      - dotnet build
    - bin/Debug/netcoreapp1.1/*
  discard-paths: yes

A full specification of this file is located here:

I cannot stress enough the importance of the format of this file. Follow the spec EXACTLY and use tabs where you see indents. The errors provided if you dont do this is very cryptic and speaks to “number of containers”. Follow the format.

You can see how why I explained the restore then build for .NET core apps. This spec file will ensure Amazon runs those those same commands. Now push this into your remote repository.

Setting up the Build

As with CodeCommit you will need to under the policies attached to the users to access this. Also, like with CodeCommit you have policies for general use, read only, and admin.

  • AWSCodeBuildAdminAccess – This policy should be given to one user. And you will need this policy to create the build project.
  • AWSCodeBuildDeveloperAccess – This policy should be given to most of your developers, unless there is a reason you want some to not be able to start builds, in which case they should either have no policy for CodeBuild or they should have the AWSCodeBuildReadOnlyAccess policy.

Once you have this set, we can  head over to Services -> Developer Tools -> CodeBuild in the AWS Console and start the real fun. First step is easy, create the project (make sure you are using either the root user or the user with AWSCodeBuildAdminAccess).

Now, let’s go section by section:


This section is pretty self explanatory. Project name is required, description is not. Fill it in and move on.


For this section start off my selecting AWS CodeCommit in the Source Provider drop down. You will notice there are other options as well. We wont cover them here.

Once you select the CodeCommit source AWS will display a second dropdown with the Repositories available, pick yours.

This section is complete, let’s move on.

This next section is where the fun part is. When I started this process I roughly knew what Docker was, now I have a better idea, still a bit hazy but noticing something on the .NET Core Setup page helped this along. Here is what my section looks like:


The key here is the Custom Image ID which we specify as the Docker image that Microsoft maintains with the latest version of .NET Core. Remember what we said earlier, .NET Standard is NOT supported here because it MUST be run on a Window machine (Mono not withstanding). .NET Core is designed to run ANYWHERE and since Docker only really support Linux images its ideal for this situation.

The path microsoft/dotnet:latest refers to the Microsoft Docker container and the ‘dotnet’ image there. You can use Amazon ECR which is a Docker esque service that provides containerized instances, but I found this much easier 🙂

Notice the Build specification setting. We could have also specified a sort of build script using the second option but I prefer the YAML approach since not understanding would pigeon-hole you when your build process becomes complex.

Enough with this section, lets move on.

When you run a build on any platform you generate output, in the land of DevOps we refer to this output as Artifacts, this next section helps CodeBuild understand how to handle your artifacts. Here is my configuration:


In this example, I am using S3 as the output location. You will need to create the bucket that I have listed. The one interesting point here is the Artifacts name. Now here, I gave the explicit which is intentional as I intend to create a Zip file as the final artifact. However, this feature must be set in the Advanced Settings (shown next) and the name will be literal. That means, you need to supply the extension, even if you tell CodeBuild you want it to Zip the output.

Moving on.

Next we need to define the service account that will actually run the build. What is important here is that the role that is used (and Amazon can auto-generate it if the user has the permissions) have the rights to access the OTHER Amazon services as needed (S3, in this case, if you choose to put your artifacts there). Here is what mine looks like:


Once you complete this setup, you should go into IAM and ensure this role has the ability to access S3, otherwise the build will fail.

Moving On.

I mentioned previously that you need to tell CodeBuild that it should Zip the artifacts the build process outputs. Expand Show advanced settings.


The important thing here, as indicated by the arrow is the Artifacts packaging option which will tell CodeBuild to zip, thereby matching the extension we provided previously.

That’s it. Now we can start a Build

Here is the output from my build:


If we go to S3 we can access our bucket and even download the Zip file and verify its contents.

Where do we go from here?

So, we have our application building and yeah, its a pain in the ass and extremely limiting that we cant use this with .NET Standard but its something and I do tend to think that .NET Core is the way of the future, especially for web apps given the flexibility it allows in deployment. My next post, hopefully sometime this week, will focus on using CodeDeploy and CodePipeline to complete the end to end process. For the moment, I am still fighting with them.

Overall, I have found Amazon to be acceptable but, the reality is if you are going to use .NET you really should have a profound reason for not using Azure. The integration with Microsoft’s tools far exceeds anything you will get with Amazon. Plus, we havent even covered the appsec.yml file which is required, I think, to use CodeDeploy. This contrasts heavily with Azure where much this is taken care of for you. Part of that is Microsoft coverage of its own language and Amazon being language agnostic more or less and not favoring one platform over the other.

I look forward to completing my understanding of this process, if for no other reason than to continue to enhance my understanding of the AWS platform and its various features.

Hybrid Xamarin.Forms Applications

When Xamarin.Forms was announced and released by Xamarin it represented an interesting take on their platform. The problem it attempted to solve was one that was becoming increasingly common in the mobile space and it represented a fair attempt to solve it. However, as a developer I do not consider Xamarin.Forms a replacement for the user of traditional Xamarin, just as I do not consider Xamarin a replacement for native development; all things have their places.

All that being said, Xamarin.Forms can give you some pretty cool advantages, one of which is the ability to design one code base and get decent rendering on multiple platforms. This makes it ideal for simple applications lacking significant customizations of the platform.

Most often, developers apply this advantage at a macro level, which is the designed purpose. However, if you consider that within complex applications you may have simple screens that do not gain any advantage from being developed in native code and that the potential of MIXING screens could yield a productivity benefit. This is what I have been looking at with Forms. I wanted to share with you what I found.

Understand the basic flow

Any mobile application represents an exercise in information architecture with the goal being to create the most efficient user flow possible. If you decide to mix screens, you have to really consider the order of your screens.

My advice for now is, assume that Xamarin.Forms will still control the navigation of your application at a high level. In some cases you may go from native page to native page, but even then, you want to do so while managing the Forms navigation flow. The rest of this article will assume this.

Custom Renderers

Each element that you see on your screen in Forms is drawn by a Renderer and one of the pillars of Forms customization is the notion of Custom Renderers whereby you can plug your own logic and perform custom rendering; this is the approach we will be using. When dealing with Custom Renderers you always want to define a custom control first. This will serve as a marker that will help to invoke your renderer.

public class NativePage : Page
     public string KeyName { get; set; }
     public string IosStoryboardName { get; set; }

     public NativePage()
          IosStoryboardName = "Main";

The properties on this class are used by the renderer to make sense for the various platforms:

  • KeyName – a unique name for the view or viewcontroller we will load for this page
  • StoryboardName – is specific to iOS and allow us to extract the related view controller out of a storyboard. The default of Main is used as the convention that most iOS developers use for their default storyboard.

For Xaml, we use this control as such:

<controls:NativePage xmlns="" xmlns:x="" xmlns:controls="clr-namespace:NativeTransition" x:Class="NativeTransition.LoginPage" KeyName="Login">

By itself, this will do nothing. In fact, you could add normal content here and it would render as Forms normally does. This is because, by default, Xamarin.Forms registers a Renderer called PageRenderer for the Page class which is what does all of the magic. So, if Forms comes across a custom control it does the following:

  • Attempts to find a Renderer registered for its specific type name
  • Attempts to find a Renderer registered for its base class
  • Attempts to find a Renderer registered for its base class’ base class
  • And so on

So, our next step will be to define a Custom Renderer, and we should do this for each supported platform. If we dont, the above sequence will be applied.

About Custom Renderers (a few words)

Principally Custom Renderers are organized around two methods

  • OnElementChanged – called each time the primary element changes (that is it is initially created or a property is changed from its default value)
  • OnElementPropertyChanged – called each time the value of a property changes on an established control. This is used frequently to support custom data binding scenarios.

Generally, these methods are available in some form or another for each renderer you will create. The biggest point to understand about these methods, in particular with OnElementChanged, is that they are called multiple times. So, generally you want to setup some logic to ensure initial creation logic only runs one time.  Here is an example:

if (e.NewElement != null && e.OldElement == null)
     // Your Creation logic here

Having your creation logic inside this logic will ensure it is called one time and keep your rendering processing efficient.

The iOS Custom Renderer

With iOS, our goal is going to be to look at our KeyName and extract that ViewController from our storyboard. Once we have this ViewController we call some method to indicate to iOS that it is hosting our View Controller. As developers, we will be able to work with this View Controller as we would normally.

var keyName = (e.NewElement as NativePage)?.KeyName;
var storyboardName = (e.NewElement as NativePage)?.IosStoryboardName;
var viewController = BuildViewController(keyName, storyboardName);

// do the iOS thing to make it like the View Controller
ViewController.View.Add(viewController.View);				viewController.DidMoveToParentViewController(ViewController);

For simplicity, I have dropped my various null and parameter checks, but you will obviously want to code defensively here. The properties being used are defined on our custom Xamarin control in the XAML.

As for BuildViewController, its very simple and familiar to anyone who has done iOS for any amount of time.

UIViewController BuildViewController(string keyName, string storyboardName)
     var sourceStoryboard = UIStoryboard.FromName(storyboardName, null);
     var viewController = sourceStoryboard.InstantiateViewController(keyName);

     return viewController;

Once extracted, the view controller can be utilized as any normal View Controller in iOS would be, nothing special is required for Forms.

The Android Custom Renderer

Android is a bit more complicated, mainly because of how the windowing system works in general. Truthfully, Android is more well geared towards doing this sort of thing than iOS is, because we could have separate activities that represent different Forms applications. But like many things with Forms, it is made harder because you are abstract two different platforms. (If Xamarin would introduce a FormsViewController for iOS, I think the two could be made similar, but that is another conversation).

As we know, Android presents its view mainly though Xml layouts and Forms leverages a sort of dynamic view generation technique to accomplish this, I believe. In our case, we will want to use KeyName to dynamically load a view from our Resources folder. Here is the core logic:

var keyName = (e.NewElement as NativePage)?.KeyName;
var activity = Context as FormsAppCompatActivity;

_layoutView = BuildLayoutForKeyName(keyName);
var pageView = (LoginPageView)Activator.CreateInstance(typeof(LoginPageView));

// support view interaction
   activity, (e.NewElement as NativePage).Navigation, _layoutView);

So, this is where things get tricky because of the way Android is handled by Forms. In iOS, we get to work with full ViewController but in Android, everything is loaded into a single Activity, effectively replacing the ContentView each time, so we can expect to get an Android activity each time. This is the reason for the PageView concept which we will cover later.

Using the KeyName value, we attempt to find a layout whose name matches this value, inside BuildLayoutForKeyName.

Android.Views.View BuildLayoutForKeyName(string keyName)
     var id = Context.Resources.GetIdentifier(
          keyName.ToLower(), "layout", Context.PackageName);
     return (Context as Activity).LayoutInflater.Inflate(id, this, false);

Notice I have some leftover code as you would want to check for both forms of casing, not just assume lowercase, though you could as that is the standard in native Android.

The final bit is to adjust the size of the view as Android perform its layout operation, we do this using OnLayout lifecycle hook. As a note, I got this code off a Stackoverflow answer, but its pretty clear what it is doing.

protected override void OnLayout(bool changed, int l, int t, int r, int b)
     base.OnLayout(changed, l, t, r, b);
     var msw = MeasureSpec.MakeMeasureSpec(r - l, MeasureSpecMode.Exactly);
     var msh = MeasureSpec.MakeMeasureSpec(b - t, MeasureSpecMode.Exactly);

     _layoutView.Measure(msw, msh);
     _layoutView.Layout(0, 0, r - l, b - t);

Ok, using this approach will get our view to show up but, we have no way to interact with the View from the renderer, unless we create a dedicated renderer for each NativePage type which does not make a lot of sense. That is why I introduced the PageView concept.

The PageView

The idea behind PageView is not revolutionary, basically at a certain point we will pass off the generated View to a class whose sole purpose is to configure and setup the view. To be fair, there is a lot more we need to be able to do with Android views, so my approach here is still lacking, but its a fair start.

public class LoginPageView
     private FormsAppCompatActivity Activity { get; set; }
     private INavigation Navigation { get; set; }

     public void PrepareView(
          FormsAppCompatActivity activity, INavigation navigation,
          Android.Views.View view)
          Activity = activity;
	  Navigation = navigation;

               (Resource.Id.loginButton).Click += login_click;

     void login_click(object sender, EventArgs e)

So, a few things that certainly need to change with this approach:

  • Its totally hard coded to LoginPageView. Since we cant use generics with renderers due to the export syntax not being amenable to it, we would need to specify it somewhere. My leading through is a convention based notation where I look for PageView and activate that.
  • It doesnt allow you to take advantage of the Android lifecycle methods. This is a big no no. My current leading thought is moving View inflation to this class as a base responsibility. But bringing the lifecycle methods over will remain tricky.

Definitely Android is a work in progress but, using this, you can create native Android interactions in your own custom View class without needing to reference Forms, though there is certainly more coupling with Forms here than there is in iOS.

Navigation back to Forms

So the cool thing here is, despite the fact that you are in native code, you are technically still in Forms, because all that is happening is Forms is rendering your Page as a native page. So, we can still use the standard Forms navigation techniques. For example, in Android you might do something like this:

async void login_click(object sender, EventArgs e)
     await Navigation.PushAsync(new PeopleListPage());

In iOS, you can do the above OR you can use traditional iOS navigation if you want (via PresentViewController). The reason this works is, under the hood all Forms does with each navigation is replace the RootViewController. Example:

partial void loginClick(NSObject sender)
          new PeopleListPage().CreateViewController(), true, null);

To be fair, these are very simple scenarios that I have been testing, under normal application development, this may or may not work. But, remember, this sort of approach is designed to enable SOME screens to be Forms based and shared, not a large variety of them. Always consider your goal and what makes the most sense. Overusing this approach will lead you to problems.

Closing Notes

I want to once again reiterate that this approach should be used to augment your Traditional or Forms based applications. I do NOT advocate this being a 50/50 split, more like a 70/30 or 80/20. The navigation concerns alone suggest a high degree of caution when build apps with this feature.

The final note I would like to make is that this approach has gained a lot of popularity and Xamarin has taken notice. They have it tentatively planned to be in the 2.4 release of Forms. I say tentative because even they admit this is a hard problem to solve, but we all know it has some very strong advantages. It will be interesting to see how they support his use case, if they ever officially do.

Mobile Center vs Bitrise

At West Monroe one of the biggest pain points we had with developing mobile applications was we lacked an effective DevOps process. That all changed in April last year when we adopted Bitrise; nothing but smiles for the most part on this end.

One of our early attempts was to use the build engine in Visual Studio Online to carry out builds, but this came with the requirement to host a Mac Build Agent on-prem. To be frank, this was a clusterfuck. During the pilot project I spent as many hours over the first three weeks trying to keep it running as I did actual development work. Eventually, we terminated the pilot and went naked without a build process; our quality suffered. It was towards the end of this project that we brought Bitrise into the fold.

I will save you reading the whole article: Bitrise beats Mobile Center right now. Bearing in mind that Mobile Center is still in Preview this isnt surprising as it lacks any maturity (they just added VSTS support a few days ago). But the direction does look good and it does have managed Mac build agents so that is a huge plus over Visual Studio Online.

From my early experiences using it, this is still very much a work in progress and I am communicating a ton of feedback to the team; I even got early access to the VSTS connector by complaining on Twitter. But the end result is the same: Btirise is leaps and bounds ahead of Mobile Center at the current time. Will Mobile Center get there? Possibly. One of the great strengths of Bitrise is the Step library which has both curated and independently submitted Steps; we use a lot of these on more complex projects.

By contrast, Mobile Center has no flexibility and only a single build path that can be leveraged, little customization. Also, while Bitrise’s dashboard lets you see In Process and past builds, Mobile Center focuses on showing ALL remote branches and bubbling those performing build actions to the top; I find this busy.

However, I see a lot of runway for Mobile Center because of what it offers beyond a simple build engine: integrated analytics, crash reporting, and distribution. No having to use HockeyApp as a separate app. Having everything centralized makes a lot of sense, but if the build processes are not feature rich it wont be worth it; personally given the number of tasks available in VSO its hard to believe this wont change soon.

So, for right now, I would not even consider using Mobile Center for anything but the simplest of projects where the support was limited and the scope diminished. Its not ready to join the big boys….yet.

Adding DevOps for GiftList

One of my aims with my GiftList project is to build sensible CI/CD support processes to enable easy deployments as I continue to develop the API. In addition, one of my aims is to move away from pure mobile dev and return to my roots as a backend developer while maintaining my strong focus on solid development techniques and processes.

Setting up the build

The first step was to setup the build such that I could confirm that I didnt miss a build error with a given checkin. VSO makes this incredibly easy using the Build Solution task; just remember to have it follow a Nuget Restore task.

I always recommend using individual build configurations for each build type, it just makes it easier to be more selective as you move through the process. I use to recommend this as a way to change your connection string at each stage but, this is falling out of practice as Cloud can hold your credentials and do the replacement for you. Such an approach maintains the “wall” between development and production so the credentials for Production are known only by the cloud and select individuals.

Adding the Unit Tests

So apart from adding the unit tests (128 as of this writing) which took me a month after I had completed a majority of the API code. But honestly, this worked out well as going back and adding the unit tests found a few bugs that I would have otherwise missed.

In terms of organization I have always been a big fan of the “give an instance … verify …” pattern where you attempt to construct logical sentences describing what is being tested with the class name and method name. Example:

given an instance of itemcontroller call getitems verify bad request is returned if id is empty guid

This allows the first portion of this to describe the general action being tested which is calls to getitems on the itemcontroller. The second portion indicates what test case we are exploring, bad request is returned if id guid is empty in this case. This approach enables good organization when you have hundreds and hundreds of tests. It also helps prevent accidental duplication.

Now, once I added the tests I needed to instruct VSO to actually run those tests as part of the build. To do this, you need to tell the task WHERE tests are located. Tests CAN be added as part of your projects but this means this code will get added to all versions of the assembly (you could remove it with a PreProcessor directive) which would inflate the overall size of the application. My preference here is to add new assemblies with a .Test suffix. I then instruct my other build profiles to NOT build these beyond development.

Once you do this, configuring the VSO tasks is rather easy. Here is a screenshot of mine:


Remember, the default setting in Visual Studio is that the DLL name matches the project name, so this works here. The ** means recursive.

Truth is, even with this your tests will not run if you are not using MSTest. In my case, I was using NUnit and I needed to ensure I had the TestAdapter Nuget package referenced (there are two versions, one for 2.x and one for 3.x – use the one correct one for your version).

Now I have 128/128 tests passing.

Let’s deploy it

So this proved to be the most difficult part for me, but it gets to be easy for you now. First, make sure you are publishing your artifacts using the Publish Artifacts task. Documentation here is kind of sparse but what you want to do is publish your output directory (mine is /bin) to a staging directory which we can use for a release.


Here is what my task looks like. The key here is the Artifact Type which I have set to Server which indicates the artifact is stored on the build server. The artifact name will represent the directory, remember it for the next step.

Ok, so it used to be that when you ran your builds if you also wanted to deploy you would code that as part of the steps. While it works, it is actually not a good strategy since it made built processes less reusable. In seeing that Microsoft has now added a second section called Releases. Releases contain you release workflows, they are independant of your Build workflows.

I am still exploring this environment but, it appears to be full featured and allows signoff for builds. For my example, I just want to deploy to my Dev environment whenever the build changes. All this takes is the Deploy Azure App Service task. Here is my configuration:


Most of this is simply selectable, very easy. Once you authorize the task it can pull your subscriptions and from that it can get your App Service instances. Really the hardest part was the Package or Folder bit, which once I got the Publish working worked great. Here is an example of what the … brings up if your Publish is working properly.


Very easy. You notice the lowest folder matches the Artifact Name from the Publish.

All in all, very easy to set this up. WIthout the time to add all of my unit tests, probably took me 2hrs tops to create this process end to end while doing other things. Hat’s off to Microsoft, cant wait to see what is coming next.


I had the chance this year to be a speaker at the inaugural Indy.Code() event in Indianapolis, Indiana. I was accepted to present two talks with a mobile focus: Intro to iOS (with Xamarin) and Intro to Android (with Xamarin). My goal with each talk was to talk less about Xamarin and focus more on the foundational concepts of the individual mobile platforms: iOS and Android.

For iOS I spent a lot of time focusing on the use Xcode as the means to build the UI for iOS apps and also how Xamarin registers its types with iOS so they can be used. I tend to stay away from the Xamarin iOS Designer due to the performance differences between it and Xcode, I also do not like how certain design aspects of iOS are represented there (Auto Layout in particular).

Beyond this, I covered how Storyboards have changed the game when designing iOS applications and how they integrate with TableViews, Navigation, and overall design. I then dipped the audiences toes in the vast topic that is AutoLayout.

I will be presenting this topic again at CodeStock in May.

For Android, which is a topic that, relative to iOS, I have much more experience with I had a much harder time breaking things down just to sheer volume and the changes that have taken place in the platform since its inception. I started off talking about Activities and how we can use annotation in Xamarin instead of registering them directly in the Manifest file.

I spent much of the time helping the audience understand the various features Android offers to deal with the fragmentation of the platform, in particular the density classification and relative pixel definitions that enable you to get 90% of the way there; I even had an example where I showed how a different layout can be defined for various traits of the platform: layout, density, sdk. Beyond, I showed an example where we used the RecylerView and Fragments to construct and Album information lookup app.

Both presentations were well received and the event was done very well. I am hoping to submit next year if they have it again. However, as I have previously noted, I am starting to move away from my mobile focus and returning to my focus as a backend developer so I can leverage my Azure knowledge and AWS certifications moving forward.

Indy.Code() too place March 29 – 31. Apologies for the delay.