With the release of Xamarin 4 came Xamarin.Forms 2.0, introducing new features and optimizations to help you build great native cross-platform mobile apps. In addition to ListView caching strategies, pinch gestures, and new properties came the first public preview of Xamarin.Forms for Windows 10 (UWP) applications. While Xamarin.Forms already supports Windows Phone and Store targets, […]

The post Getting Started with Xamarin.Forms 2.0’s Windows 10 Preview appeared first on Xamarin Blog.

When we started working for Xamarin as consultants, a couple years ago, it was nothing short of amazing for us that Xamarin had already achieved a pretty solid “F5 experience” with an app building on the Mac and debugging like any regular local .NET app. I had the same feeling the first time I did the same thing against an Azure website. Felt like magic (in the Arthur C. Clark way).

During the past year and a half since the we joined Xamarin, we iterated (among other things) on this key component of the developer experience, culminating in our most recent release, Xamarin 4. What started as a (more or less) batch process of “zip sources, HTTP post to Mac, build, run” (with frequent rebuilds needed), is now a fine-tuned granular incremental build system driven by MSBuild, connecting to the Mac over a resilient, auto-deployed and always-on messaging layer running on top of a bi-directional binary protocol over TCP, secured by an SSH tunnel.

At the user experience level, it might seem that little has changed other than a fancy new connection dialog. But as Tim Cook said “the only thing that changed is everything”, so I’ll go over the details of how it works today with the new Xamarin 4 experience.

MSBuild and Incremental Builds

For anything but trivial apps, achieving incremental builds is key for productivity: you don’t want to be copying unnecessary files over the network to the Mac, neither you want to be optimizing PNGs, compiling storyboards and what-not if none of the source files have changed.

MSBuild (and XBuild on the Mac) already support incremental builds, so the first challenge was to move away from batch-style of invoking XBuild remotely, to a fully “MSBuild-native” solution. Also, we wanted to share 100% of the build logic from Xamarin.iOS targets on the Mac. So the way it works today is:

You can see that exactly the same targets and tasks are shared between the Mac and Windows. This allows us to minimize inconsistencies between VS and XS builds. The only difference is that the Windows version of the tasks do a remote invocation to the Mac whenever the tasks that need to run on the Mac are executed. We evaluate tasks individually to determine if they must run remotely or if they can be run locally.

The unit of remote invocation to the Mac is the MSBuild Task.Execute

One example of a task that always runs remotely is compiling iOS storyboards, since the tools to do so are provided by Xcode. An example that doesn’t is the C# compiler itself, since the source code can be compiled to IL by Microsoft’s compiler on Windows without requiring a roundtrip to the Mac.

Some parts of the build are done on Windows, some parts on the Mac

The next step was to improve the targets to provide relevant Inputs/Outputs to enable incremental build. An interesting challenge there was that for MSBuild to determine that a given target doesn’t need run again (or that certain outputs are out of date with regards to their inputs), the Outputs files need to exist on the Windows side. But since all we need those output files for is for incremental build support, they are actually written as empty files on Windows :). MSBuild doesn’t care, as long as the timestamp on those files can be compared with the Inputs to detect the out-of-date items.

This mechanism existed prior to Xamarin 4, and we just replaced the underlying remote call protocol, which was almost trivial to do since the core changes to unify XS/VS builds had already been done. Our goal was to have at least comparable performance to our previous releases.

Now that the underlying communication infrastructure has shipped, we’ll focus on fine tuning the targets and tasks to leverage incremental build support even more. Our goal is to achieve substantial performance gains moving forward, and we could certainly use your feedback, especially if you find some cases where builds are considerably slower than local builds on the Mac with Xamarin Studio.

Remote Communication

The underlying communication facilities that Xamarin provides within Visual Studio are consumed by fairly independent components (we call them Agents):

• Activation: ensures that the Mac is properly activated
• Build: performs the remote build task invocation
• Designer: provides the rendering for the iOS designer
• IDB: provides similar functionality to ADB (Android Debug Bridge), hence the name, an acronym of iOS Debug Bridge (we don’t like the name so much nowadays ;)). Basically exposes list of simulators and devices available on the Mac
• Stats: we support collecting some stats (execution time, payload sizes, etc.) for diagnostics.

From top to bottom, the flow is:

1. When Xamarin starts within Visual Studio, it automatically establishes an SSH connection with the Mac, deploys the Broker (if necessary), starts it and then starts all the Agents (which you see in real-time in the status bar or the spinner icon tooltip on the connection dialog)
2. Agents use the exposed API (IMessagingClient) to send/post/reply messages (remember it’s bidirectional!)
3. The Messaging layer communicates over TCP/IP within the SSH tunel with the Broker, which forwards the message to the Mac-side agent that registered to receive the message.
4. The process is the exact opposite if the Mac side agents need to communicate with the VS ones, which are in turn registered to receive certain messages.

In previous versions of Xamarin, an unexpected error on any of the individual components on the Mac could cause the whole build host to stop working, requiring manual intervention by restarting it. In Xamarin 4, we implemented process-level isolation for unrelated components:

One key change from our previous versions is that now Visual Studio drives the Mac side too. Since it connects remotely to the Mac via SSH as a local interactive user account, it can start processes, copy files, fetch logs, etc.

Visual Studio controls deployment, versioning and manages processes on the Mac

As shown in the previous image, there is another isolation boundary at the Visual Studio process level. This ensures that multiple instances of VS can simultaneously connect to the Mac seamlessly. The broker and individual agents can all be recycled independently too. The ports used by the broker and agents are negotiated automatically to avoid collisions too.

And as soon as Visual Studio disconnects from a Mac, all processes are stopped.

In a future post, I’ll go into more detail on the protocol underlying the Messaging layer. If you’re curious, it’s MQTT 🙂

Last week we began creating an iOS application.  We covered most of what is required but we did not tackle persistence, which we will do today. This post is based on my Pluralsight course Beginning Mobile Development with Xamarin. We begin … Continue reading →

This has been a great year so far, I have released multiple new components on the Xamarin Component Store, committed thousands of lines of code into various repositories, and, finally had my book published!

It has been a long time coming, originally scheduled for about 6 months, but working full time had forced me to go a bit slower. So after 12 months of work, Packt Publishing, made my book, “Xamarin Mobile Development for Android Cookbook”, available to the world.

Beginning Writing

In September last year, they contacted me about authoring a book focused on more advanced concepts when developing Android apps using the Xamarin platform. I cover concepts ranging from using basic UI elements, to managing view states. I also show how one can make use of Bluetooth and NFC communication. Included in the topics are some that cover modern app development, such as making use of the Android support libraries to create modern apps that run on almost all versions of Android.

I won’t lie and say that the book was easy; writing is pretty hard. Once the topic is decided and the code ready, the actual readable text takes a bit of work. I feel that I was able to bring each recipe across in an easy-to-consume manner without compromising on the actual content. This is a lot of work in that it is sometimes hard to write a technical document without knowing the knowledge level of the reader.
In addition to that, sometimes I had to research why I did something. I have done something so many times that it has become automatic, and then I have to go and learn why. And then I sometimes realize that what I had been doing all this time was only one way…

All in all, I quite enjoyed writing, even if it meant very late nights. If I was to write another book, well, it might be some time in the future. I hope that my book sells well, not because of money, but it is an accomplishment. How many people can say they have written a book, and how many of those can say they wrote a good book. If this book sells well, then I would have achieved one of my life goals.

After I first found out about software development when I was 9 years old, I wanted to become a programmer. After the release of Windows, I wanted to be the new Bill Gates. I don’t think I’ll ever get to that level of awesomeness, but I can go for the other things. One of those things is to provide developers with tools that they can use to create the best that can be created.

Why I Started

When I started developing professionally, my projects were ASP.NET websites and Desktop applications. This is great, but typically those apps were company apps and only used during work hours. Mobile apps have always been a passion of mine in that they travel with the user. I have always liked being a back end developer as this is often the area where the “cool” work is done. The UI is great, don’t get me wrong, but almost all of them talk to some library or service.

During my years of development, I really grew to love my work more and more. This love grew into something that I want to share with the world. It started off by helping by brother do a bit of development. He now has built several games using many of the game creation tools. One of the coolest, and most cross-platform, is Scirra’s Construct 2. Recently, he has started using Unity 3D.

Another way I shared my love for development is though my code. I have several repositories on GitHub, which I try and update. I also use this account to update repositories in the community. Sometimes there is that awesome library, but just doesn’t have that feature… For example, there is this tiny library, NLipsum, that allows you to generate a chunk of lorerm ipsum. Although technically not very useful, it is often the simplest way to populate text fields. This library required no changes, but could only be used with desktop .NET platforms. In the age of mobile development, I was able to add a new project that created a Portable Class Library, which can be used everywhere. This is not a headlines-worthy change, but NLipsum is now more cross-platform than ever before.

Writing a book was just another way to share my knowledge and love of development with the world. I hope my book helps both the new guy on the block as well as the other guy that never got around to using In-App billing in his popular Android app. As a result, I am not going to tell you to buy my book… If you want to check it out, or use it to get started with Xamarin.Android apps, you can order it in both an ebook and/or print from Packt Publishing for $32.