Last time around we compared Codename One to Xamarin and this
time around I’d like to compare Codename One to what is probably the market leader: PhoneGap/Cordova. If Xamain
is big then Cordova is huge, it is so prevalent that it is often the default assumption when people mention cross
In fact, one of the big problems we had when describing Codename One was distinguishing it from HTML5 based
solutions like Cordova.
One of the things we’d like to clarify before delving into the comparison is that our goal isn’t to proclaim Codename One
as the “end all” of WORA…
We are biased so the comparison might be flawed. However, we think Cordova/PhoneGap are remarkably
innovative tools that changed the marketplace significantly. The goal of this comparison is to highlight the
differences/tradeoffs of each solution. In fact we rather like Cordova and even offer some
Cordova compatibility in Codename One…
We were debating a lot on whether we should include Ionic in this comparison and decided to mostly skip it for now.
We mention it and related frameworks in the comparison in a few points mostly because PhoneGap is usually used
of PhoneGap it’s just impractical to single out each and every one of them.
We might do a proper discussion of Ionic as I think it’s a very interesting solution that is very similar to Codename One
in some regards. Most of the things we discuss about PhoneGap/Cordova apply to ionic too.
PhoneGap was started in the iPhoneDevCamp hackathon, this highlights the genius behind the solution:
the underlying idea is trivial. PhoneGap is in-effect a very simple solution which is a pretty good thing.
PhoneGap places a single web view UI within an app which it then uses to display HTML. It exposes a set of
It also includes a rich set of plugins that provide quite a few capabilities, in fact we just ported one of those
great plugins to add bluetooth support to Codename One…
Adobe purchased Nitobi who made PhoneGap and open sourced the project thru Apache as the Cordova project.
Both PhoneGap and Cordova are very similar with PhoneGap offering some pretty interesting features on top of
the core open source product such as PhoneGap build.
Because Cordova/PhoneGap is so simple it was adopted throughout the industry practically all major enterprise mobility
tools such as Worklight rely on it for their client side UI. It’s become a synonym for the idea of packaging HTML
as an application and even tools that are not using Cordova internally are often referred to as PhoneGap or Cordova.
In fact even we announced PhoneGap/Cordova support
a while back and it didn’t take much to implement that…
At a Glance
Packaged code optionally obfuscated
Yes thru PhoneGap build
Depends on framework
is probably the right tool for you. HTML5 has come a very long way and is no longer as restrictive as it used to be
especially with recent iOS updates.
is literally the native language of Android and maps rather well to C/Objective-C/Swift concepts.
PhoneGap applications are just zipped into the standard OS distribution. A complaint some PhoneGap developers
app. This allows them to sell the app within the standard markets as if it was their own. Such scams are
quite common and very hard to catch/enforce.
This is not feasible in Codename One where the source code is compiled together and obfuscated by default
on Android making it even more “secure”. A Codename One application can be decompiled but this would be
a far harder process than doing the same for a PhoneGap/Cordova application.
This brings about some interesting situations, Android completely replaced it’s browser implementation between
versions of the OS relatively abruptly. This can trigger a situation where shipping applications will start misbehaving
due to OS changes. This also means that the only way to fix some issues is thru a workaround, there is no central
authority that can fix an HTML rendering issue or add a missing feature to an old OS.
With Codename One the VM and UI are the responsibility of a single entity. Since the implementation of Codename One
is at a lower point in the porting stack most of the relevant code can be ported/fixed or worked around by Codename One
itself. This means that if a low level reproducible failure happens, Codename One has the ability to fix it whereas
PhoneGap developers would need to workaround it.
PhoneGap Build supports building native applications via the cloud which is a wonderful approach.
Codename One works in the same way but unlike PhoneGap build, Codename One is built around that
approach as a basic expectation.
PhoneGap build works with a set of pre-determined plugins whereas Codename One is more flexible with
it’s support for native code and 3rd party libraries.
Codename One uses lightweight widgets to do it’s rendering. Arguably HTML can be considered lightweight
as well but it is often not the case.
One of the core powers of HTML has been it’s complex support for dynamic reflows, this allows positioning
components using a very elaborate box model. However, this power is also the source of HTML’s greatest performance
challenges. Some HTML frameworks choose to position elements absolutely and lay them out thru code
logic, which is pretty close to what Codename One does in it’s layout managers. However, this forces the
Frameworks like Ionic have taken up the lightweight approach to creating native “themes” in a similar way to
Codename One. This provides Ionic with many of the advantages Codename One enjoys but also some of the
drawbacks/advantages inherent from layering on top of Cordova.
One of the core capabilities of Codename One is in embedding native widgets directly into the app. This is demonstrated
in Codename One thru the native Google Maps support and other such capabilities. Since embedding an OS
native widget into HTML is “problematic” that level of platform extension can’t be accomplished in Cordova.
Cordova and Codename One can be used to create very small applications. In fact Cordova can be even smaller
than Codename One in the hands of a skilled developer.
These tools include their own overhead which is rather extensive in some cases. E.g. Ionic is specifically well
known for producing very large application binaries.
Property Cross Comparison
The PropertyCross demo was built as a tool that allows us to compare two cross platform frameworks, as such
there are versions of the demo for many such platforms. You can check out details of the Codename One
implementation here. The github repository for this demo
Since PhoneGap/Cordova is mostly an infrastructure tool there are several implementations that support PhoneGap
Build. E.g. jquerymobile,
sencha touch and too many others to even
With so many variations how can we properly compare the two frameworks?
There are several things we can gleam from property cross by reviewing all of the above:
Codename One has 2 file types that aren’t configuration or build scripts: res file (resources) & Java files.
Codename One doesn’t have splashscreens or multiple icon sizes… Those are generated automatically unlike
the PhoneGap based solutions where you need dozens of resource files even without tablet support!
Codename One is terse. Ionic, is one of the smallest implementations. It includes more than 600 lines of
The Codename One implementation has 623 lines of code out of which over 150 lines are comments and 40
lines are import statements…
Who says Java is verbose?
Notice that Codename One can
embed PhoneGap/Cordova code into
Codename One applications. Would that make it superior to just using Cordova directly?
then it’s hard to compete with that…
However, if you want to use proper Java to develop your app and care more about the security of your code
then Codename One has advantages.
If you think we misrepresented Codename One or PhoneGap/Cordova in any way let us know in the comments.
CN1 vs React Native ?
Agreed. I already wrote something but it wasn’t a real comparison: [http://www.codenameone.com/…](http://www.codenameone.com/blog/java-is-superior-to-react-native-in-practically-every-way.html)
ah.. yes I remember now. Would be good to get a feature for feature comparison.
Seems you haven’t seen [http://microsoft.github.io/…](http://microsoft.github.io/ace/) yet.
Not better or worse, just different, aimed for different needs.
Thanks for the headsup, I actually did see this when it was announced and it totally slipped my mind. I wonder how well it works with the native HTML rendering?
Codename One is totally different from LWUIT by now, we even have some CSS support. Although the “giving CSS to a designer” line is a bit… I’ve worked a lot with designers and never got anything remotely close to a usable CSS snippet from them. The best they could offer is the CSS photoshop produces for a layer which isn’t much…
In mobile where the design needs to be aware of screen size, density, orientation, font constraints etc. the design requires proper programming skills. I’ve yet to see a designer produce something half decent for a website and I can’t imagine one producing something workable for cross platform mobile devices…
I am a Java/Android developer and was asked to create an Android watch application to be added to an existing Cordova project. I was hoping that Cordova could receive requests from the watch through Android Wear messaging, but our Cordova expert says that Cordova can only receive Wear messages, if the Cordova app is currently in the foreground. It appears Cordova can’t run in the background without writing native code. If this is true, it may be important when considering Cordova. So, I ended up writing the native Android Wear message receiving piece for Cordova.
Was that a comment, concern, or just venting out?