Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Comparing Xamarin and Codename One

DZone's Guide to

Comparing Xamarin and Codename One

The author looks at differences between Xamarin's use of C# and Codename One's use of Java for development on Apple, Android, Linux, and Windows platforms.

· Java Zone
Free Resource

Navigate the Maze of the End-User Experience and pick up this APM Essential guide, brought to you in partnership with CA Technologies

First, let's start with a big disclaimer: I'm the co-founder of Codename One so calling me biased would be an understatement. Having said that I would not have bothered comparing Codename One to Xamarin had I not thought that Xamarin is an excellent tool. 

Xamarin is an amazing product that I contrasted with Codename One in the past, but this is worth repeating. On its surface, Xamarin might seem like a similar tool to Codename One that uses C# instead of Java, but this is misleading because the tools are so different conceptually that they have very little in common.


Background

Xamarin was founded by Nat Friedman and Miguel de Icaza famous for the GNOME desktop environment, Mono and Ximian.

Xamarin launched in 2011, during those years Xcode was a very primitive IDE. It didn’t have ARC and had quite a few problems. Xamarin offered the ability to write native iOS apps in C# with garbage collection and the other great features allowed by C#.

Xamarin didn’t abstract the API much at the time and effectively provided mappings between C# and native API calls. It also produced a similar version for Android which did the same. In that sense, Xamarin eschewed the write once, run anywhere mantra in favor of a common set of business logic coupled with separate UI/native code/resources.

NOTE
When we say "native code" in the Xamarin context that usually means C# code that uses the native OS API. The Codename One context of native code refers to actual OS native languages, e.g. Objective-C on iOS.


As the company grew it built the Xamarin Forms solution on top of the existing infrastructure which provides something closer to write once, run anywhere. Since native widgets were used for Xamarin Forms this posed a problem, as there are inherent, insurmountable differences between the iOS/Android widget API’s.

Microsoft Purchase

Xamarin was purchased by Microsoft in February 2016 and integrated into Visual Studio. Most of its products were open-sourced as part of this purchase.


At a Glance


Category Xamarin Codename One

Language

C#

Java

IDE

Visual Studio/Xamarin Studio

NetBeans, Eclipse or IntelliJ IDEA

Cloud Build

No (requires Mac & Windows for full OS support)

Yes (can work on Linux for iOS development)

Web Deployment

No

Yes

Widgets

Heavyweight

Lightweight

Portability Strategy

Cross platform, sub-projects

WORA + Native Interfaces (one project)


NOTE Xamarin requires a Mac for the iOS native app but you can develop on a Windows machine and have a Mac machine in your office to which Xamarin will connect to do the actual native work.


Language & IDE

I’m not a fan of C# or Visual Studio, but C# is a decent language, as is Java, especially with version 8. Since both languages have similar core concepts, the differences come down to personal taste more than anything.

The same is true for Visual Studio vs. any of the popular Java IDEs (Eclipse, IntelliJ & NetBeans). These are all mature, powerful IDE’s that include anything you might need.

Native Language

While as a language C# might be a decent option, it is alien to the two leading mobile platforms.

Android’s "native" language is Java. The UI widgets in Android are implemented in Java, which effectively means that if you write code in C it will perform slower than Java code as it would need to pass thru JNI. C# code can’t be implemented on top of the current Android VM and effectively needs to pass thru JNI back and forth repeatedly.

This overhead is very noticeable when working with heavyweight widgets as the communication between the widget and the logic needs to be very frequent. In that sense, C# is less native than Codename One which is just implemented directly on top of the native layer.

On iOS the story is different, Xamarin implements the whole toolchain, effectively hiding Apple's tools completely. This is a very powerful abstraction but it sometimes creates another layer of complexity. For example, when Apple introduces a new idea such as bitcode or a new profiling tool, Xamarin can’t fully leverage such a tool. It has its own set of tools but they will always be second-class citizens on Apple's platform.

Codename One uses the open source ParparVM to translate Java bytecode to a native C Xcode project on Mac OS. This effectively creates a native iOS project and allows you to write native Objective-C code write into that project. In a sense, this is "more native"as it ends up using a greater portion of the "officially supported toolchain".

Xamarin isn’t needed on Windows as Microsofts native tools can be used to provide portability to that platform, there Microsoft is the true native leader by definition.


Cloud Build

Codename One’s cloud build capability is unique. It allows developers to build a native application using the Codename One cloud servers (Macs for iOS, Windows machines for Windows, etc.) This removes the need to own dedicated hardware and allows you to build native iOS apps from Windows and native Windows apps from your Mac or Linux machine.

This makes the installation of Codename One trivial, a single plugin to install. This isn’t true for development environments that don’t use that approach.

Xamarin is far more "low level" than Codename One. Xamarin assumes you have deep platform knowledge, e.g. you have to understand the Android activity API and lifecycle in order to build a Xamarin Android app. You need to understand the ViewController to build a Xamarin iOS app. You don’t need to understand either one of those in order to build a Codename One application.

Both platforms allow access to the underlying native code with a different underlying philosophy as explained below.

NOTE Knowledge of the native platform is less essential with Xamarin Forms but is still expected and deemed as an advantage by the Xamarin team. This highlights the core conceptual/philosophical differences between the platforms


Web Deployment

Xamarin supports almost all of Codename One’s supported platforms either directly or thru Microsofts Visual Studio tools. However, it doesn’t support building native JavaScript web applications.

Codename One supports the process of compiling an application (threads and all) into a JavaScript application that can be hosted on the web. This is done by statically translating the Java bytecode to JavaScript obfuscated code.


NOTE There are some early stage efforts to bring XAML to JavaScript but none are at a mature stage of supporting complex notions like threads


Widgets

This is probably the biggest difference between Xamarin and Codename One.

Xamarin exposes the underlying UI API completely to the developer. This is exposed so completely that a developer can literally use the native iOS/Android visual design tools to build layouts (that naturally won’t be portable).

Codename One uses a lightweight widget approach where it draws the component hierarchy but allows embedding of native widgets for specific requirements (HTML, media, text, etc.) this. The difference between these two approaches is highly documented and has been debated since the days of Smalltalk (think Swing vs. SWT/AWT).

Heavyweight architecture is closer to the way the native OS behaves and as a result is inherently less portable and not as flexible. This is a tradeoff that some developers are willing to accept in order to be "more native".

Heavyweight is sometimes deemed "faster" by its proponents but the technological basis for such claims is flawed as these widgets are harder to measure realistically across platforms and optimize properly.

Xamarin Forms

Xamarin also supports Xamarin Forms which uses XAML to allow sharing most UI code between various platforms by picking the lowest common denominator approach to the UI. Unlike Codename One the Xamarin Forms approach still uses native code and assumes some native access.

It isn’t designed as a complete WORA (Write Once, Run Anywhere) solution but rather as a middle ground solution.

Notice that with Xamarin Forms you will not be able to use some native OS capabilities such as the native OS GUI builders for obvious reasons.


Portability Strategy

Codename One uses a single project that works everywhere. When you need access to native code this native code is hidden by the native interfaces abstraction that allows that single project to remain "clean" of native code. By default, no native code of any type is necessary to build a Codename One application.

Xamarin requires a "pseudo native" project (still written in C#) to represent the lifecycle, resources and other elements of the various supported platforms. By default, this will include a lot of the platform specific code such as UI, etc., with the exception of Forms apps where there will be less code in the separate projects.

These might seem like small differences but they hide a major core difference: Codename One tries to abstract the aspect of platform native differences and Xamarin pushes it to the forefront.


Microsoft

A big selling point for Xamarin is the Microsoft acquisition positioning it as a major player backed by the full weight of Microsoft. Microsoft has repeatedly abandoned technologies in which they invested a great deal of money, e.g. Windows Phone 7, Silverlight, etc. It also demonstrated this recently by discarding RoboVM without the courtesy of opening its source code.

Xamarin is free in order to gain traction and serve Microsofts market goals. As long as those goals align with the goals of developers using Xamarin this is a good thing. However, since this is a market MS competes in it is not an impartial player.

No one can tell at this time whether the purchase will have a negative effect on the future development of Xamarin. So far the Microsoft purchase has been largely a positive thing with the exception of the RoboVM issue.


Final Word

As usual, our opinions are biased but I think we presented a reasonably fair evaluation. Xamarin is an impressive tool that is quite different inherently from Codename One and we hope we highlighted those differences fairly.

If you are looking to write a native application you like C# and don’t mind dealing with platform differences it is a compelling option. However, if you prefer Java, and portability is key, I think we have a far more compelling story.

If you think I misrepresented Codename One or Xamarin in any way let us know in the comments.



Thrive in the application economy with an APM model that is strategic. Be E.P.I.C. with CA APM.  Brought to you in partnership with CA Technologies.

Topics:
java ,mobile ,codenameone ,xamarin ,xamarin.forms ,xamarin forms ,xamarin.ios

Published at DZone with permission of Shai Almog, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}