Tag Archives: xamarin

development, software development, visual studio

Visual Studio 2013 update 1: avoid the RC if you use C++

Microsoft has released Visual Studio 2013 Update 1 RC which I installed for a look. It has a “go-live” license, which means you can use it in production, and when the final version comes out you will be able to install it over the top, so it sounded safe enough.

Update 1 is only a bug-fix release – the fixes are listed in the link above. “When you edit multiple resources in Resource Editor, Visual Studio crashes randomly,” is one, so if that affects you, you might want to install it.

Unfortunately the RC introduces a new problem. The syntax highlighting in the C++ editor is broken. Here is a snippet of code before the update:

image

and after

image

Microsoft is aware of the issue and apparently the RTM update will be OK.

While investigating this, I discovered another issue. Visual Studio 2013 was crashing whenever I tried to open a C++ project. If I tried to debug Visual Studio with a new instance, the new instance would crash too. I uninstalled Update 1 RC but that did not fix it. This post on StackOverflow does not describe exactly the same issue, but did lead me to suspect Xamarin, an add-on for Android and iOS development with C#. I uninstalled Xamarin and the problem disappeared; Visual Studio seems to start up more quickly too. A shame as I like the product.

Update: the final Update 1 is now available. What’s in Update 1: http://support.microsoft.com/kb/2911573

Download: http://go.microsoft.com/fwlink/?LinkId=301714

development, microsoft, mono, software development

What does Xamarin’s success say about open source versus proprietary? Miguel de Icaza says he has never been happier

2 Comments

image

Yesterday Xamarin, which offers tools for targeting iOS, Android and Mac with C#, announced a partnership with Microsoft, an announcement which I wrote up on The Register. It drew a few comments, several complaining about the cost:

So it cost more then Visual Studio Pro.

And that is for 1 target platform?

or

Not so useful for little indie developers at those prices.

or

From open source to $999 per developer per year. Monetising Mono seems to have worked, so perhaps PCL being open sourced won’t be such a bargain either.

If you check Xamarin’s pricing you will see that the tools are not cheap for casual users; of course, if you are selling thousands of apps or developing corporate apps at normal rates the tools soon pay for themselves.

Xamarin is doing well as far as I am aware; CEO Nat Friedman told me of rapid growth in the number of customers and I have seen for myself the high interest in the tools at events like Microsoft BUILD earlier this year in San Francisco.

This gives me pause for reflection. What does the success of Xamarin, and the relative lack of success of Mono (the open source C# compiler and .NET Framework on which Xamarin is based) say about how well the open source business model works in the real world?

I was reminded of a conversation I had with Miguel de Icaza, creator of Mono and co-founder of Xamarin, Friedman back in February of this year, when Xamarin 2.0 was launched. I asked de Icaza if the new company publishes the source code for all its products?

“No. Our company does proprietary tools for iOS and Android apps. The entire iOS and Android support is proprietary as well as our commercial Mac support. All those three pieces are proprietary while the IDE and the Mono runtime are open source. Whether the code is open source or not depends on whether it is part of core Mono or core MonoDevelop. Otherwise it tends to end up as proprietary.”

Friedman added: “Mono has a thriving open source community around it, and Xamarin has a thriving community of developers who are building commercial mobile apps. We have 12,000 customers, many of them have never heard of Mono. They came to us because they had a problem to solve, they were C# developers and they wanted to get an iOS or Android app built. We solved that problem and that was worth money to them. The reason we have a business is that Microsoft developers do pay for tools, unlike Web developers for example. It’s been a great market for us. It allows us to invest.”

I asked de Icaza if he gets any grief from the open source community for having proprietary code in his company.

“Actually no. We started doing the proprietary bit at Novell. In fact we’ve been doing proprietary for a long time, even before we were acquired by Novell, at Ximian. We didn’t get a lot of grief from people. I can tell you though that when I was working in the Linux world, they were very stressful days for me, because people constantly complain about a “secret conspiracy” and that thing just went out of control. There are some advocates in the Linux world that don’t like anything that has the label Microsoft on.

“Ever since we did Xamarin which meant we focused on Mac and Windows, all that stress is gone, I don’t think I have ever been happier. In the past I was enduring this constant barrage of senseless attacks, and now I never hear about this.

“One thing that happened in the Linux world is that I was very proud of the four or five big apps that were built with Mono. F-spot that we built, Banshee, and a couple of others. Now with Xamarin I can’t keep track of them any more because they are measured in the thousands. There are thousands of very large apps, over a millions lines of code, that people send us. It’s a very different world, it’s just so much larger than all the work we did in Linux days back then.”

.net, cloud computing, mobile, software development

Xamarin acquires LessPainful, announces Test Cloud for mobile apps

1 Comment

Xamarin, a company which provides tools for cross-platform development in C#, has announced its acquisition of LessPainful and the creation of cloud-based testing for mobile apps based on LessPainful’s technology and the Calabash scripting language it created.

The Test Cloud will perform automated user-interface tests on real devices, hosted by Xamarin, will provide detailed reports in the event of test failures, and will support Continuous Integration so that bugs are caught as early as possible.

image

“After you’ve conquered the cross-platform mobile development problem, testing is the next large pain point” says Xamarin CEO Nat Friedman. “You can’t just get by with manual testing. There’s a need for the same level of tools and processes in mobile testing that you have in desktop and web testing.”

“Quality is actually more important on mobile than in other places. Mobile sessions are very short. People are really intolerant of low quality on mobile. The release cycles are shorter too. People are revving more frequently, and testing is a bigger challenge.”

Another issue with mobile testing is the number of devices out there, especially if you throw cross-platform into the mix. “You have on Android all these manufacturers who customise the OS in different ways, you have multiple different versions that are in use, and you have multiple different form factors and device capabilities. The testing permutation matrix is huge.”

“Automated UI testing is the only kind of testing that can ensure that the app does what it is supposed to do.”

Friedman says that the Xamarin UI tests are more robust than competing UI test frameworks because they do not depend on UI image recognition. “The right answer is object-based, you identify user interface elements on the screen by object IDs”.”

How does testing on real devices work? If you have 50 developers testing on 27 devices in Xamarin’s cloud, will there be racks and racks of devices to support them?  “That’s what it looks like at our end, racks and racks of devices,” confirmed Friedman. “The service is going to be built based on device/hour usage. We’ll be able to scale up to match what people need.

“We talk to developers who spend $8,000 a month just to get new devices. That’s not counting the labour and everything else they need to do, to set up their own testing infrastructure. It’s a giant pain point.”

Xamarin’s Test Cloud will offer plug-ins for Jenkins, TeamCity, and Microsoft’s Team Foundation Server, to support Continuous Integration.

The scripting language for the Test Cloud is either Calabash , or C# scripting which is under development by Xamarin.

The Test Cloud is not just for applications developed using Xamarin’s C# framework, but also supports other frameworks including those written in native iOS Objective C. However, only iOS and Android are supported.

Availability is set for the third quarter of 2013.

Xamarin’s Evolve conference is currently under way in Austin, Texas, with around 600 developers in attendance. Friedman says the company is growing fast. 1000 developers a day download the tools, there are over 15,000 paid developers, and the company now has 65 employees.

More information on the Xamarin Test Cloud is here.

.net, embarcadero, mobile, software development

Xamarin vs Titanium vs FireMonkey: should cross-platform tools abstract the GUI?

20 Comments

Cross-platform development is a big deal, and will continue to be so until a day comes when everyone uses the same platform. Android? HTML? WebKit? iOS? Windows? Maybe one day, but for now the world is multi-platform, and unless you can afford to ignore all platforms but one, or to develop independent projects for each platform, some kind of cross-platform approach makes sense, especially in mobile.

Sometimes I hear it said that there are essentially two approaches to cross-platform mobile apps. You can either use an embedded browser control and write a web app wrapped as a native app, as in Adobe PhoneGap/Cordova or the similar approach taken by Sencha, or you can use a cross-platform tool that creates native apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero FireMonkey.

Within the second category though, there is diversity. In particular, they vary concerning the extent to which they abstract the user interface.

Here is the trade-off. If you design your cross-platform framework to include user interface widgets, like labels, buttons, grids and menus, then you can have your application work almost the same way on every platform. You can also have tools that build the user interface once for all the platforms. This is a big win in terms of coding effort. If the framework is well implemented, it will still adopt some of the characteristics native to each platform so that it looks more or less native.

Some tools do this by drawing their own controls. Embarcadero FireMonkey is in this category. Another approach is to use native controls where possible (in other words, to call the API that shows a button, rather than drawing the button with the graphics API), but to use custom drawing where necessary, even sometimes implementing a control from one platform on another. The downside is that because those controls are not in fact native, there will be some differences, perhaps obvious, perhaps subtle. Martin Fowler at ThoughtWorks refers to this as the uncanny valley and argues against emulated controls.

Further, if you are sharing the UI design across all platforms, it is hard to make your design feel equally right in all cases. It might be better to take the approach adopted by most games, using a design that is distinctive to your app and make a virtue of its consistency across platforms, even though it does not have the native look and feel on any platform.

Xamarin Studio on the other hand makes no attempt to provide a shared GUI framework:

We don’t try to provide a user interface abstraction layer that works across all the platforms. We think that’s a bad approach that leads to lowest common denominator user interfaces.*

CEO Nat Friedman told me. He is right; but the downside is the effort involved in maintaining two or more user interface designs for your app.

This is an old debate. One of the reasons IBM created Eclipse was a disagreement with Sun over the best way to design a cross-platform user interface framework. Sun’s Swing framework, derived from Netscape’s Internet Foundation Classes first released in 1996, takes the custom-drawn approach, which is why Swing apps always look like Swing apps (even if you apply the “Windows” look and feel). A team from IBM, some originally from Object Technology International which was a company acquired by IBM, believed it was better to wrap native controls with a Java abstraction layer, created SWT (Standard Widget Toolkit) to do that, and used it to build Eclipse.

Personally I am wary of toolkits which rely heavily on custom-drawn controls rather than native controls, though I see their value. On the other hand, Xamarin Studio is so far in the other direction that it removes some of the benefit of a cross-platform framework.

My prediction is that Xamarin will come up with its own GUI abstraction framework in future, along the lines of SWT. It is a compromise; but one which delivers a lot of value to developers who want to create cross-platform apps with the maximum amount of shared code.

*I have never understood this use of the term “lowest common demominator”. The LCD in maths is the lowest number into which a specific group of numbers divide exactly, so it is an elegant thing. In cross-platform what you should strive for is the highest common intersection: to make available all the features common to each platform.

Update: in April 2014 Xamarin announced Xamarin Forms, a GUI framework which wraps native controls in a XAML implementation (XAML is the presentation language also used by Microsoft, for WPF, Silverlight, Windows Phone and Windows Runtime (Windows 8) apps. There is a quick hands-on here.

.net, microsoft, mobile, mono, open source, professional, software development, windows

Xamarin 2.0 and Xamarin Studio announced, build for OSX, iOS and Android with C#

2 Comments

Xamarin has announced significant updates to its developer platform. Xamarin is the company formed around 18 months ago, when Novell discontinued its investment in Mono, a cross-platform implementation of C# and the .NET Framework. Its focus is on mobile platforms, in particular iOS and Android, though there is also support for the Mac. On Windows and Windows Phone, the presumption is that developers will continue to use Microsoft’s .NET Framework.

“If you look at what you can develop with C#, there’s about 1.2 billion Windows machines out there, but there’s now about a billion Android and iOS devices. Together we can make C# a universal language for application development and reach 2.2 billion devices,” Xamarin co-founder and CEO Nat Friedman told me.

“There’s a wonderful built-in audience of C# developers, millions of them, who need a bridge to mobile. We can help them take their existing skills and tools, and even code they’ve already written, and bring them to mainstream mobile platforms like iOS and Android.”

The key announcements:

  • Xamarin Studio is  an updated version of MonoDevelop, the Mono IDE. It runs on Mac and Windows.#
  • You can now develop iOS apps in Visual Studio for the first time
  • MonoTouch, the framework for iOS, has been renamed Xamarin.iOS
  • Mono for Android is now called Xamarin.Android
  • A new component store has pre-built components for download, some free, some commercial.
  • Xamarin now offers a free Starter edition, and pricing plans for independent developers, smaller businesses, and enterprises. Indie is $299 per platform per year, Business is $999 per platform/year, and Enterprise $1800 platform/year.

The Starter edition is not much use. It has a limited app size, and even the sample project I downloaded, an Employee Directory, exceeded that size and I had to register for a trial.

Xamarin’s philosophy is to share non-visual code, but to create a user interface that is native for each platform. This is a compromise in terms of the effort involved in supporting multiple platforms, but ensures a native experience on each device. “That’s fundamental to our platform,” says Friedman. “We tell our developers to separate the UI layer from the rest of the app. That allows them to share all the non-UI code across platforms, but to deliver a fully native UI, even though the whole app is written in C#. That’s what users demand now, people want native experiences.”

“We’ve been building tools that essentially project the underlying iOS APIs or Java [Android] APIs into C#”, explains co-founder Miguel de Icaza. “What it means is that people need to build a new UI for each platform.” He adds that Microsoft platform developers should be used to this, as Microsoft itself has several similar but incompatible .NET platforms. “There’s the one on Silverlight, the one on WPF, the one on Windows RT, and the one on the phone, it’s four,” he says. “Developers have had to resort to putting their logic into shared libraries, and build a per-platform UI. We’re reusing that knowledge.”

The ability to develop for iOS in Visual Studio is new. “It’s our most-requested feature of all time.” said Friedman.

I downloaded Xamarin Studio, which in my case was around 1.3GB including an updated Android SDK.

image

The IDE itself is clean and fast, and very much code-centric. It lacks the bloat of Visual Studio, though you will miss many of the features of Microsoft’s IDE.

image

I build the sample Employee Directory app and deployed it to an Android emulator which I use for Nexus 7 development. Deploying the runtime components took a long time, but after waiting patiently the app launched successfully.

image

If you want to do iOS development you will need a Mac of course. Although you can code on Windows, if you then the code is pushed over the the Mac side for compilation and debugging. In order to use Visual Studio, one option is to run Windows in a virtual machine on a Mac, as I have done with reasonable success using Embarcadero’s cross-platform tools.

Xamarin says it is growing fast. There have been 230,000 downloads of its tools, increasing by around 700 per day, and over 12,000 paying customers.

Despite Xamarin’s roots in the open source world (and Mono is still open source), a quick look at the pricing table shows that this is a fully commercial offering and priced accordingly. Presuming customers keep on subscribing, that is a good thing, ensuring the future of the platform; but it is not so good for the smallest developers who might otherwise give it a try.

.net, development, microsoft, mobile, mono, software development

Xamarin brings C# to development of apps for the Mac App Store

Xamarin has released Xamarin Mac which adds Mac support to the existing iOS and Android compilers from the company:

  • MonoTouch: apps for iPhone and iPad using the MonoDevelop IDE on the Mac
  • Mono for Android: apps for Android using either Visual Studio or MonoDevelop
  • Xamarin.Mac: apps for Mac OS X using MonoDevelop on the Mac

The major platforms missing from the above are Windows and Linux (unless you count Android), even though Mono began as a Linux implementation of Microsoft’s .NET platform.

Xamarin says that a Windows version is not necessary since you can use Microsoft’s tools to code in C# for Windows desktop and Windows phone.

You can also get Mono for Windows, Mac and Linux from the old Mono project site.

Why would you bother with paid-for Xamarin.Mac when you can get Mono for Mac as a free download? There is even a Mac packager which lets you create a standalone package for your Mono app. A good question, but I guess the answer is the benefit of Xamarin-specific libraries and support from the company. Xamarin has also done the work to ensure that you can distribute your app via the Mac App Store.

Xamarin.Mac costs $399 for personal use, or $999 for an enterprise license which allows internal as well as app store distribution. A one year, one seat license with priority support costs $2,499.

Xamarin knows how to charge then, and in the end that may be a key reason why the project is working, whereas Mono struggled as an open source project that never had the resources it deserved.

The Mono Project site now says that it is “sponsored by Xamarin” so open source developers are getting some benefit from the commercial offshoot.

Xamarin is important for the C# language, since it represents a viable implementation which is independent of Microsoft.

.net, development, microsoft, mobile, mono, open source, professional, software development, visual studio, web authoring

The strategy behind Mono has shifted: ten years of open source .NET

Yesterday, SUSE and Xamarin announced, in effect, the transfer of all things Mono to Xamarin.

The agreement grants Xamarin a broad, perpetual license to all intellectual property covering Mono, MonoTouch, Mono for Android and Mono Tools for Visual Studio. Xamarin will also provide technical support to SUSE customers using Mono-based products, and assume stewardship of the Mono open source community project.

Xamarin is a startup formed by Mono founder Miguel de Icaza following the acquisition of Novell and SUSE by Attachmate, which ceased Mono development.

Attachmate acquired Novell in November 2010. Mono has been plucked from the abyss with impressive speed.

That said, the strategy behind Mono has shifted. Mono exists because de Icaza liked what Microsoft announced back in 2000 when it introduced C# and the .NET Framework. Microsoft made a show of standardizing the .NET CLI (Common Language Infrastructure), which made PR sense at the time since there was controversy over Sun’s ownership of Java, though nobody really believed that Microsoft knew how to steward an open source development platform or indeed believed that it was really serious about it. History largely justifies that scepticism; but de Icaza called Microsoft’s bluff and forged ahead with Mono, implementing not only the CLI and C# but most of the .NET Framework as well.

The goal of Mono, as I recall, was to bring the benefits of C# and .NET to Linux developers, and to enable developers to move applications freely between Windows and Linux. Apple OS X was also on the radar, though it took longer to become much use. Recalling Mono’s early days, de Icaza said:

Mono to me is a means to an end: a technology to help Linux succeed on the desktop.

Mono worked remarkably well from quite early on, but never quite well enough to persuade mainstream developers it was a sensible choice for applications that would otherwise have run on Windows. It did emerge as a viable and productive toolset and platform for Linux and a number of Mono applications became popular, including Beagle search, Tomboy notes, and F-Spot photo management. Some ASP.NET applications run on Mono; I have one on this site. Another Mono success was its use as the scripting engine in Unity, a game development platform.

A big problem for Mono though was the lack of a business model. There was support and servicing of course, which must have generated some revenue for Novell, but most Mono use is free. Novell possibly had in mind that Mono could be significant as an application server, but it has never become a really trusted platform in the Enterprise. For example, as Alan Radding (Dancing Dinosaur) notes:

DancingDinosaur has not found any SUSE on z user that has successfully implemented .NET apps on the mainframe. A few have tried but reported that Mono on z wasn’t ready for prime time.

Even among the free software and open source community, Mono was hampered by suspicion of Microsoft. If Mono became successful enough to threaten Microsoft, would lawyers appear? Given the way Microsoft is currently behaving with Android, filing legal actions and signing up licensees, those fears might not be unwarranted.

So what is Mono today? The answer is that Mono is now primarily a mobile platform. The Xamarin home page makes this clear, as well as making it apparent that the Mono team has discovered the value of a business model:

image

Xamarin is tapping into two real business needs. One is the need for a cross-platform mobile development platform that works. The second is a way for Windows developers to use their existing C# skills for mobile development, given that they might not be happy with the tiny market share currently achieved by Windows Phone 7.

When I had a quick try with Monotouch I was impressed, and I would like to spend some more time with it and with Mono for Android.

Mono has touch competition though. In particular, PhoneGap, Appcelerator’s Titanium, and Adobe AIR. I was interested to see that Adobe is coming up with a packager for AIR on Android, which may significantly improve it as a cross-platform mobile toolkit.

Still, Xamarin is small and nimble and I expect it to succeed. It has also has Visual Studio integration, which is an advantage. One of the pieces Xamarin has now licensed from SUSE is Mono for Visual Studio.

The downside of these latest developments is that if you depend on Mono for the desktop or for ASP.NET, you may find these parts of the Mono project getting little attention from the new company. But Mobile is all that matters now, right?

I write this on July 19 2011. According to Wikipedia:

Recognizing that their small team could not expect to build and support a full product, they launched the Mono open source project, on July 19, 2001 at the O’Reilly conference.

Well, if there was a launch there it was low-key. It is not mentioned in this report. But de Icaza does recall:

We planned the announcement to come by July 19th 2001, so we could announce this at the O’Reilly conference, as Tim O’Reilly had been very supportive of this effort, and had offered his help since the early stages, when it was still a very young idea. When we announced the project launch we had our team in place, and we were shipping our metadata framework and our C# compiler as well as a few initial classes So officially the Mono project was launched on that date, but it had been brewing for a very long time.

Happy Anniversary!

.net, microsoft, mono, open source, professional, silverlight, software development

Mono splits from Novell/Attachmate to form basis of new company

1 Comment

Mono is an open source implementation of .NET, formerly sponsored by Novell, and its future following Novell’s acquisition by Attachmate has been the subject of speculation.

Today Mono leader Miguel de Icaza has revealed new plans. In a blog post, he announces Xamarin, a new company focused on Mono. This company will build new commercial .NET tools for Apple iOS and Google Android, to enable .NET development on those platforms. Note that they will not be called MonoTouch and MonoDroid, the Novell offerings for this, but will be “source compatible”. I am sure there are brand and intellectual property ownership issues here; but de Icaza is no stranger to negotiating tricky issues of this kind, bearing in mind Mono’s relationship with Microsoft .NET. However I am not sure why the new company cannot acquire the existing brands, since it seems that Attachmate will no longer be able to support them.

The plans are not exactly new, but have been forced by Attachmate’s decision to lay off the entire Mono team:

We have been trying to spin Mono off from Novell for more than a year now. Everyone agreed that Mono would have a brighter future as an independent company, so a plan was prepared last year.

To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers.

Apparently Xamarin has “angel funding” but is looking for more.

The advent of MonoTouch and MonoDroid has been good for Mono, since it gives the project a stronger business model than it had previously. These mobile platforms are hot, and the ability to code for them in C# is great for Microsoft Platform developers. This factor could enable Xamarin to succeed.

On the other hand, Novell’s name gave Mono enterprise credibility as well as the backing of a large company, and these it now lacks.

The curious thing is that Mono is valuable to Microsoft. The company seems at times to hate Mono, because it removes the need for Windows, and at other times to love it, because it extends the breadth of .NET to include Linux and now iOS and Android. Microsoft gave some sort of official status to Moonlight, the Mono implementation of Silverlight, though the company’s support for Moonlight has always seemed hesitant.

So can we expect now that the company which can afford $8.5 billion for Skype, could expend a few million in support of Xamarin? Or will it stand by and hope that Mono fades away?

I have no idea, though I would like to see both Mono and Xamarin succeed. It is no threat to Microsoft, but does take .NET to places that Microsoft will never support. Without Mono, C# is merely a language for programming Windows.