I'm new to this topic and couldn't find any guides concerning this. I'm wondering how the Today Extension files from a xcode project (originated from the CN1 iOS debug build sources) needs to be added to the actual CN1 project in order to get integrated properly.
We don't have builtin support for that and didn't really study it. We never had official support for Android widgets either.
Both can be used through native code though. E.g. in this case you can use ios.plistInject to add the necessary plist changes. The actual UI/code that implements them should be done in a native interface anyway.
I have seen answers to this question using other tools but I cannot see how to do it with CN1. If I release a LITE version of an app, what is the process for the user to get the PRO version once they have paid?
Like I said I have seen other answers but they talk about settings within the development studio itself which makes me think that it may be related to the toolset I am using - in this case Codename One.
Thanks.
P.S. I will need to know this for both Android and Apple
This will work for all the platform Codename One supports and is explained in this tip. Effectively you keep two or more codenameone_settings.properties and multiple Main packages/classes. Then toggle them by replacing the codenameone_settings.properties file.
I recently read FIRST CLASS ECLIPSE SUPPORT which made me expect a cn1lib-wizard. But there still is none, right?
The gist of the article is that we will update the Eclipse plugin with the NetBeans & IntelliJ versions. With the trend of migrating towards common code across IDE's within our plugin (the new settings UI) this should be much easier and Eclipse should no longer be out of date with the other IDE's.
I'm not sure when we'll get around to do the library template, unlike the other features it requires some work since the Ant implementation on Eclipse is rather different. So it's hard to give a specific date.
After installing this plugin: https://github.com/TranWare/cordova-plugins which should work with this device: http://www.idtechproducts.com/products/mobile-readers/176.html
I am trying to use it but when I called it "IDTech is not defined" even I saw the plugin running on debug mode!
Are you developing for Android or iOS (or both)?
Looking at the source of this plugin, its Android only. Unfortunately, it looks like nobody has written a proper Cordova plugin for the IDTech card reader that supports both platforms :(
I did find another plugin, but this one is iOS only: https://github.com/deboorn/iMag-Cordova-Plugin. Maybe give that one a shot instead?
I should note I've not tried either of these plugins personally, but I am doing some research in adding support for this device in a Cordova app I've built and came across that plugin (and your post). Best of luck!
I'm prospecting alternatives to develop for multiple mobile platforms, and have found Codename One, that uses Java as lingua franca, instead of HTML/CSS/JS or scripting languages.
What I couldn't find is how does it work. Does it bundle a JVM with the application for iOS and Win7, and uses Dalvik in Android? Does it translates source code to native, and do we have access to this source code? Is there other magic, considering they promise "no compromise"? What limitations should I be aware while coding agnostic Java?
Preemptive strike: this is a question about Codename One, not about which cross-platform should I choose or if I should go native or if I should go web.
Codename One has an optional SaaS approach so this might (and probably will) change in the future to accommodate improved architectures. Notice that Codename One also provides an option to build offline which means corporations that have policies forbidding such cloud architectures can still use Codename One with some additional overhead/complexity. It also means you can use it for free without ever working with the build servers.
Currently on Android the standard Java code is executed as is. Java 8 syntax is translated using retrolambda for all platforms when its used. This allows it to be compatible to all Android versions as well as other ports.
On iOS Codename One built & open sourced ParparVM which is a very conservative VM. ParparVM features a concurrent (non-blocking) GC and it is written entirely in Java/C. This effectively means that an xcode project is generated and compiled on the build servers so its effectively as if you handcoded a native app and thus "future proof" for changes made by Apple. E.g. with recent 64bit and bitcode changes to iOS builds ParparVM needed no modifications to comply with those changes.
In the past Codename One used XMLVM to generate native code in a very similar way but the XMLVM solution was too generic for the needs of Codename One.
iOS builds are compiled and signed on Macs in the cloud using xcode (the official Apple build tool). This makes them compatible with current/future changes from Apple and allows developers to use Windows/Linux while targeting iOS. You can read more about the compatibility of ParparVM to iOS here.
In the past Codename One supported Windows Phone using a C# translator that relied on XMLVM but it was not an ideal approach. Notice that the XMLVM backend that translates to C# is very different from the one that was formerly used to translates to iOS. Codename One chose to discontinue that old backend as it wasn't as powerful as the new UWP backend and doesn't match Microsofts goals moving forward and focusing on UWP (Universal Windows Platform).
For Windows 10 desktop and Mobile support Codename One uses iKVM to target UWP (Universal Windows Platform) and has open sourced the changes to the original iKVM code in the Codename One github repository.
Notice that UWP builds are done on a Windows 10 machines in the cloud thus allowing developers to use Mac/Linux or older versions of Windows when building native windows apps...
JavaScript build targets which are available on the enterprise level subscribers use TeaVM to do the translation statically. TeaVM provides support for threading using JavaScript by breaking the app down in a rather elaborate way. To support the complex UI Codename One uses the HTML5 Canvas API which allows absolute flexibility for building applications.
For desktop builds Codename One uses javafxpackager, since both Macs and Windows machines are available in the cloud the platform specific nature of javafxpackager is not a problem.
What makes Codename One stand out is the approach it takes to UI where it uses a "lightweight architecture" to allow the UI to work seamlessly across all platforms and be developed almost entirely in Java. It is augmented by the ability to embed "heavyweight" widgets into place among the "lightweights". You can learn more about this in this blog post. Notice that at this time peering is undergoing some improvements and now supports more elaborate usages such as layering.
A lightweight component is written entirely in Java, this allows developers to preview the application accurately in the simulators & GUI builder.
Codename One achieves fast performance by drawing using the native gaming API's of most platforms e.g. OpenGL ES on iOS.
The core technologies behind Codename One are all open source including most of the stuff developed by Codename One itself e.g. ParparVM but also the full library, platform ports, designer tool, device skins etc. You can learn more about using the Codename One sources here.
FYI Shai Almog, the author of this answer, is the CEO of Codename One.
Codename one took very balanced approach to portability. I would like to add a pragmatic comment.
From the user interface side, CN1 does paint all its UI on platform-provided canvas. It tries to mimic platform native look and feel, if you choose it, but has as much success as Swing had with its "native platform look and feel", because native platform constantly changes, and "native l&f" always lacks behind and in most cases feels not quite right.
But, if you choose platform-independent look and feel (which is the sort of the trend today), you are not restricted by Codenameone's default component set set in any way: it's just like Swing with its cross-platform look and feel ("Metal" etc.). Which is good.
From the language side: on iOS it is java compiled to C which is then tied to hand-written Objective-C, and it does not bundle VM, only portability layer. Most important here is the fact that java is compiled to C and not Objective-C, which make it faster then idiomatic Objective-C code, because it does virtual or, more often, direct method invocations instead of slow Objective C message dispatch. Which is good.
It also may seem little faster on Android, because, while using Dalvik/Art, it does not use Android native UI which is bulky compared to CN1's. This can make dynamic UI creation faster in runtime, which is good.
One of the strongest points of CN1 approach is its emulator (implemented over desktop JavaFX canvas) which you use to develop software. Emulator makes use of same UI code and portability APIs as on mobile platforms and lets you use IDE of choice for debugging. It restarts quickly, and edit-compile-run cycle is very sustainable compared to android. Which is good.
Second very strong point (main one!) is open nature of their UI library, all native code and bytecode-to-C translator. If you spend some effort, you can avoid building Android/iOS ports on their farms and untie yourself from their particular revision of product (but not from quite a few value-added services they offer, which are not open source!). Depending on your situation, this may (or may not!) be quite good for you!
Weak point of Codenameone is its less-then-ideal maturity, which means you can easily shoot yourself in the foot using basic UI components, if you use them the way they were not indended to be used. Also it means that its java portability layer is not big enough (and has holes in it) to cover everyone's need, and you may have to use native in some places, and port other pure java libraries, too.
Also, current state of graphics performance is sub-optimal; if you get bunch of text on screen, you'll easily miss 16msec fluid animation/repaint time limit, this can be worked around by double-buffering, but it also has its limits. Luckily, there is still room for optimization in implementation on both main platforms, hopefully they will improve it.
Overall, Codenameone has good niche as a cross-platform framework for several classes of applications; you may find a value in their services, too.