Monthly Archives: June 2014

Xamarin.Forms : One UI to rule them all ?

Xamarin 3.0 has recently introduced Xamarin.Forms, a powerful UI abstraction that allows developers to easily create user interfaces that can be shared across Android, iOS, and Windows Phone.

Introducing Xamarin.Forms

Xamarin.Forms apps follow the same architecture xamarinmvvmthat traditional cross-platform applications, except there is an additional –new- project. It’s the main component here that makes everything possible.

Behind the scene what is a Xamarin.Forms project? It’s just a Portable Class Library (PCL) or a Shared Project. Shared projects were introduced with Visual Studio 2013 update 2 to provide Universal Apps.  It’s a little like file linking but with a better integration into VS.

This project depends on the Nuget package Xamarin.Forms, which contains more than 40 controls and UI componenents. It also comes with cross devices UI components such as Binding, Navigation and Dependency Injection.

There are two ways to create shared-UI views: programmatically using the API provided by Xamarin.Forms or with Xaml using the same set of controls (Is it the beginning of Xaml everywhere?) It’s a new independent meta-language to define your UI. An UILabel (iOS),  TextView (Android) or TextBlock (WP) is simply a Xamarin.Forms.View.Label. It’s also possible to create custom controls and UserControls and define renderers for each platform. Fantastic!

Without Xamarin.Forms, you have to understand each layout system to build a native UI. Now with Xamarin.Forms, you design only once.  These two samples give the same result:


Both techniques provide advantages and drawbacks but from my point of view, the biggest problem is that you don’t have any designer to preview the UI or even intellisense: It’s important to understand that’s it’s a completely new set of controls you have to learn without any help from Visual Studio. I hope I‘m sure Xamarin will improve this soon because it’s quite counter-productive. Feel free to propose an answer to this question on stackoverflow.

Read the official introduction guide here.

What about MvvmCross?

If you follow Xamarin community since a few months – like me, you may already have heard about MvvmCross, a framework that allows developers to share logic between multiple platforms. It’s mainly maintained by Stuart Lodge and is a brilliant cross Mvvm abstraction. Even better, this framework come with an awesome list of features such as cross-platform binding, dependency injection, a plugin system,   many services (Navigation, Location, Camera, …) and a few UI controls to maximize code sharing and avoid breaking the Mvvm Pattern. The combo PCL+MvvmCross+Xamarin is often called “The Precious” aka “One language to rule them all”.

Can you use it with Xamarin.Forms?  Yes because Xamarin.Forms was designed to work with the MVVM design pattern (but no included). However, much of what MvvmCross gives you is already baked in. Xamarin.Forms comes with features like DI, Navigation … whereas MvvmCross comes with ready-to-use implementations like plugins. For example, do you want to use GeoLocation (typically GPS) functionality? Install the MvvmCross package in your solution or create 3 implementations (one per platform) with Xamarin.Forms. I think we will see new packages in the coming weeks/months for common devices sensors and services. That’s another disadvantage of this first version of Xamarin.Forms: you have to reinvent the wheel in some cases. In reality, the ambiguity may also come from MvvmCross itself because it’s not only a simple cross Mvvm framework; with all the features that are included, it’s much more  a Cross platform framework than Mvvm framework.

highres_379493672So, yes there is a little overlap between these two frameworks but this should not prevent to use them both. From my point of view, Xamarin.Forms is not an MvvmCross-killer but a fantastic new path for cross-platform development. You now have the chance to share code and UIs.

Finally, I was last week in the 3th Xamarin meetup in Paris with James Montemagno.  I really appreciated the presence of Xamarin for this event. I am quite pleased to see the French community growing so fast. Is it only in France ?

Do you use {pretty print} ?

Steve Souders began to describe Web Performance Optimization 10 years ago. WPO is the field of knowledge about increasing the speed in which web pages are downloaded and displayed on the user’s web browser. He wrote and contributed to many books (High Performance Web Sites , Even Faster Web Sites , Web Performance Daybook V2
) to explain us his best practices for performance along with the research and real-world results behind them.

One of the most important rules is to Combine & Minify resources. Bundling combines multiples files into a single file whereas Minification is the process of removing all unnecessary characters from source code without changing its functionality.

With the latest HTML5 specification and the emergence of JS frontend frameworks like JQuery and more recently AngularJS, JavaScript has never been so used and so popular. We can now create scalable, maintainable applications, unified under a single language: JavaScript !

As we’re all good web citizen, all our resources (JS/CSS) are bundled and minified on production. This is sometimes where things start going bad. Have you ever try to debug JavaScript on production? The primary drawback of this optimization is that it makes debugging your JavaScript code a nightmare, since the browser’s developer tools will show you code that is virtually unreadable.

For example, a production JavaScript may looks like this: 14K characters on the same line.


It’s impossible to debug the previous script because browsers can’t set breakpoint at character level (only at line-level).

Helpfully, some of the browsers have an option in developers tools to un-minify partially a JavaScript file. This option is called “pretty print” and the icon is like {}.


Internet Explorer

In Firefox (since December 2013)

Here is the result after pretty print.


It’s fairly better and you have the nearly the same debugging experience that for dev scripts. Sometimes it’s not enough because JavaScript minification tools rename local functions & variables. It’s common to see a(), b(), c() in a minified script.  A good indentation won’t change this.

Fortunately, Source Maps provide a way of mapping the lines & columns of the production source code (bundled & minified), back to their original locations in the corresponding uncompressed source files. This feature is supported by all modern browsers.

An additional file is generated during the minification process and is added at the top of the optimized file.


Source Maps are easily generated by grunt-contrib-uglify or Closure Compiler. Unfortunately, it’s still not supported by Microsoft ASP.NET Web Optimization Framework. For sure, this is something that needs to be done. Web Essentials also offer this feature.

It’s a nice tip for every web developer but the good question may be : Why do you have to debug production code ?