Category Archives: Mobile Development

Codename One, Java, Mobile Development, Software Development

Video: Building a Codename One Project for iOS

Image April 7, 2021 shannah

This is the third video in my series about our new online tool, Codename One initializr, which allows you to generate a Maven starter project for a native mobile app in one click. The first video showed how to generate the starter project, and run it in the Codename One simulator. The second video showed how to build and deploy the project on an Android device. In this video I show how to build and deploy the project on an iOS device.

TLDW (Too Long Didn’t Watch):

This video starts out with my Codename One project already opened in IntelliJ. See this post for steps on how to generate this project.

In the video I demonstrate two different approaches for building the iOS app.

Locally (0:55-2:45) – Requires a Mac with Xcode Installed.
Using Build Server (6:45-8:35) – Can be built on Windows, Linux, or Mac. With no special requirements beyond Maven and the JDK. You just need a free Codename One account.

NOTE: I also show how to generate your iOS certificates and provisioning profiles using the Certificate Wizard (2:45-6:45), as this is required to build apps for iOS.

Building Locally

The local build option generates an Xcode project, which we then open and build using Xcode.

To trigger this build, select “Local Builds” > “Xcode iOS Project”:

Then press the “Run” button.

It takes the ParparVM compiler a minute or two to do its thing, but when it’s done, it opens the generated Xcode project in Xcode.

Once opened, I press the “Run” button on the Xcode toolbar and wait while it compiles the project. When it is done, it opens the iOS simulator with my app running in it.

Building with the Build Server

One of the nice things about Codename One is that it provides a build server with all of the native build tools installed and up-to-date. This simplifies the process of building native apps greatly. You can build your project for iOS, Android, Mac Desktop, Windows Desktop, Windows UWP, and Javascript without requiring any special build tools installed beyond the JDK. Building for any of these targets is as simple as pressing a button, or running a Maven goal.

Generating Certificates

Building for iOS requires that you have an Apple developer account. Additionally, Apple requires you to generate certificates and provisioning profiles for your apps. This is by far the most painful part of app development. To help ease the pain, Codename One provides a certificate wizard to help generate these. Before I can submit my first iOS build, I need to walk through the certificate wizard to generate these certificates. The certificate wizard process starts at approx 2:45 in the video, and runs until 6:45.

To access the certificate wizard, I need to open Codename One Settings. I do this by selecting “Tools” > “Codename One Settings” from IntelliJ’s configuration menu, then pressing the “Run” button.

This will open The Control Center (aka Codename One Settings, aka Codename One Preferences):

Once there, I select “Device Settings” > “iOS” > “Certificate Wizard” from the navigation menu on the left.

This displays the login form for the certificate wizard:

IMPORTANT: You need to use your Apple Developer account to login to this form. NOT your Codename One account.

In the video I spliced out some of the waiting time. The login can take a little while, so be patient. Once logged in, it shows me a list of my registered development devices, and I can select which ones I want to be able to deploy this app to for testing and debugging.

The above screenshot has all of the rows greyed out. When you log in, you’ll see device names and UDIDs listed on this form.

Generally I select all of them. If this is your first time building an iOS app, then you may not have any devices listed yet, and you’ll need to click on the “Manage Devices” button and follow the instructions there.

Next, it asks me to confirm that I want to regenerate my certificates, as it has detected that I already have certificates generated in my Apple account. In my case, I say “yes”, I’d like to regenerate them, but in most cases, you would select “no”, to just use your existing certificates.

TIP: If your certificates were generated by the certificate wizard, then a copy of them has been stored inside the $HOME/.codenameone/iosCerts directory, and the wizard will use them automatically. If they weren’t generated by the certificate wizard, and you choose not to regenerate them, then you may need to specify the location of your certificates in the iOS Settings section.

Next, it asks whether we want to generate push certificates. In this case, since this is just a basic Hello World app, we don’t need push, so I leave these options OFF.

After clicking next, it will churn for a bit, and if all goes well, it will show us the message that our certificates were generated and installed successfully.

Just to be sure that my settings are saved. I click on the hamburger menu in the upper right, and select “Save”.

Sending the Build

Now that the certificates are generated, we can send the build. Back in IntelliJ, I select “Build Server” > “iOS Debug Build”

NOTE: If this is your first time building with the build server, you may be prompted for your Codename One username and password.

I then follow the progress of the build on the Codename One website.

When it’s finished, I get a set of links to do things like download the .ipa, or install the app on device.

Get Started

Getting started with your own native app is really easy. Just go to the Codename One initializr, enter your app details, and press “Download”.

For more information about Codename One, see the Codename One website.

Codename One, Java, Mobile Development, Software Development

Deploying Apps on Multiple Form-Factors

Image April 6, 2021 shannah

Photo by Domenico Loia on Unsplash

The other day I stumbled across this post whose title seemed to suggest that Flutter is not a cross-platform framework.

The thrust of his article is that, even though Flutter allows you to build your app for 6 platforms, that doesn’t mean that you should:

Yes, you can deploy your app on 6 platforms, but honestly, I am not planning to do so. Basically, because YOU SHOULD use different design patterns depending on the platform. I canâ€™t imagine deploying my apps on a different platform.

At first glance, he appears to be arguing for writing separate apps for each platform (e.g. Android, iOS, Mac, Windows, etc…). This idea that you need to write a separate app for each platform using the platform’s native UI toolkit is widespread in the developer community. “Native Widget Maximalists”, as I call them, believe that using cross-platform UI libraries will result in a sub-par, “non-native” experience, and will, therefore, be rejected by the user. Generally, adherents to this philosophy are fine with sharing “business logic”, but the user interface must use the native UI widgets. Much of this dogma is based on dated observations of clunky, cross-platform, desktop apps of the mid to late nineties – many of them developed by novices using early incarnations of Swing.

Since that time, cross-platform toolkits have matured, and platforms have converged on some common UI design patterns. This is especially the case on mobile, where many popular native apps look nearly identical on Android and iOS. Mobile developers have realized that it is more important to create a nice, consistent design than it is to try to “look native”. Yes, there are differences between iOS and Android, but the differences are the exception – not the rule. In my opinion it is overkill to maintain two separate codebases for the 2% of the UI where they diverge. Better to provide abstractions that allow that 2% delta to be satisfied in platform-specific ways.

If you read further into the article, you’ll see that the author actually isn’t a “native widget maximalist”. I.e. He isn’t arguing that you should build separate apps for iOS and Android using their native SDKs. He isn’t even arguing that you need to write separate apps for iOS and Android.

Usually what works on mobile wonâ€™t work on desktop and the other way around.

What he’s saying is that you shouldn’t deploy the same app on desktop as you do on mobile, because the form factor is too different. If this is his thesis, then I agree with him… with some caveats.

Strategies for targeting multiple form factors

Disclaimer: I work for Codename One.

Two of the best cross-platform development tools for mobile development are Codename One and Flutter. They approach the problem of cross-platform development in very similar ways. Both provide 100% code reuse across platforms. Both provide a rich set of UI components and API abstractions for the underlying device capabilities, and both can be deployed to iOS and Android (and other platforms), as native apps. Codename One apps are developed in Java and/or Kotlin. Flutter, in Dart.

Both Codename One and Flutter also allow you to deploy your app as a desktop app. However, if you don’t tweak your UI for the larger screen-size, and desktop usage patterns, the result probably won’t be very good. Even using mobile apps on tablet feels forced if you haven’t customized the UI for the larger screen-size. There are four strategies I use when building a multi-form-factor app (i.e. an app that runs on mobile and desktop):

1. Responsive UI

This is where the app logic is essentially the same across both form-factors, but the layout manager, and styles are “form-factor”-aware. E.g. On tablet/desktop they use different styles, and the layout managers position elements differently. (E.g. Instead of a hamburger button that reveals a side-menu sliding out over top of the form, the side menu is always visible).

2. Component-level abstraction

This is where most of the app’s control flow is the same, but certain parts of each form are abstracted to allow for different implementations on desktop, tablet and mobile. This may involve using a different widget for editing some field, displaying some extra sections on desktop that aren’t visible on mobile. This is very similar to Responsive UI, and there is certainly overlap. The distinction is that with Responsive UI, you are keeping all of the same UI elements – you’re just rendering them differently. With component-level abstraction, the UI form may actually include different UI components with different logic on desktop than it does on mobile.

3. Alternate views

This is where the app’s control flow is the same, but you create entirely different views on mobile than on tablet. If you are very careful with the design of your views, you may be able to reuse your controller classes, as long as the views share common APIs, and fire compatible events. Keeping them in sync can be challenging, so quite often you would also write separate controllers as well.

4. Separate control-flow

This is where you are basically implementing two separate apps. You can reuse business logic, but the UI layer is written separately for tablet/desktop and mobile.

5. Separate apps

If you are already implementing your app with separate control flow, then creating separate apps is just one small additional step. Generally you would still share all of your business logic between the apps. You would just provide alternate entry points for the different apps. With Codename One, this can be achieved either by moving all of the code into a shared library (cn1lib), or by simply providing an alternate configuration file (codenameone_settings.properties) that specifies a different main class. Most build targets use Proguard, or equivalent, to strip out unused code, so the app size isn’t impacted by the code-sharing.

Best choice?

It appears that the author of the article is arguing for option #5 – Separate apps. His preference, he says, is informed by his experience working on large enterprise systems where there would be different teams working on the apps for different platforms, and keeping it all in the same app would lead to toes being stepped on. Option #4 (Separate flow control) should adequately address his concern as well, since each form-factor would have its own package, likely, and developers wouldn’t need to tread on anyone else’s garden.

My preference is to use the lowest number on that scale that I can get away with, and progress up the ladder as required. IntelliJ makes refactoring from one strategy to another mostly painless, and the less fragmentation there is in the code-base, the easier it will be to maintain – generally. Obviously adding team members, or splitting the project into multiple teams changes that maintenance calculation.

Still prefer a cross-platform development tool

Suppose your team decides to implement separate apps for each form-factor (Mobile, Tablet, and Desktop). Let’s even go a step further and suppose that you decide to implement separate apps for each platform (Android Mobile, Android Tablet, iPhone, iPad, Mac, Windows, Linux). Then is there still any benefit using a cross-platform toolkit like Codename One or Flutter? Since you’re doing separate apps, wouldn’t it be just as well to just use the native APIs?

Unless you have an unlimited supply of time, developers, and money, then the answer is “no”. You would be much worse off by choosing to use separate native SDKs for each platform. Even if you manage to write some shared modules that you were able to share between the projects, the complexity involved in maintaining separate codebases is staggering. Everything is 7x more difficult. Every bug is fixed 7 times, and testing gets ridiculously complex. In addition, keeping up with the latest on all of these platforms and APIs takes dedication. You would likely need to bring in separate teams for each platform – and very little of the work can be shared between the teams.

Using a technology like Flutter – even if you are building 7 separate apps, would be far easier. Sharing code between projects is much easier, and every developer can work on every project without facing barriers to entry imposed by the idiosyncrasies of each native API.

Summary

Just because you can deploy your app to 8 different platforms, doesn’t mean that you should. Deploying to multiple platforms within the same form factor (e.g. phones) is a solid approach with a proven track record – with countless popular apps on the iOS and Android app stores currently developed with cross-platform tools like Codename One and Flutter. However, deploying to multiple form-factors (e.g. phone and desktop) is more difficult, as what works on one form-factor, may not work well on another. You may be better served by creating separate projects for each form factor, and sharing business logic between them. This doesn’t mean that you should drop your cross-platform development tool (e.g. Flutter/Codename One). Using such a tool is still a benefit as it reduces the combined project complexity, and makes it easier to share code and developers between the projects.

Codename One, Java, Mobile Development, Software Development

Codename One Project -> Build Android App

Image April 6, 2021 shannah

In my last post I showed off the new Codename One initializr online tool, generating a Maven project, and opened it in IntelliJ.

In this video I demonstrate how to build an Android app with this project.

TLDW (Too Long Didn’t Watch):

Here’s the gist of the video. There are two different build options for Android:

Build Server > Android
Local Builds > Android Gradle Project

In this video, I start with option 2, “Android Gradle Project”. This option does NOT require a Codename One account, and performs all of the build on your local machine. It does require that you have Android Studio installed.

I select “Local Builds” > “Android Gradle Project” from the Configuration menu of IntelliJ, and then press “Run”.

This generates an Android Studio project, and automatically opens it in Android studio.

I then press “Run” in the Android Studio, and wait while it builds and installs the app on my Android Emulator.

In the second part of this video, I use the “Build Server” > “Android” build option, which is much simpler, and doesn’t require you to install Android Studio. All you need is IntelliJ (Actually you don’t even need IntelliJ, as you could just build the project using Maven), and it will use the Codename One build server to generate the Android app.

After selecting “Build Server” > “Android” from the configuration menu, I press “Run” to start the build.

It then redirects me to the Codename One dashboard where I can monitor the build progress and, download the app when it’s done.

More Background

When we decided to migrate to Maven, we also made the choice to add official local build targets so that developers are no longer reliant on the build server to build their Android and iOS apps. Building locally has always been an option, but it was difficult, and we didn’t provide support for it. By adding an official local build option, we are hoping that developers who balked at Codename One because they didn’t want to be reliant on us for their builds will give us another look.

If you haven’t heard of Codename One yet, I encourage you to check us out. In my biased opinion, we are the best game in town, if you’re looking to build native mobile apps in Java or Kotlin.

It only takes a minute to create and build your first project using Codename One initializr.

Codename One, Mobile Development, Software Development

Preview: Online Tool to Generate iOS/Android app starter project

Image March 30, 2021 shannah

The Codename One initializr is an online tool for generating a Codename One starter project. You can select either Kotlin or Java, then you can download the project and open it in your local IDE.

In this 5-minute video I use the initializr to generate a bare-bones Java project, which I open and run in IntelliJ. I also give a brief tour of the project structure and build targets.

TLDW (Too Long Didn’t Watch):

Here’s the gist. Go to Codename One initializr, select either the “Java Bare-bones Project” or “Kotlin Bare-bones Project” from the “Template” select box, and press “Download”

Extract the resulting project, and open it in IntelliJ (or your preferred IDE).

Press “Run” and wait while Maven downloads the build dependencies. It will open the Codename One simulator with the simple “Hello World” app running.

The project is a Maven project, with the following build targets:

iOS
Android
Mac Desktop
Windows Desktop
Javascript App
Windows UWP App,
JavaSE Desktop App
Xcode Project
Android Studio Project

In the video, I also demonstrate how to add a Button that, when clicked, opens a dialog. This is achieved by opening the common/src/main/java/com/example/myapp/MyApp.java file, and adding the following to the start() method:

Button btn = new Button("Click Me");
btn.addActionListener(evt->{
    Dialog.show("Hello World", "You Clicked Me", "OK", null);
});
hi.add(btn);

I’ll soon be posting some follow-up videos to demonstrate how to build and deploy the project to iOS and Android devices, so watch the RSS feed or follow me (wherever you receive my posts), to be notified when these are posted.

More Background

I’ve been working hard over the past several months to migrate Codename One from Ant to Maven. That process is now complete, and it has enabled us to introduce a new, simpler workflow for creating Codename One projects. The Codename One initializr uses our Codename One App Project maven archetype to generate a starter project. Right now we just have two starter templates: Bare-bones projects for Java or Kotlin. We will be adding more templates soon, including some templates for full-featured apps that you can take and customize.

I’ve very proud of this work, and I’m excited about some of the new things that it will enable.

If you’re a Java or Kotlin developer and you’re interested in making cross-platform native mobile apps, you should give Codename One a try. You just might be surprised at how pleasant the experience is.

Cocoapods, Codename One, Mobile Development, OS X Development, Ruby, Software Development

High Sierra, Ruby, RVM, CocoaPods, ipatool, xcodebuild Ughh!!

December 19, 2017 shannah

This is a very terse post to record a problem/solution for Cocoapods on High Sierra.

I have a build process that involves running cocoapods and xcodebuild on the command line. Some time ago, I installed rvm in an attempt to fix a build error. It ended up not fixing the error, but I kept it installed because it seemed like a nice thing to be able to easily switch between ruby versions. However, xcodebuild and its sub-tools are picky about using the system ruby, so before running xcodebuild, I would always have to switch back to the system ruby using rvm use system. This was an inconvenience, but it wasn’t hard to do, so I just endured.

Some time later, I upgraded to High Sierra, which broke my system ruby. Running ruby would give an error like

dyld: Library not loaded: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/libruby.2.0.0.dylib
  Referenced from: /usr/local/bin/ruby
  Reason: image not found
Abort trap: 6

This seems to be because High Sierra upgraded its ruby to 2.3.0, but rvm some things still referenced the old 2.0 installation, which had been removed. In trying to resolve this situation I first uninstalled rvm – because I didn’t seem to be helping anything and could possibly be hurting things:

rvm implode

After doing this, I still received the error message above. I then noticed that I had two ruby binaries on my Path: /usr/local/bin/ruby and /usr/bin/ruby. The former referenced the old 2.0 libs, while the latter seemed to correctly reference the new location. So, I deleted the former:

sudo rm /usr/local/bin/ruby

And things almost started working. When I tried installing cocoapods again with:

sudo gem install cocoapods

I received “Permission denied” messages. I needed to do

sudo gem install -n /usr/local/bin cocoapods

And, voila!, things magically start working again.

Codename One, Java, Mobile Development

Async to Better U/X

August 16, 2016 shannah

I come to you today with three simple tips that will guarantee to improve your Codename One apps’ usability:

Don’t block the EDT
If you must block the EDT, do it when the user won’t notice
Prefer asynchronous coding patterns (e.g. using callbacks) to synchronous coding patterns (e.g. *AndWait(), and *AndBlock() methods).

The first one is GUI 101. All of the UI is drawn on the EDT (Event dispatch thread). If you are performing a slow operation on the EDT, the user will probably notice a lag or a jerk in the UI because drawing can’t take place while your slow operation is occupying the thread.

Here’s a quick example. I have a form that allows the user to swipe through 12 images, which are loaded from the classpath (getResourceAsStream()). My first attempt at this is to load all of the images into Labels inside the Form’s constructor as follows:

public class MyForm extends Form {
    private Tabs tabs;

    public MyForm() {
        super("Welcome to My App");

        tabs = new Tabs();

        tabs.hideTabs();

        setScrollable(false);
        Container buttonsContentWrapper = new Container(new BorderLayout());
        try {
            for (int i=1; i< =12; i++) {
                int w = calculateTheWidth();
                int h = calculateTheHeight();
                Button l = new Button(
                        Image.createImage(
                                Display.getInstance().getResourceAsStream(null, "/Instructions"+fi+".png")
                        ).scaledSmallerRatio(w, h)
                );

                l.setUIID("Label");
                if (i>1) {
                    l.setUIID("InstructionImage");
                }
                l.addActionListener(e->{
                    buttonsContentWrapper.setVisible(!buttonsContentWrapper.isVisible());
                    revalidate();
                });
                Container tabWrapper = FlowLayout.encloseCenter(l);
                tabWrapper.getAllStyles().setPaddingTop(Display.getInstance().convertToPixels(2));
                if (i==12) {
                    tabWrapper.putClientProperty("lastSlide", Boolean.TRUE);
                } else {
                    tabWrapper.putClientProperty("lastSlide", Boolean.FALSE);
                }
                tabs.addTab(i+"", tabWrapper);
            }
        } catch (Exception ex) {
            Log.e(ex);
        }
        Container mainContent = new Container(new BorderLayout());
        mainContent.addComponent(BorderLayout.CENTER, tabs);
        setLayout(new LayeredLayout());
        addComponent(mainContent);

        buttonsContentWrapper.setVisible(false);
        Button skipButton = new Button("Skip");

        skipButton.addActionListener(e->{
            MyApp.getInstance().getMainForm().show();
        });

        Container buttonsContent = FlowLayout.encloseRight(skipButton);
        buttonsContentWrapper.addComponent(BorderLayout.SOUTH, buttonsContent);
        addComponent(buttonsContentWrapper);
    }
}

So what’s the problem with this code? Loading the 12 images inside the constructor of this form takes too long. If I have code like:

MyForm form = new MyForm();
form.show();

There is a lag of 1 or 2 seconds in the new MyForm() line — before the form is even shown. This feels really bad to the user.

We can improve on this by employing the 2nd tip above:

If you must block the EDT (hey we need to load the images sometime right?), then do it when the user won’t notice

Rather than loading all of the images directly inside the MyForm constructor, we can load each one inside its own Display.callSerially() dispatch, as shown below:

public class MyForm extends Form {
    private Tabs tabs;

    public MyForm() {
        //...
        try {
            for (int i=1; i< =12; i++) {
                //...
                final Button l = new Button();
                Display.getInstance().callSerially(()->{
                    try {
                        l.setIcon(
                            Image.createImage(
                                    Display.getInstance().getResourceAsStream(null, "/Instructions"+fi+".png")
                            ).scaledSmallerRatio(fw, fh)
                        );
                        l.getParent().revalidate();
                     } catch (Exception ex){
                        Log.e(ex);
                    }
                });
                //...

            }
        } catch (Exception ex) {
            Log.e(ex);
        }
        //...

    }
}

This will still load the images on the EDT, but it will do them one by one, and in a future event dispatch, so that the code won’t block at all in the constructor. If you run this code, you’ll notice that the 1 to 2 second lag before showing the form is gone. However, the form transition may contain a few “jerks” because it is still interleaving the loading of the images while drawing frames.

So this is an improvement, but still not a good user experience. Luckily we can go back to tip #1, “Don’t block the EDT”, when we realize that we didn’t have to block the EDT at all. We can load the images on a background thread, and then apply them as icons to the labels when they are finished loading, as shown below:

public class MyForm extends Form {
    private Tabs tabs;

    public MyForm() {
        // ...
        try {
            for (int i=1; i< =12; i++) {
                // ...
                final Button l = new Button();
                Display.getInstance().scheduleBackgroundTask(()->{
                    try {
                        Image im = Image.createImage(
                                Display.getInstance().getResourceAsStream(null, "/Instructions"+fi+".png")
                        ).scaledSmallerRatio(fw, fh);
                        if (im != null) {
                            Display.getInstance().callSerially(()->{
                                l.setIcon(im);

                                l.getParent().revalidate();
                            });
                        }
                    } catch (Exception ex){
                        Log.e(ex);
                    }
                });
                //...
            }
        } catch (Exception ex) {
            Log.e(ex);
        }
        //...

    }
}

This has double nesting. The first nest (inside scheduleBackgroundTask()) downloads the icon on a background thread. Then the second nesting using callSerially(), assigns the image as the label’s icon back on the EDT. This was necessary because we can’t access the label from the background thread. That part must occur on the EDT. But that part is non-intensive and very fast to perform.

So the result is a very fluid user experience with no lags and no jerks.

Prefer Async to Sync

I’ll address the preference of Async to Sync separately. The example above is a sort of example of this since the nested calls to scheduleBackgroundTask() and callSerially() are technically “callbacks”. However, with this tip I’m more specifically targeting methods like invokeAndBlock(), addToQueueAndWait(), and other *AndWait() methods. At their core, all of these methods are built upon invokeAndBlock() so I’ll target that one specifically here – and the wisdom gleaned will also apply to all AndWait() methods.

First of all, if you aren’t familiar with invokeAndBlock, it is a marvelous invention that allows you to “block” the EDT without actually blocking the EDT. It will indeed block the current dispatch event, but while it is blocked, it will start processing the rest of the events in the EDT queue. That way your app won’t lock up while your code is blocked. This strategy is used for modal dialogs to great effect. You can effectively show a dialog, and the “next” line of code isn’t executed until the user closes the dialog – but the UI itself doesn’t lock up.

invokeAndBlock() is the infrastructure that allows you to do synchronous network requests on the EDT (e.g. NetworkManager.getInstance().addToQueueAndWait(conn)). Since this pattern is so convenient (it allows you to think serially about your workflow – which is much easier), it is used in all kinds of places where it really shouldn’t be.

So why NOT use invokeAndBlock

Because it will ALMOST always result in a worse user experience. I’ll illustrate that with a scenario that would seem, at first, to be a good case for invokeAndBlock (addToQueueAndWait()).

Here is a form that allows a user to update his bio. Somehow the form needs to be populated with the user’s existing profile data, which is exists on a network server. The question is when and how do we load this data from the server.

A first attempt might populate the data inside the form’s constructor using AddToQueueAndWait() (or some method that encapsulates this). That might look like this:

public class MyForm extends Form {

    public MyForm() {
         ConnectionRequest req = createConnectionRequest();
         NetworkManager.getInstance().addToQueueAndWait(req);
         setupFormComponents();
         populateFormData();
    }
}

The problem with this is similar to our first example loading images from the classpath. Execution will stall inside the constructor for our form while the data is loaded. So the user will have to wait to show the form. A common technique to mitigate this UX blunder is to display an infinite progress indicator so the user knows that something is happening. That’s better, but it still makes the app feel slow.

If we want the user to be able to see the form immediately, then either we need to have loaded the data before-hand, or we need to show the form, and populate it later. We could also use a combination (e.g. show the form with data we loaded before, then update it once we have the new data.

Loading data before hand, exclusively, is not realistic. There must exist a point after which we deem the data is too old and we need to reload it. And we are back at needing to load data when the form loads.

If we want to solve this problem, and still use addToQueueAndWait(), we either need to wrap addToQueueAndWait() inside a callSerially() dispatch so that it doesn’t block inside the constructor – and delay our show() method; or we need to move the call somewhere else, after the form is already shown. Although that isn’t ideal either, because we’d like to have the data as soon as possible – so the longer we delay the “sending” of the network request, the longer the user has to wait for the result.

Now, our handy tool (invokeAndBlock) that was supposed to reduce our app’s complexity, is actually making it more complex. Wrapping it inside callSerially() in the constructor means that we are now combining an async callback with sync blocking code. We might as well, at that point, just use addToQueue(), and use a result listener to process the response without blocking the EDT at all, as shown in the example below:

public class MyForm extends Form {

    public MyForm() {
         ConnectionRequest req = createConnectionRequest();
         req.addResponseListener(e->{
             populateFormDataWithResponse(req);
         });
         NetworkManager.getInstance().addToQueue(req);
         setupFormComponents();
    }
}

This predicament is the reason not to use invokeAndBlock (addtoQueueAndWait()). It isn’t that they are evil, or they can’t be made to work. It is because, if you aim to achieve an optimal user experience, it will get in the way more than it will help.

Does this mean that you should never use invokeAndBlock() or addToQueueAndWait()? No. There are valid cases for both of these. E.g. addToQueueAndWait() can be used from a background thread (off the EDT), in which case it isn’t even using invokeAndBlock. It is just plain-old blocking that background thread, which is perfectly OK because it’s not the EDT. In addition, there may be cases where you DO want to block the flow of the application without locking up the UI. Modal dialogs is the flag-ship use-case for this. I struggle to think of another suitable scenario though.

Codename One, Java, Mobile Development, Uncategorized, Xataface

Entitled OSS Users and the Xamarin RoboVM acquisition

October 22, 2015 shannah

RoboVM has been acquired by Xamarin, it was announced; and it would no longer be open source.

Wow.

It only took five minutes for the forum posts and reddit threads to start up condemning the move as some sort of robbery. The RoboVM was accused of luring unsuspecting users into its community on the promise of open source, only to pull a switcheroo and sell out to big business. Some users were demanding the RoboVM team continue to share their work for free, because … that would only be fair.

RoboVM, on the other hand, explained that they had been open source for a few years and had received little to no contributions from the community, so there wasn’t much incentive to continue with that approach. My personal experience with managing open source projects is consistent with theirs. I released the first version of Xataface in 2005. In that time it has hundreds of thousands of downloads, and is still used in many enterprises as the back-bone of their web information systems (I don’t have an exact count since most apps built with Xataface are internal). In that time, I can count the number of community contributions on my fingers and toes. I’m thankful to all of the users who did contribute. But let’s be real, the case for open sourcing a project because the community will contribute is not compelling.

Shut up and Fork it!

No, really. The source (albeit a couple of months out of date) is still on GitHub and it is licensed under the GPL. That repository represents countless hours of high-quality work by incredibly skilled individuals. That is one hell of a contribution to the open source community. Let them move on; And if you want your open source RoboVM, you can build on this fantastic source base.

Personally, I think it is highly likely that the last open source version of RoboVM will continue to circulate for a long time to come. At least in its core as an AOT java VM, it should be maintainable by people on the outside because most of the heavy lifting is already done there. It is the value-added components like the iOS API bindings, and tool support, that will be difficult for the community to maintain going forward. These things are evolving too fast for volunteers to keep up with.

Dependent Tools

If you are an iOS developer who just uses RoboVM to build iOS apps in Java, then the move to close the source probably won’t affect you – except that your costs may be going up some. I wonder more about the impact that this has on other developer tools that have made RoboVM an integral part of their tool chain. I’m thinking about companies like Gluon that provides JavaFX support for iOS and Android. They use RoboVM for their iOS builds. DukeScript, which allows you to write Java apps with an HTML5 UI and deploy to iOS (and other platforms), also uses RoboVM for its iOS builds. How will they respond.

I had argued as recently as 6 months ago that we (at Codename One) should incorporate RoboVM into our toolchain rather than maintain our own Java VM. But we ultimately decided that there was too much risk in that approach because “what if RoboVM closes down, or goes closed source”. 20/20 hindsight shows that we made the right choice and our new iOS VM is now quite mature, performant, and robust. But most importantly we are not dependent upon other external factors for maintaining it.

What Open Source VMs are Left for iOS?

RoboVM wasn’t the only open source VM for iOS. It was just the most active, and provided the best and most comprehensive bindings to the iOS native APIs. But there are alternative VMs that the open source community may turn to for their supply chain. For example:

Codename One (proper) – (Full disclosure, I work for Codename One)… Codename One is open source and provides a full cross-platform Java solution for write once run anywhere.
Codename One’s VM – Codename One has developed its own Java VM for iOS that works as a cross-compiler from Java to C. This is open source and is a good option for Java tools that need a path to iOS.
Avian – Avian is an AOT Java compiler that can be used to compile java directly to iOS binaries. It is written in C++, and has a very permissive license.
XMLVM. This project has been discontinued. But I mention it for completeness in case people want to revive it.
OpenJDK for iOS. It has been approved for an iOS port of the Open JDK to be developed. This may also present a long-term option, but this is still only in the planning stage.
J2ObjC – A transpiler that converts Java source code into Objective-C source code.
JUniversal – Java source transpiler to C# and C++ that includes a runtime library to help with portability.

Codename One, Java, Mobile Development, Software Development

iOS Certificate Wizard

July 3, 2015 shannah

I don’t know about you, but I cringe every time I need to deploy apps to iOS. There is always something with the certificates or provisioning profiles that requires tinkering. No more, I say!

This is a sneak peak of a new certificate wizard I developed for Codename One. It reduces the problem of generating certificates and provisioning profile down to a few clicks. Watch for this to be included in the Codename One plugin as soon as next week.

Codename One, Mobile Development, Software Development

My WWDC 2015 “Hey that’s cool!” list

June 10, 2015 shannah

The 2015 WWDC keynote included a lot of â€œmehâ€, but a few â€œhey thatâ€™s coolâ€s. Here is my â€œhey thatâ€™s coolâ€ list.

1. Search API

Apple announced a new search API that iOS app developers can use to allow users to search within their application from.

We now have an API for search. So now when a user performs a search, we can find content behind the apps they have installed on the device, and pull those up in results. And when they tap, theyâ€™re deep linked directly into the application. We even provide a convenient back link so they can get right back to their search results. We think these kinds of intelligence features really make a huge difference in your experience in iOS.

Android has provided a similar API for a while now, so this feature is really just playing a little catch-up. But what this means for Codename One is that it will now be possible to design a cross-platform API for this.

2. Swift Open Source

When Swift was first announced (and not open sourced), many pundits were cynical of Appleâ€™s motives – particularly suspecting that Apple was looking to create yet another â€œlock-inâ€ mechanism for developers. While this is still probably true, their decision to open source it at least some good faith. Their announcement from the Swift blog

Here is what we can tell you so far: 1. Swift source code will be released under an OSI-approved permissive license. 2. Contributions from the community will be accepted â€” and encouraged. 3. At launch we intend to contribute ports for OS X, iOS, and Linux. 4. Source code will include the Swift compiler and standard library.

We think it would be amazing for Swift to be on all your favorite platforms.

With Swiftâ€™s apparent success, one must wonder how long Objective-C will remain â€œsupportedâ€. Apple historically has had no qualms about pulling the rug out from developers when they want to make a shift, and Objective-C certainly is showing its age – so donâ€™t be surprised if, some time in the next couple of years – we get a new WWDC bombshell that Objective-C is being scrapped.

Codename One currently compiles everything down to plain old C code so we would be largely unaffected by such a change – although there would be some native portions that use Objective-C that would need updating. Luckily, if youâ€™re a Codename One user, you donâ€™t need to concern yourself with these details because you are working in Java.

3. iPad Split Screen

This is the coolest advance of them all. Being able to have two apps open at once makes the iPad much more functional – one step closer to replacing the laptop for a lot of users. As a power user, I have often felt that the iPad is not living up to its potential as a computing device – and usually ends up working like just a large iPhone. Small advances like split screen open the doors for app developers to make innovative apps that empower the user to do things that werenâ€™t previously possible.

One small bit of irony is that many apps that were developed using Appleâ€™s development toolkit will need have modifications made to support the different sizing that would occur when an app is displayed in split screen. Codename One apps should â€œjust workâ€, since it is designed from the ground up, with layout managers, to work across many different devices and screen dimensions.

4. Metal

Metal was announced last year as a more efficient graphics layer than OpenGL for iOS. Now it is available on Mac OS X. Apple describes Metal thusly:

Metal provides the lowest-overhead access to the GPU, enabling you to maximize the graphics and compute potential of your apps on iOS and OS X. With a streamlined API, precompiled shaders, and support for efficient multi-threading, Metal can take your game or app to the next level of performance and capability.

In the key note they cited performance improvements by switching to Metal between 30% and 700%. Codename One is currently using OpenGL for all of our graphics rendering but we have had our eye on Metal for some time. It is uncertain how much we can stand to gain by a switch to Metal. My conservative estimate would be closer to 30% than 700% – but who knows.

5. Apple Pay

Apparently Apple Pay is catching on. In the keynote they dazzle us with lots of numbers (e.g. 250 banks have signed on, etcâ€¦) that make it look like they really have a chance of taking over. They have successfully chiseled out a large chunk of the music and software pie. If they can get a piece of every retail transaction â€¦ I shudder to think of how big they could become. Welcome our new overlords.

Codename One, Java, Javascript, Mobile Development, Software Development

Porting a Java Project to the Web with TeaVM

April 6, 2015 shannah

I am always experimenting with new technologies just to see what new cool things are possible. As a Java developer, Iâ€™m usually toying with JVM-related technologies. The latest new and cool technology that I have been experimenting with is TeaVM: A JVM for the browser. After using it for about 2 months now, I am confident in saying that TeaVM is awesome!

TeaVM vs GWT

Java in the browser is nothing new. GWT has offered Java to Javascript cross-compilation for years. So how is TeaVM any different or better than GWT?

TeaVM operates on Java byte code rather than source code. This means you can convert precompiled .class files or even full .jar files to Javascript.
TeaVM supports (or can potentially support) alternative JVM languages like Scala, JRuby, Kotlin, etc, since it operates on .class files (which all JVM languages ultimately compile to). GWT is limited to just Java.
Multithreading. This is groundbreaking. TeaVM actually supports threading primitives like synchronized, Thread.sleep(), Object.wait/notify, etc.. This is a very new feature of TeaVM. Many have tried to come up with a threading solution in the browser, but TeaVM is the first (in history?) to have successfully done it. See live demo of multithreading

What Iâ€™m Using it For

Iâ€™m currently working on porting Codename One into Javascript. Codename One is a Write-once-run-anywhere solution for mobile application development. Up until now, it supported deploying apps to iOS, Android, Windows Phone, J2ME, BlackBerry, and the desktop (Windows/Mac)… but notably, it did not support deployment to the web. For the past year, I have been having on and off discussions with the other Codename One developers about the possibility of a Javascript port, but I was advised that it was impossible because Javascript didnâ€™t support multi-threading. Attempts had been made before using GWT but they did not prove successful. Codename One is a heavy user of threading primitives since it maintains its own event-dispatch thread (very similar to Swing), and this would lock up the browser if allowed to run in the Javascript single-threaded environment.

A little over a year ago I came across TeaVM for the first time, and I asked Alexey (its author) whether there was any support for threading. He said â€œnoâ€ at the time, but that he had an idea of how he could implement green threads. At that time I wasnâ€™t working for Codename One and had limited time to spend on projects like this, so I just left it there.

Fast forward to a couple of months ago. I was given the green light to go ahead and attempt a Javascript port. At that time still, it was basically me saying â€œI think I can do itâ€, but the rest of the team was skeptical, having failed before with GWT. I contacted Alexey again and told him what I was planning to do.

Aside: I was a little naive at this point to think I could do the port with my current knowledge and tools. Knowing what I know now, there is no way I could have succeeded without the the help of Alexey and TeaVM.

At this point I thought I could take the code that was generated by TeaVM and modify it to use Stratifiedjs to support continuations/pseudo threads. He replied that he was aware of this project but that it wasnâ€™t a good fit because he had a better way.

The full thread that shows the development of Async code generation (i.e. multithreaded support) can be see here.

Within days, he had completed a prototype of his new â€œCPS styleâ€ code generator that supported asynchronous code. He implemented Thread.sleep() and Thread.yield() and posted a test case. Based on these implementations, I added initial support for Object.wait(), Object.notify() and a few other threading primitives. Alexey, has since refactored and improved these implementations, such that probably none of my original contributions are recognizable. The full scope and scale of this project, frankly were a little over my head.

I have now been working on the Javascript port for Codename One for a couple of months. There have been quite a few bug reports, but Alexey has been quick to fix them all. I would say that TeaVMâ€™s multithreading implementation is pretty stable at this point. And it is getting more stable daily.

The Poker Demo

Here is a small teaser of the result of the new Codename One port that is built using TeaVM: the Poker demo. The application itself was not modified from the version deployed to iOS, Android, etc… It just required a port layer to implement the “native” components of the Codename One framework, and the rest was left up to TeaVM to work its magic.

Run the demo yourself here

Performance

I have been very impressed by the performance that I have been able to achieve with TeaVM. The generated code is very efficient resulting (give or take) in one line of Javascript code corresponding with one line of Java code.

You might think that adding threading support and blocking synchronous method support would lock up the browser, but you would be dead wrong. TeaVMâ€™s transformation to continuations allows it to provide support for synchronous code without ever blocking the javascript thread. This is because, under the hood, these are implemented using callbacks.

Debugging

Personally I prefer to use Netbeans as my IDE so Iâ€™m not benefiting from the debugging support that Alexey created for Eclipse. Therefore, I do my debugging directly in chrome. This actually isnâ€™t as bad as it sounds. Stack traces in chrome are very readable and map directly to the corresponding Java stack trace (i.e. if an error occurs in javascript it is fairly easy to track it back to the original Java code that caused it).

Optimizations

Another nice thing about TeaVM is that it pays attention to things like executable size. It uses static analysis to strip out dead code prior to conversion so that your app is as small as possible. It also includes an option to minify the code, which further reduces the code size.

More to Come

Personally I think that Java needs to be in the browser, since it is essentially the â€œoperating system of the futureâ€. I also think that the browser can benefit greatly from Java as applications get more complex and difficult to maintain. Currently TeaVM provides the best route between Java and the browser, so I expect it to catch on over the following months and years.

Do you currently have a project that depends on GWT? Or do you have a Java project that you would like to offer on the web? You may want to consider porting it to TeaVM because of all of its nice features (i.e. support for other JVM languages, and multithreading). I have had a great time porting Codename One to TeaVM. Iâ€™m happy to answer questions or offer tips if you are interested in porting your project over as well. In addition, I think youâ€™ll find that Alexey is very responsive to bug reports, feedback and questions.

For more information about TeaVM, check out its Github repository.

TLDW (Too Long Didn’t Watch):

Building Locally

Building with the Build Server

Generating Certificates

Sending the Build

Get Started

Strategies for targeting multiple form factors

1. Responsive UI

2. Component-level abstraction

3. Alternate views

4. Separate control-flow

5. Separate apps

Best choice?

Still prefer a cross-platform development tool

Summary

TLDW (Too Long Didn’t Watch):

More Background

TLDW (Too Long Didn’t Watch):

More Background

Prefer Async to Sync

Shut up and Fork it!

Dependent Tools

What Open Source VMs are Left for iOS?

1. Search API

2. Swift Open Source

3. iPad Split Screen

4. Metal

5. Apple Pay

TeaVM vs GWT

What Iâ€™m Using it For

The Poker Demo

Performance

Debugging

Optimizations

More to Come

Ramblings about Xataface, Java, and other software development issues