How do I – Create Desktop & Web Applications


In this short video we will discuss the desktop
and JavaScript ports of Codename One both of which are pretty confusing to new developers. We’ll start with the desktop port which
is a pro feature. The reason for this is simple, desktop builds
are huge and take up a lot of server resources. A desktop build packages Mac applications
as DMG files which is a common distribution format for Mac applications. You end up with the standard drag to install
interface familiar from native Mac applications. On Windows an EXE or an MSI file can be generated
as a result, this is determined by build hints. Under the hood the binaries on both platforms
include a JRE within the installer. This is internal to the app and isn’t exposed
to the user. The JRE is private to the app. This is implemented thru the standard Java
packager tool from the JDK. The Java packager tool requires a Mac for
Mac apps and a Windows machine for Windows apps. This isn’t a problem with Codename One as
we have build servers for both OS’s. Notice that even though these are desktop
builds the apps will still look like Codename One apps and often look like tablet apps. This isn’t a problem for some developers
and we already use this internally. Our new GUI builder is built completely in
Codename One and demonstrates the flexibility that this approach can deliver. The JavaScript port of Codename One is an
enterprise feature. Notice that this tool doesn’t generate a
website, it generates something that feels like an app. For some use cases this is better but you
should check the feel of our demo applications first before making choices. The JavaScript code uses TeaVM to statically
translate Java bytecode to obfuscated JavaScript and even compiles the code in such a way that
thread code works. This allows everything in Codename One to
work including the event dispatch thread etc. Graphics and the whole UI are rendered thru
the HTML5 Canvas API which draws the elements on the browser just like it would draw them
on a mobile device. This generates code that runs completely on
the client just like any other native OS port. This isn’t a tool that communicates to the
server to fetch application state or run logic there. There is one big limitation in JavaScript
itself that doesn’t exist in native mobile devices: same origin. JavaScript can’t open a network connection
to any server other than the one it was delivered from. To workaround this we provide a proxy servlet
that can proxy the requests from your application to any arbitrary server. I didn’t mention the UWP port before, UWP
stands for Universal Windows Platform and it’s the new approach for Native Windows
supported by Microsoft. These 3 platforms have a lot of overlap between
them and some users choose to target all 3 of them. However, your millage may vary so here is
a brief comparison. Desktop is effectively one port with 2 targets:
Mac and Windows 8 or newer. JavaScript should work pretty much everywhere
although a reasonably modern browser is required, performance might not be great when running
on some of the older mobile devices though. The Universal Windows platform is a part of
Windows 10 so you would need that at a minimum… The desktop port only works on intel CPU’s. That does include a lot of the Windows tablets
or convertible devices but not all of them. JavaScript should pretty much work on anything
and UWP should work on any Windows phone, tablet or desktop as long as it’s running
Windows 10 or newer. Shipping is where these differ a great deal. It’s hard to ship the desktop apps in the
stores. You would need to provide downloads in your
website or distribute installers in your organization. JavaScript should be shipped via a webserver
although it’s theoretically possible to package it this isn’t something that’s
currently supported. This might be great but it might be a problem
as stores provide a lot of value with things such as in-app-purchase. A UWP app can be shipped through the Microsoft
store which is convenient for some use cases. License requirements from you vary a great
deal, desktop requires pro. JavaScript requires enterprise and UWP is
available for everyone. Notice that even if you cancel your subscription,
your distribution license isn’t revoked! So you are legally allowed to upgrade to enterprise,
build a JavaScript version and cancel your subscription. And finally native interfaces are a crucial
way to extend a port and hugely important. The desktop port uses JavaSE under the hood. That means you can just invoke any feature
in Java including JNI when you need a native interface. This is very convenient and has been a deciding
factor for many developers. The “native” for the JavaScript port is
JavaScript. This allows you to access JavaScript functionality
that isn’t exposed but even when you use native within the JavaScript port you are
still stuck in the sandbox of the browser due to the inherent limitations of the web
platform. The UWP port uses C# as the native language. Notice that this is the UWP variant of C#
which has a few restrictions and limitations. You can debug desktop behavior right in the
simulator by picking the builtin Desktop skin. This skin is resizable and allows you to isolate
behaviors that occur only in a resizable app. You can just send a desktop or JavaScript
build from the right click menu. It’s pretty easy. Notice there is a lot of nuance in both so
check out our developer guide and pro/enterprise support if you run into issues! Thanks for watching, I hope you found this
helpful

Danny Hutson

Leave a Reply

Your email address will not be published. Required fields are marked *