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.
Join the DZone community and get the full member experience.Join For Free
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.
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.
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
Visual Studio/Xamarin Studio
NetBeans, Eclipse or IntelliJ IDEA
No (requires Mac & Windows for full OS support)
Yes (can work on Linux for iOS development)
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.
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.
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|
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 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.
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.
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.
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.
Published at DZone with permission of Shai Almog, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.