We've just launched a new library project type for Codename One, this is very preliminary but we think this is pretty much the final direction we will take with the Codename One library support.
To get started just create a new project and select the Codename One library project as your option. This will generate a cn1lib file when you build the project which you can just place in a lib dir of any new Codename One project in order to distribute binary libraries. You will need to use the Refresh
Libs right click option when adding a new library to a project. The obvious question we get quite frequently is: Why not just use
Jars? There are several different answers here:
So now that we have the basic requirements in place what is actually happening and what's a cn1lib file? The cn1lib file is a zip containing between 2 - 7 zips within it. The two required zips are one containing the compiled classes of the library and the
- We only support a subset of Java 5 hence something might not be supported and we will fail.
- We expect code to be compiled in a specific way (target 1.5 etc.) we just don't test other configurations and they are likely to fail.
- We would like to enable native device code, e.g. including an Android specific JAR or iOS specific .a library, this is possible with our file format but impossible with JAR's.
- We want intellisense code completion to work properly (include the javadoc when you use the library) while this is possible with jar's its not automatic.
- We want everything to integrate with the Codename One designer tool (this is work in progress, more on that later).
other one contains stub sources for the library. We run a doclet on your sources and generate sources that only contain the signatures and javadocs, this allows code completion to work correctly in the various IDE's without you having to do anything about it and still allows for proprietary libs. Other than that we package into zips all the content of the native directories for every one of the platforms, so if you used Codename One's ability to generate native interfaces then this will all be packaged in source form into the library. To keep proprietary data there you would need to use a library such as a jar (for Android, Blackberry & J2ME) or an 'a' file for iOS. That gets into the territory of native OS programming which is a bit out of the scope of this mini introduction so I won't get into that. I hope you guys start banging on the tires of this tool and let us know how it works out for you.
Notice: This post was automatically converted using a script from an older blogging system. Some elements might not have come out as intended.... If that is the case please let us know via the comments section below.