Fork us on GitHub

Open File & Rendering

Continued bug squashing update
Post Image

Open File & Rendering

As part of our continuing effort to squash bugs for the 3.4 release date we hit two major issues, the first of which is a long time RFE to fix PDF viewing on iOS & Android to work consistently. This also applies to any file opening in iOS/Android which should now be trivial with the Display.execute method. Just use that method on any file within your home directory in FileSystemStorage and it should launch the native app to view that file.

A common use case is to see a PDF file for help or guide e.g. like this:

Form hi = new Form("PDF Viewer", BoxLayout.y());
Button devGuide = new Button("Show PDF");
devGuide.addActionListener(e -> {
    FileSystemStorage fs = FileSystemStorage.getInstance();
    String fileName = fs.getAppHomePath() + "pdf-sample.pdf";
    if(!fs.exists(fileName)) {
        Util.downloadUrlToFile("http://www.polyu.edu.hk/iaee/files/pdf-sample.pdf", fileName, true);
    }
    Display.getInstance().execute(fileName);
});
hi.add(devGuide);

hi.show();
The original demo used the Developer guide but since that is a 25MB download that’s probably not a good idea for a mobile app demo…​

Renderers On Android

The other issue we tackled was with renderers in Android following issues with the new Android pipeline. The asynchronous architecture of the newer Android pipeline made a lot of behaviors quite challenging especially for the renderer class where we share the Style object for multiple component instances.

As part of that fix we also improved performance of scrolling further by improving caching behavior on Android.

Part of the fix requires that all render components mark themselves properly as setCellRenderer(true). This also applies to nesting so if you used something like a Container renderer containing multiple child components you need to call setCellRenderer(true) on all of the children. We don’t do it implicitly since that might lead to odd bugs where adding a child before and another child after will result in weird rendering…​

We intend to switch to the new Android pipeline a bit after the 3.4 release so be sure to update your renderer code if you use such an approach or better yet, avoid List and switch to InfiniteContainer or InfiniteScrollAdapter.

After publishing this Steve noted that I was quite unclear about a few of the things above so below are a couple of clarifications:
  • The setCellRenderer call only applies to you if you implemented the ListCellRenderer or CellRenderer interfaces. If you don’t use a List or used one of the standard lists (thru GUI builder etc.) this doesn’t apply as this is done implicitly (so nothing should be done for GenericListCellRenderer, MultiList etc.).

  • setCellRenderer always improved performance in Codename One lists, however the performance improvement I mentioned above relates mostly to some cache misses in the rendering pipeline that we ran into while fixing the issue.

Share this Post:

Posted by Shai Almog

Shai is the co-founder of Codename One. He's been a professional programmer for over 25 years. During that time he has worked with dozens of companies including Sun Microsystems.
For more follow Shai on Twitter & github.