Microsoft introduces Mobile Center

As announced yesterday at Connect #MSFTConnect, Microsoft plans to merge several acquired products into a new product, named Visual Studio Mobile Center. It will be, as they call it, a mission control center for your mobile apps. Nowadays Microsoft has several products scattered over several ecosystems and they plan to bring it together in one product.

So what will it contain? Well as you might know Microsoft acquired HockeyApp in late 2014. HockeyApp then joined forces with the Application Insights team. They strengthened their vision on crash reporting and gathering analytics for your apps. I have even heard that in the near future you should be able to correlate your analytics from your App with the analytics from your back-end. This will bring new exciting insights into your software. Next to that HockeyApp is also great at beta testing and distributing your Apps, I personally don't expect that Microsoft will change a lot here, but that's only for the better since it already works excellent in HockeyApp.

Crash Telemetry in Mobile Center 

With the acquisition of Xamarin in February this year Microsoft joined forces with one of the major mobile frameworks out there. I think it completes their vision on Cross Platform development. With .NET running on almost every device Microsoft development ecosystem became much stronger. But with the acquisition of Xamarin, Microsoft also bought Xamarin's Test Cloud. Its a cloud of real devices where you can run your Calabash or UITest tests on. Its very powerful but the downside is that its a little ecosystem on its own. Microsoft announced yesterday that Test Cloud will also be part of the new Visual Studio Mobile Center. Moving it into a merged ecosystem will enhance our productivity and reduce the numbers of accounts that we have to make and licenses that we have to buy. I even expect that the business model of Test Cloud will be changed to pay-per-use, just like in lots of Azure components, instead of the 3 license levels they now provide. Hopefully this will be the case!

Test Cloud in Mobile Center

I also want to point out an very important quote by James Montemagno. He said that the build flow in Mobile Center works completely out of the box without configuring a Mac build agent and that you "Don't have to worry about Mac or PC's". This is a major improved because nowadays I have to spin up my Mac build agent every time I start developing my iOS app. It would be a great addition if it works out of the box and that I only have to worry about writing code :)

One quick downside I noticed in the presentation is the fact that it doesn't support Cordova. I saw Xamarin, React Native and Objective-C / Swift. I'm not sure why Microsoft didn't include Cordova in it because they are still busy with the TACO tools in Visual Studio. Maybe it will be added in the future, hopefully.

So Mobile Center looks great and I can't wait to play with the preview. Let me know what you guys think!

Mobile DevOps using Xamarin

After working with Xamarin for a decent amount of time I thought it would be useful to a lot of developers to share my experience with the platform and its ecosystem. I will discuss the matter based on a DevOps approach, since that is the approach I took. Note that I understand that there is much more to DevOps and that I'm covering only a small part of it.

So I decided to learn Xamarin and the company that I work for supported me by buying me a Xamarin license with University access. After watching a couple of courses I decided to jump in the
deep. I started with Android because I had some experience with native app development on Android. It surprised me that the Xamarin development experience was remarkably close to developing native on Android. Xamarin does a great job on matching the original native's development experience. And that was exactly the moment that I took a deeper dive into Xamarin. I wanted to know how Xamarin could match the native environment and how its works under the hood.

What Xamarin does is, is that they have created bindings that actually match Native UI calls. The .NET runtime will call the native OS features and, as misunderstood sometimes, will definitely not emulate them. This is one of the major advantages of Xamarin over web apps such as Cordova. The user will actually experience a native look and feel instead of a web based UI. Don't get me wrong web based UI's can have great user experience too but its hard to match the performance and user experience of the native controls.

So how is Xamarin able to call Native UI features from a .NET runtime? And does this work both on Android and iOS? Well the two platforms take a different approach. Lets start with Android. Android Apps normally run the Android Runtime(ART). Its a Java virtual machine that's comparable to the .NET runtime. It also got JIT compilation and is able to execute dynamically created code. Xamarin Apps build for Android supply a second runtime next to the ART runtime, namely the Mono runtime. Mono is able to execute .NET compiled code, named IL(intermediate language) and JIT compile and execute it on the fly. The guys at Xamarin also added Android bindings to the runtime which enable you to execute ART code from your .NET code. This is the real power of Xamarin. It basically enables you to run .NET code in your App and next to that also use .NET code to execute native Android code which normally is only available in the Android Runtime.

But whats the difference with iOS? Well Apple has made a very important restriction on iOS, namely:

However, there is a security restriction on iOS, set by Apple, which disallows the execution of dynamically generated code on a device.

This restriction basically excludes JIT compilation from iOS, which is a fundamental part of the .NET runtime. This forced Xamarin to take a different approach on iOS. They came up with Ahead of Time(AOT) compiling, which is an alternative to Just in Time(JIT) compiling and is fundamentally different. Once you compile an App for iOS it will compile your App to machine code for iOS. The compiler for iOS is not open source and is not available outside of XCode and XCode is only available on a Mac. Thats why Xamarin developers for iOS are required to have a Mac.

Having this said, I would like to make one very important note on compilation for iOS. iOS simulators don't have the restriction of dynamically created code and Xamarin will in fact use JIT compilation on iOS simulators even if your simulator runs on a Mac. This can have serious consequences for your code. Some .NET features such as Reflection.Emit are by definition not available on iOS. You code may run fine on the simulator but once you run it on a real device there is a chance that it will crash. Its therefore very important to test on real iOS devices early in your development cycle.

Conclusively, in my opinion you are only ready to develop with Xamarin if you understand the architecture of Xamarin. You don't have to be an expert but knowing how your code is actually executed is very important. Its helps you to understand how your development environment should be setup and how to tackle certain problems.

Now that you know the basics of Xamarin I will elaborate on the tools that I have used and how they collaborate and support my DevOps cycle.

Development

Starting with my development environment. I work a MacBook Pro with a Windows Virtual Machine. This enables me to work with Visual Studio as well as Xamarin Studio, Android Studio and XCode. 

• Visual Studio

Visual Studio is my favorite IDE. It's essential in a Microsoft orientated IT landscape and works great with Xamarin. The designers in Visual Studio are often even better than the native designers. Have you tried the Storyboard designer in XCode? The storyboard designer in Visual Studio is way better and delivers a far better User Experience.

One downside of using Visual Studio for Xamarin iOS is that you have to connect with a Mac over the network. This slows down the performance and sometimes your connection will become corrupt. Xamarin tooling isn't that stable and you will definitely encounter issues with connectivity and latency. If you encouter issues please take a look at the Xamarin Output Window. A whole bunch of stuff has to boot up before you will be able to communicate with your Mac.

• Xamarin Studio

If you want to work on a Mac and don't want to hook up a Virtual Machine with Visual Studio, you will have to use Xamarin Studio. Its a fair IDE with support for all kinds of features. You can definitely use it to build your Apps. However its not my favorite, Visual Studio is far more comprehensive. Its fast though. The main problem with Xamarin Studio is of course the lack of possibility to build other projects then your Xamarin projects. If you have for instance an ASP.net WebAPI project in the same solution as your Xamarin solution you will not be able to run and test using Xamarin Studio. You will however be able to build it. Another example of lacking functionality is the ability to build and run unit tests. The projects are currently not supported by Xamarin Studio. If you want to setup unit tests for for instance your shared .NET functionality you should definitely take a look at NUnit test projects.

• Android Studio

You will not use Android Studio a lot with Xamarin development. However its useful for some features regarding publishing to the PlayStore. Signing your packages and actually uploading them is really easy with Android Studio.

• XCode

The same goes for XCode. You will not develop your code in XCode but sometimes you gotta use it. Probaly mostly for development profile- and certification issues that you are most likely going to have.

Build

As a build and continues integration server I used Visual Studio Team Services(VSTS) a lot. It has great support for mobile development and really empowers your mobile dev ops cycle. It has great build in support for building your mobile apps, testing them and pushing them to the next step in your dev ops cycle.

Generally speaking I took the following approach. I set up a Git- or used an existing Tfs repository. I developed my App and shared as much code as possible in my shared portable class libraries. I used dependency frameworks to make sure that my shared code was unit testable. I then wrote unit tests to verify my feature after developing it. I didn't took the test driven development approach since you have to match your code to two vendors, iOS and Android, and its therefore hard to predict how your code will finally end up. Sometimes you gotta take different turns to get code working on both platforms.

As stated earlier I used both Git and Tfs as source control. I highly recommend that you use Git as source control for Xamarin projects. Especially when iOS is involved. There is simply no Tfs client for Mac available and that's really a struggle. And also Xamarin Studio only got support for Git source control. If you don't have a choice because you have to hook into an existing Tfs repo than I recommend that you install Eclipse with its Tfs plugin.

Once you have hooked your source control into a continues integration flow you should be able to automatically build your Apps once have you checked in or pushed your code to the Git repo. I recommend that you automatically build your Apps and also run the unit tests.

Building your iOS Apps in VSTS can be a challenge. VSTS doesn't have default build agents with iOS capabilities. Hopefully they will in the future but for now they don't. You will therefore have to hook up your own Mac as a build client in VSTS. Xamarin has some documentation for it but you are more likely to find your answers if you search for VSTS documentation. I used this blog as a reference to set up my own hosted build agent. Its pretty straight forward but you might encounter some issues with configurations. Keep in mind that you have to spin up your build agent every time you start developing. Otherwise the build will be queued but never build and therefore your whole advantage of having a continues integration flow is gone.

Having this said it is wise to have at least two build flows, one for development and one for testing/acceptance. The dev build flow should not have any test cloud testing in it since that is very time consuming and will cost you a lot of money. It will however have the continues integration switch turned on to notice early build and test failures. Its up to you if you want dev apps pushed to hockey app. I personally don't do this very often since I rather pick up a physical device and test on it rather then pushing it to hockey app and downloading it from there. You can't debug via hockey app any way so its kinda pointless. The test/acceptance flow however should do a full unit and test cloud test prior to pushing it to hockey app. You will probably won't release a new test or acceptance app more than once a day so your test cloud hours will not be burned up to quick. Note that testing on test cloud can take some serious time, I have head some tests than ran for half on hour on 3 different devices so if you want to release quick keep that in mind.

Test

Once your Android and iOS apps are build at every code change you are ready for automated testing. First of all make sure that your unit tests cover most of your shared code. Its very important to make sure that your tests succeed without the presence of a backend. Most Apps connect with some other API but these API's should be mocked. Dependency injection is the keyword the get this to work. With dependency injection it is easy to mock your API by mocking an HttpClient.

Make sure that you don't use just one of the many Dependency Injection frameworks. They have to be compatible with your PCL's profile. Some NuGet packages won't be available for your profile. I used Splat since its easy to use and compatible with almost all profiles. Its even available for Xamarin MacOS projects. For mocking I used Moq. Mocking Nuget packages don't have to match difficult profiles since they only apply on your testing projects, and these are mostly regular .Net framework projects.

After unit testing your code you should start with building automated UI tests. This often te most overlooked and skipped step in the dev ops cycle. However its crucial when your applications grows larger. Building a solid regression test set that hits every aspect of your UI helps to find bugs earlier in the dev ops cycle. This does apply for a lot of applications such as websites, desktop apps and mobile apps. However on the mobile platform its even more important. This is caused by the very large range of devices that possibly run your App. Especially Android has literally thousands of different Android OS versions with their own resolutions and such. This significantly improves the chance that your App will have bugs on some configurations. Does this mean that you have to cover all devices with your automated tests? Luckily no, you'll have to invest in the most common devices and run your UI tests prior to every release.

Xamarin's test cloud is a great platform for automated UI tests. The downside of the platform is that its rather expensive. You pay for test hours and prices range from 99$ a month for 1 hour a day up to 799$ for 10 hours a day. Hooking up your continues integration to your UI test may burn up your test cloud hours really fast so be careful with that. I highly recommended to take at least the 99$ plan and make sure that Apps are UI tested before you send them to your in-person testers or even to the stores. Make sure that you burn up the hours you buy by building a solid regression set.

Keep in mind that test cloud is rather slow. It can easily take up several minutes per device to finish your tests. You will be in the queue a lot. I highly recommend that you write your iOS tests in Xamarin Studio instead of Visual Studio. Running your tests on a simulator will have significant overhead in Visual Studio. Its spins up and shuts down the simulator for every request. Also keep in mind that your app is build with the ENABLE_TEST_CLOUD compiler constant. This also applies to the build you have configured in VSTS. If you want to test your app in test cloud than you will have to build it in debug mode.

Accept

I'll share my experience with HockeyApp in the near future.

* HockeyApp upload from VSTS
* TestCloud integration
* Feedback via HockeyApp
* Crash Reports

Deploy

I'll share my experience with deploying to the App Stores in the near future.

Xamarin vs Cordova

Update: 21-4-2016: Note that all price related remarks on Xamarin have become invalid, since Microsoft has acquired Xamarin and announced that its use will be free of costs. As before Mono will still be used as runtime for Xamarin so those remarks stay the same. Microsoft has also announced new ways of sharing code via Microsofts Standard Library. That is still in preview and therefore not applicable to this blogpost.

Original post:

Recently I've had the privilege to work with Xamarin, where in the past I've been working a lot with Cordova. This blogpost compares both platforms and points out the major pros and cons for both platforms, since both platforms sadly aren't perfect.

I've hands-on experience with both platforms and successfully released multiple business apps to all App stores (Windows, iOS and Android) and also to several Enterprise Mobility Management suites such as MobileIron and HockeyApp. All apps that I have made are business to business apps and are generally data driven apps. The fact that I made mostly b2b apps may cloud my judgement and you should consider if my remarks are applicable to your situation.

Cordova

So lets start with Cordova. Whats great about Cordova is, is that it is completely open. You can look it up, file bugs or tasks and even join the development community. The fact that the apps are web based makes startup time really quick and the learning cursive is almost not there. With the possibility to write native parts using plugins makes it a full service platform. People who say that native functionality is not possible with Cordova just don't know the power of it.

Whats also great about Cordova is, is that it got a big community. There are lots of guys on github and stackoverflow that will answers your questions. Having such as a big community also causes that the tooling got significantly better. Visual Studio got great support for Cordova and the command line interface of Cordova is really easy to use.

Sounds like Cordova is perfect, well that's absolutely not true. Cordova definitely has its quirks. Developing for web has its traditional issues, a major part of that is browser compatibility. You know the browser hell we lived in back in the day? Remember supporting IE6/7/8, Firefox and Chrome? Well iOS and Android in particular reintroduced that same problem. The web views that are loaded with Cordova have different implementations for every OS version. Apple and Google updated their browsers with every OS release and that caused subtle behavior differences in the web views with every release. So as a developer you have to constantly test your code against multiple OS versions for you to be sure that it works perfectly.

Another problem with the web views are keyboard interactivity and form inputs. Business apps naturally have a lot of forms and therefore have a lot of keyboard interaction. This is really a struggle when you use Cordova. The different platforms behave differently with keyboard events, some platforms resize the web view and others just overlay the web view with the keyboard, making your inputs not visible because of the overlap of the keyboard. You wont have this problem when you are using native UI components. Another point I was trying to make was the fact that the HTML5 input controls are poorly implement in the several web views. This can really be a struggle since, for instance, you won't get the nice date picker keyboard for date inputs in certain browsers. You will have to work with input masks and weird date pickers which are probably a little confusing for your users.

Another point that I would like to make is performance. Cordova apps generally perform well but there are boundaries. You can expect performance issues when you have large lists or grids with a lot of data, in other words when your DOM is blowing up. The web views render significantly slower on mobile devices then on your desktop, I recommend that you develop and test on actual devices to identify performance issues early in your development cycle. Cordova also performs really bad for HTML5 games, don't try to use plain Canvas for gaming purposes since you will be disappointed about its performance. And also WebGL is poorly or not at all implemented in different OS versions.

Pros and Cons of Cordova

Pros	Cons
Web technology Tons of JavaScript libraries Small startup time Almost no learning curve	Different web views everywhere Forms based applications are a mess! Android made a mess of it
Opensource Big community (Stack overflow, Github) Lots of plugins available Free to use	Performance Calculations tent to be slower Multi threading is only possible with webworkers Large lists or grids render slow.
Tooling Great Visual Studio support Cross platform CLI	Gaming HTML5 Canvas performance is bad WebGL isn't supported in all platforms

Xamarin

Well and there is Xamarin, finally cross platform mobile development tooling in C# .NET. As a .NET developer I was really happy when Xamarin came out. Yay! I can use my favorite language to write Android and iOS apps. But then I looked at the price and the threshold for getting started became to high for me. But luckily after a while the company that I'm hired to decided to create Apps with Xamarin so that's how I met Xamarin. So is Xamarin worth the money? Lets find out!

So lets start with the most obvious advantage of Xamarin. You can write C# code for mobile devices. Its not just fancy, its very functional as well. C# is a mature language and probably one of the best out there. It also got a huge existing code base. You can find examples and solutions of practically everything so that's really great! You can also use NuGet for existing packages so you won't have to write everything all over again. But does Xamarin really run the .NET framework? Well actually it doesn't, it runs Mono, the opensource variant of .NET. Is that a problem? Well it shouldn't be, but sometimes it is. As a developer you trust .NET with your life but when you start coding on Mono you will soon figure out that there are subtle changes and that it sometimes doesn't really work as expected. Debugging for instance is quite fragile, e.g. async and await debugging performs really strange and step over functionality works really lame. These are just examples so don't think that these are the only problems.

Lets focus on the code reuse. Probably all of your code is written in C# .NET instead of Mono. This means that there's a chance that some of your C# code isn't executable on Mono, but the chance of that is minimal since Mono is quite up to date. You shouldn't be using WCF, WPF and MVC in Xamarin anyway. There is a greater chance that your existing code is not a portable class library. Normal class library's wont be usable since they rely on the complete .NET framework instead of the Portable variant of .NET. For more information please visit Cross-Platform Development with the Portable Class Library documentation of Microsoft. So please make sure that before you start with Xamarin that the code you want to re-use is compatible or convertible to a PCL.

What's actually really great about Xamarin is the performance compared to Cordova. Xamarin actually executes native code whether or not via a managed code runtime such as a Java VM or the Mono runtime. Depended on what code you call either the Java VM or the Mono runtime will execute native code which really speeds up your calculations and processing time. It also enables you to use multi-threading which can really speed up your time intensive tasks, especially with use of the latest multi-core devices, and also background tasks can significantly improve your UI responsiveness which is always great for a better user experience.

Sounds like Xamarin is an expensive gift from heaven right? Well sadly it's not. You will still have to write your UI for every platform. And that will not be easy at all. You will have to know the Android and iOS frameworks really well since Xamarin just provides C# wrappers for the Native UI parts of both platforms. And on top of that the in-code documentation of Xamarin is just not there, so you will have to have Google on your second screen with the SDK documentation of the specific platform. But hey, when your finished you got native UI's for every platform, that probably means better performing views and a platform matching UI which will result in a better User Experience. But I hear you thinking what about Xamarin Forms? Well Xamarin Forms is immature and to probably to basic for your use. It contains the absolute basic UI parts if you want anything custom you will end up writing platform specific UI's.

Pros and Cons of Xamarin

Pros	Cons
Performance Multi-threading is enabled More responsive UI	Expensive Pay big money for everything. e.g University, Test cloud
Write in C# Chance of code reuse is high e.g Data contracts, serialization Write Native UI in C#	Mono instead of .NET Tooling contains bugs Looks like .NET but actually isn't Poor in code documentation
Tooling Great Visual Studio support Excellent Android UI designer	Platform specific UI Steep learning curve Immature Xamarin Forms Wouldn't recommend for Gaming

Conclusion

So which one is the best? Well of course the answer should be that it depends on your situation. Cordova's learning curve is short and you are really quick up and running. Xamarin is expensive and the learning curve is steep, but it also provides better User Experience and performance. To help you decide I made some guidelines:

Choose Cordova if:

• You don't want to spend multiple thousands of dollars on tooling.
• You definitely want the same UI on every platform, regardless of User Experience.
• JavaScript is your thing and C# isn't.
• You want to be up and running withing days/weeks.
• You don't rely on calculations, multi-threading and lots of data in the UI.
• You got an existing code base written in JavaScript.

Choose Xamarin if:

• You don't mind spending multiple thousands of dollars on tooling.
• You pick User Experience over easy UI development.
• You are willing to learn platform specific UI frameworks.
• You rely on calculations, multi-threading or UI intensive screens.
• C# is your thing and JavaScript isn't.
• You got an existing code base written in C#.

If you have any question feel free to ask, you can also contact me to advise you on a more personal level.

JavaScript Unit Testing in Visual Studio Team Services(VSO)

JavaScript unit testing can be a real struggle. Especially when you want to integrate unit testing into your continues delivery and/or continues deployment. This blog post is about enabling your JavaScript unit tests to run on Visual Studio Team Services.

Unit testing your web application is hard, you probably got to deal with one or multiple data connections, server side code such as ASP.net(C#) and front-end JavaScript code which is fully integrated into your HTML templates. Regardless of the code that has to be unit tested you got to mind several design principles, namely:

1. Separation of Concerns
2. Dependency injection
3. Build integration

This blog post isn't about the first and second principle but all about the 3rd one, namely Build Integration. This post therefore presumes that you have a working set of JavaScript unit test using a framework such as: QUnit, Jasmine and Mocha.

So why Build integration? Well having your unit tests integrated in your automated build flow is a must have for every web developer. The time that we manually build and unit test our code is over. If you are still doing that, then that's a big sign for you to critically look at your workflow. You are literally living in the past!

Most of you developers know how to unit test your .NET code. Microsoft got great tools in Visual Studio and TFS/VSTS(VSO) to automatically run your unit tests and flag the build as a failure if one of your tests fail. This will result in finding issues earlier in the development process and thus probably better quality and faster development.

So why are we not unit testing our JavaScript, and if we do why don't we integrate it in TFS/VSTS? Well because its a little bit more complicated than unit testing .NET code. JavaScript code obviously runs in a browser, TFS/VSTS should spin up a browser and run your unit tests and then check if they succeeded or failed. Well that's the exact problem, TFS/VSTS doesn't support that functionality and that leaves us hanging to automate our JavaScript unit tests.

But wait! what about all those server side JavaScript instances such as NodeJS, can't they tackle this problem for us? Well actually they can! NodeJS provides great functionality to run your JavaScript unit tests on the NodeJS runtime but the only problem is, is that NodeJS doesn't got a DOM. In fact it doesn't even support document.getElementById, which will cause a lot of unit tests to fail. Well luckily for us there's PhantomJS. PhantomJS is a headless in memory browser with a DOM. It actually renders the DOM but doesn't paint it. So that tackles the problem.

But how do we get PhantomJS to work in TFS/VSTS? Well you don't have to do anything. Someone at Microsoft fixed that for us and named it Chutzpah. Chutzpah is both a Visual Studio extension aswell as a NuGet package. It contains PhantomJS as a dependency and comes with 3 JavaScript unit test libraries, namely: Jasmine, QUnit and Mocha. Its able to run and debug your JavaScript unit tests via the Visual Studio and TFS/VSTS interface, that means that you get both your .NET as JavaScript test results in one unified standard. Which is great for build purposes.

So how does it work? Well just search for Chutzpah in the Visual Studio Extensions and you will find two extensions. The first is the Test adapter, its used to run tests in the Visual Studio Test Explorer. Once you've installed the Test adapter, you will see that your JavaScript unit tests will be picked up in the explorer. Just select your tests and spin it up, you will see that your tests will integrate perfectly within Visual Studio.

The second extension is a context menu extension that allows you to run your tests within two mouse clicks. This plugin also provides you additional functionality such as code coverage results, using blanket.js. It produces really nice code coverage files that exactly pinpoint the code that hasn't been hit.

It will be easy to get your unit tests to run on TFS/VSTS, once your unit tests run within Visual Studio. First crab the NuGet package. The NuGet package, as stated earlier, has the necessary files to run your unit tests, this also applies to TFS/VSTS. Secondly add a Visual Studio test build step to your build flow.

Once you've done that make sure that you adjust to test assembly to only match JavaScript test files. Normally I suffix these files with *.tests.js. This makes them easy to find and apply in the build step. Note that we have to exclude all files that are found in the obj folder. Otherwise you will have double tests. The screenshot contains the following line: **\*.tests.js;-:**\obj\**\*.tests.js

Lastly make sure that you point to the Chutzpah test adapter. This actually points to the NuGet package that you've installed for your project. Make sure that the $(Build.SourcesDirectory) has the packages folder or you might up ending with strange errors. 

Well and that's it. Hopefully you've had enough information. If you have any questions or problems feel free to contact me.

NuGet and JavaScript libraries are a bad marriage

Almost everyone who is using Visual Studio uses NuGet today. Its a powerful package manager for .NET based applications. It clearly does it job for maintaining and distribution of libraries. Its also widely used in Enterprise environments where companies setup their own NuGet servers for better application live cycle management of their code.

Well nothing but love... until you try to use NuGet for JavaScript libraries. JavaScript libraries are referenced differently than .NET libraries in Visual Studio projects. .NET libraries are always referenced in the project file, this results in a single list of referenced libraries and the NuGet package manager can always keep track of the downloaded libraries. JavaScript libraries however get dumped in a Scripts folder. Well I don't know about you guys but I easily use 10-20+ JavaScript libraries in a single Web application. So here is the pain in the ass. I'm frustrated about the fact that I can't structure my JavaScript in a more folder like structure. If I move the JavaScript libraries in a different folder than NuGet loses its track of the JavaScript libraries and as a result version upgrades or removal of libraries result in additional or unintentional left files. This problem gets even bigger when you use Typescript. With TypeScript the amount of files for a JavaScript library are almost alwayst doubled since you have to get the definition files. A lot of the most common libraries also contain a bunch of CSS. The exact same problem also applies on CSS, in fact it applies of every non .NET library.

Well thats enough hating, its time for some advise. I think NuGet should introduce a mapping scheme for non .NET libraries. You should be able to place the content of a NuGet package wherever you like in your project. NuGet then should remember those locations and keep track of those files. NuGet should also update their saved locations when a user moves those files. This will be huge for the usability of non .NET libraries in NuGet.

Thank you for reading and please share your thoughts.

Why MCSD certification is important

Recently I have started getting my MCSD Web Applications certification. As a .NET consultant this is quite important from a market value perspective however in my opinion it’s even more important from a personal development perspective.

Let me elaborate, as your company is trying to sell your expertise to a third party it’s important for the third party that they get an employee with the appropriate skills, in my case .NET framework skills. There is always a certain chance that the consultant exaggerates his skills and that he claims to be an expert on certain aspects while he only used the technology for a short amount of time or that he used it in a limited way. For instance, the .NET framework is a really big framework and stating to be expert in it might mean something else for you than for the hiring company. It’s a matter of perception. This resolves in a risk for the hiring company. This risk can be reduced by getting the right certifications. Certifications can’t be misinterpreted since the content of the examinations is fixed. So when the consultant has for instance a 70-487: Developing ASP.net MVC Web Applications certificate you can be sure that he has the appropriate knowledge to build a solid MVC Web application. This certainty reduces the risk of hiring an incompetent employees, which increases the market value of the consultant since hiring an employee with certifications has a higher change of success.

Secondly the personal development perspective. As a, not necessarily Microsoft, software developer you have to keep learning and keep expanding your knowledge. Software languages develop, frameworks expand, new libraries come and go, you simple can't learn one language or one framework and do your thing for 40 years. You need to keep track of new trends and developments. MCSD Certification helps to keep your Microsoft knowledge up to date. Since certifications expire you will have to keep track of new trends and developments or catch up when you retake your examination. The certification functions as a big stick to keep your knowledge up to date. Some developers think that just working experience is enough. I tend to think that that's not true. Working experience is often limited to the technology that applies to the application you are developing. Its pretty hard to keep your MVC knowledge up to date if you are for instance developing a Web Forms application for your work. You will have to catch up in your spare time and MVC is only a small part of the MCSD Web Applications stack. MCSD certifications basically force you to keep track of developments, some guys need it some guys don't. I like it.

Async Cordova Windows plugin

Recently I had to write a Cordova plugin for Windows Phone 8.1 and the Windows RT and desktop environment. I went to the Cordova plugin documentation and was disappointed by the lack of information. Hopefully this blog post will help you out.

So I assume that you know a little bit about a Cordova plugin structure. Please take a detailed look at existing plugins when you don't. One important part of a plugin are its platforms. Note that Windows and WP8 are two different platforms. Windows will apply on Windows Phone 8.1 and Windows RT/Metro while the WP8 platform will only apply on Windows Phone 8. This is because the Windows platform generates an Universal App which can be applied on almost every Microsoft Windows runtime.

Every plugin has a plugin.xml which contains information about the files of the plugin. Note that the example below is a stripped version of a plugin.xml file. Every plugin.xml should contain 1 or more platform elements with the supported platforms. Make sure that you create a separate xml element for every platform (ios, android, wp8, windows, etc).

<plugin id="com.foo.bar"
        version="1.0.0"
        xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns="http://apache.org/cordova/ns/plugins/1.0">
    <name>FooBar</name>
    <platform name="windows">  
        <framework custom="true" src="src/windows/FooBar.dll"></framework>

        <js-module name="WebSqlProxy" src="src/windows/FooBarProxy.js">
            <runs />
        </js-module>
    </platform>
</plugin>

You can specify additional files inside the platform element. These files will be loaded into your application or executed in the Cordova.js context. The framework elements are files that will be added to your application and usually contain native libraries, for Windows usually DLL or WINMD files. WINMD files are commonly used for Windows Phone projects.

Next to the native library files there are JavaScript files inside the js-module elements. There are two kind of JavaScript files that you want to add, namely the proxy JavaScript files and functional JavaScript files. The proxy JavaScript files are used to build a bridge between your native library calls and the JavaScript calls. The functional JavaScript files on the other hand are commonly used to initialize the JavaScript or for example extend the window object with a certain namespace.

Inside element inside the js-module element states the mode of the execution of the JavaScript file. There are several options available but the two major ones are <runs \>, which just executes the JavaScript file and <merges target="x"> which gives you the power to merge a JavaScript object with a certain JavaScript object, such as window.

So there's the plugin.xml. So lets get back to those native libaries. I told you that the Windows platform generates a Universal App. The native library of your plugin should also be a library for Universal Apps. You can create one using Visual Studio > New Project > Templates > Store Apps > Universal Apps -> Windows Runtime Component project. Please choose your name carefully because your namspace is very important. I will use Nimrod.FooBar as namespace in my example.

using System;

namespace Nimrod
{
    // This class must be sealed because Cordova only recognizes sealed classes.
    public sealed class FooBar
    {
        public static string Echo(string value)
        {
            return value;
        }
    }
}

Compile the project and look for the WINMD file. This file should be added to the src\windows plugin directory. Also add it to the plugin.xml as a framework file. After that you can write a JavaScript proxy. It will look like this:

module.exports = {
    echo: function(success, fail, args) {
        var value = args.shift();
        var res = Nimrod.FooBar.echo(value);
        if (res != undefined) {
            success(res);
        } else {
            fail();
        }
    };
};
require("cordova/exec/proxy").add("Nimrod", module.exports);

The module.exports object is extended with an echo function. This function has a call to the native library; Nimrod.FooBar.echo(value). Please note that this syntax is confirm the Namespace.Class.Method syntax used in the native library. The Cordova proxy will map this JavaScript call to the native library.

So how do you use the plugin in your code? Well note that the module.exports is added with Nimrod as key. This will result in a Nimrod object on the window object. So use can use the plugin like this:

// This is a Cordova event that states that all plugins are loaded.
document.addEventListener("deviceready", function () {
    // window.Nimrod doesn't exist in iOS or Android.
    if(window.Nimrod) {
        window.Nimrod.echo(
            function(res) {
                console.log(res);
            }, function () {
                console.log("Something went wrong");
            }, 
            "Hello world"
        );
    }
});

So this is great isn't it? Well not exactly. What if my native library does a time consuming action, such as a database call or a mathematical calculation? My App will be blocked for the entire call. This is because the plugin isn't setup asynchronously. So lets fix that.

The .NET framework has excellent support for asynchronous programming. Especially .NET 4.5 or higher. Please take a look at this example:

using System;
using System.Threading.Tasks;
using Windows.Foundation;

namespace Nimrod
{
    // This class must be sealed because Cordova only recognizes sealed classes.
    public sealed class FooBar
    {
        public static IAsyncOperation Echo(string value)
        {
            return FooBar.doSomeTimeConsumingThings(value).AsAsyncOperation();
        }

        private static async Task doSomeTimeConsumingThings(string value)
        {
            string result = null;
            
            await Task.Run(() =>
            {
                Task.Delay(1000);

                result = value;
            });

            return result;
        }
    }
}

The echo method now returns an IAsyncOperation instead of the string. This AsyncOperation has as effect on the return value in the JavaScript proxy. Instead of being the string value it now will be an JavaScript promise. This will not be blocking the JavaScript. Take a look at the updated proxy code:

module.exports = {
    echo: function(success, fail, args) {
        var value = args.shift();
        var promise = Nimrod.FooBar.echo(value);
        promise.done(function (res) {
            success(res);
        });
        promise.fail(function () {
            fail();
        });
    };
};
require("cordova/exec/proxy").add("Nimrod", module.exports);

I hope this helped, if you have any questions feel free to ask. I might be able to help you out any further.