FAQ
What Is Codename One?
Codename One is a free open source solution that allows you to rapidly build native applications to all mobile devices using Java & optionally a GUI builder. The framework provides full access to the underlying native platform while still providing remarkable portability.
Codename One consists of a Client Library, IDE plugin, Designer tool (GUI builder, theme designer, localization editor etc.), Simulator environment, Build servers & cloud provisioning services.
Codename One consists of a Client Library, IDE plugin, Designer tool (GUI builder, theme designer, localization editor etc.), Simulator environment, Build servers & cloud provisioning services.
Will Apple Allow This? Doesn't their EULA (End User License Agreement) Prohibit Things Like This?
That's old news. Apple revisited their EULA and now allows tools such as Flash, Lua and other languages/meta-platforms on the device as long as the applications comply with the iOS store guidelines. This means you as developers would need to work hard to create high quality applications and test them on the devices to see they behave properly but you do not need to code them manually in Objective-C.
If Adobe can submit Flash applications to the iTunes store so can we.
Is Codename One Related To LWUIT?
The Codename One client solution is based on LWUIT although allot was changed.
Is Codename One Free For Commercial Use?
Yes! No royalties, ads or any such limitation exists!
The project is entirely open source so placing unfair stipulations is something we will never do.
The project is entirely open source so placing unfair stipulations is something we will never do.
Do I have To Use the Cloud Services?
No.
They are entirely optional, however they make the process of building to multiple devices much easier. Please note that we do not provide instructions or support for offline building however plenty of resources exist on the internet for doing that.
They are entirely optional, however they make the process of building to multiple devices much easier. Please note that we do not provide instructions or support for offline building however plenty of resources exist on the internet for doing that.
Is My Source Code Sent To The Cloud?
No.
We only send compiled bytecode to the cloud and process that bytecode. We don't touch your source code.
There is a special case with native code which must be sent in source code form since it can't be compiled on the client e.g. Objective-C code can only be compiled on a Mac with XCode.
All communications with our servers are done over SSL.
We only send compiled bytecode to the cloud and process that bytecode. We don't touch your source code.
There is a special case with native code which must be sent in source code form since it can't be compiled on the client e.g. Objective-C code can only be compiled on a Mac with XCode.
All communications with our servers are done over SSL.
Are The Cloud Services Free?
We limit heavy resource usage to avoid abuse but we intend to always offer a basic cloud service for free. We provide a premium paid cloud and commercial hosting options but we see great value in keeping the cloud free for hobbyist and small development shops.
We also provide prominent community members with an option to apply for a free pro/basic account through our community outreach program.
We also provide prominent community members with an option to apply for a free pro/basic account through our community outreach program.
Where Is The Source Code?
Here.
Can I Use The Full Java SE API & Language Features?
The iPhone port and Android both support the full Java SE 5+ language features and a wide range of the Java SE API's. However, its very difficult for us to properly test and optimize the iPhone port for such a wide target. Furthermore, in order to support RIM devices and J2ME devices we need to limit ourselves to the CLDC 1.1 Java subset.
That is why we artificially limit the build path and features to that language/API level, this limitation can be removed manually from the build.xml file but we don't recommend it since it might trigger issues.
We could feasibly support these features in the future via tools such as retroweaver etc. These tools have implications of their own so we will only adopt them if there is justified strong demand for these features.
That is why we artificially limit the build path and features to that language/API level, this limitation can be removed manually from the build.xml file but we don't recommend it since it might trigger issues.
We could feasibly support these features in the future via tools such as retroweaver etc. These tools have implications of their own so we will only adopt them if there is justified strong demand for these features.
Can I Add External Library JAR's To The Classpath?
Not at the moment, we intend to offer a library API in the future. The main complexities are in enabling native interfaces for such external libraries.
Where Is The Windows Phone 7 Port?
Windows Phone 7 is pending for now, we intend to add it during the public beta cycles.
What About Languages Other Than Java?
We would love to support additional languages on top of our solution such as Jython, JRuby etc. This seems like a feasible endeavor and we hope the communities for such language implementations would help us in that effort.
