Deprecations, Simplified cn1lib installs & Theme Layering

Deprecations

We decided to discontinue support for building without a certificate, this support was added initially because generating an iOS certificate was so difficult and we wanted developers to see that "it works" before committing to the expense. However, this process is wrought with bugs that are often hard to trace back and error prone. Added to that is the fact that we now have the new certificate wizard which makes the process simpler thus removing the final blocker (no need for a Mac). We will block this functionality in the build servers by next week and thru the plugin after that.

We also decided to remove the ability to push with a null device id with the new push servers overhaul. It was a tough decision to make but I'm sure you will get behind it when you see the other features we intend to add specifically: delivery reports, status & batched pushes. We'll probably restore this functionality in the future in a different form that will allow other features such as smart segmentations etc. The API will probably take a very different form and be designed for server side usage.

Last but not least, we still kept the original web UI that Codename One used in the old appspot server. If you are still using that UI then it will be discontinued soon! We suggest you migrate to the new web UI in this website. If there are features or capabilities missing from the current web UI please let us know.

Build Hints in cn1libs

Some cn1libs are pretty simple to install, just place them under the lib directory and refresh. However, many of the more elaborate cn1libs need some pretty complex configurations. This is the case when native code is involved where we need to add permissions or plist entries for the various native platforms to get everything to work. This makes the cn1lib's helpful but less than seamless which is where we want to go.

If you don't intend to write a cn1lib you can skip to the next section, for you this post just means that future cn1lib install instructions would no longer include build hints... However, if you are writing cn1libs then this is a pretty big new feature...

We now support two new files that can be placed into the cn1lib root and exist when you create a new library using the new project wizard: codenameone_library_required.properties & codenameone_library_appended.properties.

In these files you can just write a build hint as codename1.arg.ios.plistInject=... for the various hints. The obvious question is why do we need to files?

There are two types of build hints: required and appended. Required build hints can be something like ios.objC=true which we want to always work. E.g. if a cn1lib defines ios.objC=true and another cn1lib defines ios.objC=false things won't work since one cn1lib won't get what it needs...In this case we'd want the build to fail so we can remove the faulty cn1lib.

An appended property would be something like codename1.arg.ios.plistInject=<key>UIBackgroundModes</key><array><string>audio</string> </array> Notice that this can still collide e.g. if a different cn1lib defines its own background mode... However, there are many valid cases where ios.plistInject can be used for other things. In this case we'll append the content of the ios.plistInject into the build hint if its not already there.

There are a couple of things you need to keep in mind:

This code happens with every "refresh libs" call not dynamically on the server. This means it should be pretty simple for the developer to investigate issues in this process.

Changing flags is problematic - there is no "uninstall" process. Since the data is copied into the codenameone_settings.properties file. If you need to change a flag later on you might need to alert users to make changes to their properties essentially negating the value of this feature... So be very careful when adding properties here.

The rule of thumb is that a build hint that has a numeric or boolean value is always required. If an entry has a string that you can append with another string then its probably an appended entry These build hints are probably of the "required" type:

Theme Layering

Theme layering is something that comes up often in support queries and we don't have a good reference for it so I decided to write a quick tutorial on that. There are two use cases in which you would want to use layering:

You want a slightly different theme in one platform

You want the ability to customize your theme for a specific use case, e.g. let a user select larger fonts

This is actually pretty easy to do and doesn't require re-doing the entire theme. You can do something very similar to the cascading effect of CSS where a theme is applied "on top" of another theme. To do that just add a new theme, make sure to remove the include native theme constant in the new theme. Then in the new theme define the changes e.g. if you just want a larger default font define only that property for all the relevant UIID's and ignore all other properties!

Notice, this assumes the name of your main theme is "Theme" (not the layer theme you just added). This is important since the original code relies on the theme being in the 0 position in the theme name array which might not be the case! Then when you want to add a layer just use:

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.