While multi-image's go a long way in making your app scalable to various devices, scalable images can be even more convenient. The SVG standard never took off though, its too complex to support in an efficient way on the devices and so its relegated to web applications and even those don't make heavy use of it due to its complexity.
However, icon fonts have gained a lot of popularity in recent years and we used them in the past in Codename One e.g. in the photo demo.
That usage was awkward, we had to define a special font for the tab area and use letters in a way that didn't communicate what would actually appear on the screen. It worked because we only used an icon without text, had we tried to use both it wouldn't have worked...
So we now have support for icon fonts via the new
FontImage class. This class encapsulates a character or string from the icon font and presents it as an image. You can even scale and rotate such as image and you can convert it to an
EncodedImage or regular
Image if necessary.
This allows very smooth graphics that adapt based on the platform e.g. here we use the fontello font to show a rotating progress wheel, thanks to the smoothness of the font the progress looks far more refined:
InfiniteProgress ip = new InfiniteProgress();
int size = Display.getInstance().convertToPixels(20, true);
Font fnt = Font.createTrueTypeFont("fontello", "fontello.ttf");
FontImage fm = FontImage.createFixed("\ue800", fnt, 0xffffff, size, size);
We can create such an image using two methods, a fixed size/color image which you can use to assign a pixel size for such an image and a more "generic" method that will accept a style and adapt the icon for that style.
As we move forward we would like to integrate icon fonts far deeper into the Codename One stack, this would include integration with the designer tools etc.
Retiring The Old VM
Apple is pretty quick with with moving forward, they pushed everyone to 64 bit very fast and it seems they are poised to do the same with some new iOS 9 changes. This usually takes the form of requiring an xcode upgrade which is pretty easy for us to do since we just need to login to all the servers and update xcode on those machines.
This does pose a problem though, the newer versions of xcode require a newer version of Mac OS (Yosemite or even newer), unfortunately the older versions of xcode that still run the old VM don't work on Yosemite anymore and aren't maintained by Apple. We will try to wait until the last minute to upgrade in order to allow those of you who are still building with the old VM (e.g. in the enterprise setting) some time to migrate. However, you must migrate... Even versioned builds won't work with the old VM once the OS is updated so you can no longer rely on the old XMLVM builds to still work in the future!
Unfortunately some of our enterprise users just don't read the blog, social media posts or our repeated mailings on the subject...
Which is why we will be retiring the
ios.newVM build hint so those guys who just added it and forgot about it will be forced to re-evaluate its necessity.
We will expose a new flag:
ios.deprecatedDontUseThisFlagSeriouslyOldVM which you can set to true to force the old vm. But seriously...
Don't use it.