I was ordered to deliver an app in 2 versions : one demo/light (limitted features) the other full (all features). I have a boolean in code which tells which one is running. They both run as expected in the simulator or on a test device (iOS and Android).
Now I want to distribute them. So I read that it was possible with XCode to define different targets corresponding to the light / full versions and with Eclipse it was possible to define the base project as a library and then create 2 projects also corresponding to the light / full versions.
Before I start messing around with my app project, is there a recommended way to achieve my goal with CodenameOne maybe via build hints that would change the app name and the boolean inside the code depending on a build hint value ?
EDIT 19/09/2016 (working methodology)
Following Shai's advices here are the steps I followed to generate a light version based on the full one (in case someone encounters the same case) :
Under your IDE (Eclipse or whathever) copy and paste the base package in the src folder and rename it com.packageLIGHT.appName (simply append LIGHT to the package name, don't use underscore or space since it will be considered as an illegal character later by Apple)
=> So now in src folder you should have
src
|- com.packageLIGHT.appName
|- com.package.appName
Then in com.packageLIGHT.appName remove all files except MyApp.java (aka the main file). In this file add import com.package.myApp.*;
3.1. (ECLIPSE) In "Run/Run Configurations" menu copy the existing config and paste it as Simulator_MyAppLIGHT and in arguments change it to "com.packageLIGHT.myApp.MyApp".
3.2. (NETBEANS) The "Run/Set Project Configuration" does not seem to work as expected since any configuration that might be selected leads to the same default behaviour. However applying step 6. and running the project in the simulator afterward has the expected result.
Now you should be able to run both versions by running the different configurations.
For iOS (not sure if it is also needed for Android) you have to generate another pair of provisioning files. So move the existing ones in iosCerts/FULL and use CN1 wizard to generate the "light" version provisioning files where you'll adapt the package name to match "com.packageLIGHT.myApp". Store the generated files in iosCerts/LIGHT. There is no need to overwrite the existing certificates (more on certificate here).
Finally replace in "codenameone_settings.properties" the original package name with the "light" one for the lines codename1.ios.appid and codename1.packageName. Also change the iOS provisioning files to iosCerts/LIGHT or FULL depending of what you want to build.
Now when you send the Android / iOS build to CN1 server it will build either the "light" version or the full one depending on what package is written in "codenameone_settings.properties".
Please note : if at step 6. you get NullPointerException on build.xml on line 469 (android build) or 344 (iOS build) which deals with certPassword="${codename1.android.keystorePassword} (android build) or appid="${codename1.ios.appid}" (iOS build) and you're using CN1 plugin version 1.0.0 20160812 under Eclipse then Shai's comment below may be worth it
If you want 2 distinct versions of the same app then you need 2 distinct packages since the thing that defines the app uniquely in the store is the app package. There are two common ways to do it:
Place functionality in cn1lib and build two apps
Build one app and just swap the codenameone_settings.properties file
The first one should be pretty clear but might be a bit painful to work with as you can't run the cn1lib and might run into issues debugging it.
The second one is actually rather simple. Create the main version of the app then add the package to the demo version and copy the main file there.
To run the demo version just change the package in the IDE "run settings".
Copy your codenameone_settings.properties to a separate file and just replace all the regular package names to the demo package names. When you want to build the "demo" version replace the codenameone_settings.propeties files with one another, you can automate that with a script obviously.
Related
In the Simulator, CEF is correctly used, but I noticed that local JavaSE builds use JavaFX. Can CEF be used in local JavaSE builds?
My main Stub class already contains the following:
Class.forName("org.cef.CefApp");
System.setProperty("cn1.javase.implementation", "cef");
But (when running the resulting jar on windows) JavaFX seems to be picked by the build. Do I need to copy the cef folder to the target javaSE output? I tried doing this but it also didn't work
If I run the resulting jar with java -jar, the CEF output that is seen when running the simulator (copied below) isn't printed in the console
Adding CEF to classpath...
Has CEF been excluded from local JavaSE builds explicitly? If so, it would be great if there could be a build hint to force the resulting build to look for cef libs in the /lib directory
Not so much excluded as not added. We need to add some support for that. You would also need to place the right DLLs in the right path for this to ultimately work. We need some bootstrap code similar to what we did in the Codename One Designer tool to support CEF.
I am trying to run AppEngine Standard Environment inside PyCharm.
The problem is when I include Google App Engine SDK as part of External Libraries, but it contains multiple version of old libraries that somehow has higher priority than the library I have in my env folder.
Specifically, it is loading jinja2-2.6 which doesn't work for Python 3, even though I have jinja2-2.11.3 in my env/lib.
Pycharm does have a bit of issues with its library system as many users have reported before. To Adjust the version of your libraries in PyCharm you must access the interpreter options relating your python interpreter for your current project, you can access this option by searching in the menu Settings/Preferences or by pressing Ctrl+Alt+S
In this dialog you can view the packages available and their current running versions. You can update the version by clicking on the ▲ symbol next to the version. if you have trouble upgrading to a specific version you may need then you can alway remove a package by clicking on the "-" on the right hand side after clicking on the package you wish to remove. After removing the package you can add a new one by clicking on the "+" button right on top of the "-" button. Here you can search for the package you need and before installing a package, you can check the specific version checkbox to search for the version you require in the dropdown menu next to it.
This link contains images for what i'm explaining here.
Remember that these packages are taken directly from the pip so if you have errors using the interface you can always try to manually edit the packages (also described in the link).
To upgrade a specific package using pip for python3 you can use the following command:
pip3 install --upgrade PackageName
I've recently been asked whether it was possible for me to convert my older theme contributions to the new Qooxdoo packaging system. So I installed Qooxdoo 6.0 and got a first test app running - not without problems because the instructions in the official docs are a bit buggy (e.g "npx qx" is an unknown command with my Ubuntu 18.04). I also read about the packaging system and what to do to install one of the existing packages from the Qooxdoo repository.
Then I followed the steps described in section "Create a new package". This procedure resulted in a folder structure which looked familiar at first sight, but a closer look made me wonder: There are two resource folders now, one is under "source" (as I would have expected) and the other one is under "source/class/[mypackage]". I also noticed that there is a "demo" folder in "source/class/[mypackage]", which used to be a top-level folder in previous Qooxdoo versions.
I then copied the theming files of my contribution to "source/class/theme", the demo app files to "source/class/[mypackage]/demo" and the demo resources to "source/class/[mypackage]/resource". After compiling the project I managed to run the demo app, but only without the expected resources (no icons, no fonts, no background images). The theming as such appears to be applied properly, but I keep getting plenty of error messages telling me "404 (Not found)" and "Image could not be loaded".
What am I doing wrong?
I guess you are running into a bug with our template for packages ... please open an issue https://github.com/qooxdoo/qooxdoo-compiler/issues/
As for how to do it. Have a look at an actual theme package for 6.0 https://github.com/ITISFoundation/qx-osparc-theme there you can see the required structure.
Also, for this kind of question, interactive help is probably best. Visit the qooxdoo chat on https://gitter.im/qooxdoo/qooxdoo
I created a sample Codename One project in netbeans and generated a desktop build.while installing .exe its not giving me the provision to select specific location to install.
Once I got the exe from codename one dashboard,I installed the .exe and it got installed in default folder like c://user/AppData/...enter image description here
The goal we had when we created this was to make the installation minimal just like a mobile phone/tablet installer. The experience might be slightly different for the ZuluFX version where we have more control over the result.
If not you can try the MSI build (not supported for Zulu) which might give you a better install experience.
I changed source of DotNetnuke (a little!) and I want to package an install version of my new DotNetNuke.
How Can I do this?
p.s: I know It's not recommended to change the source but I have no another option
(Telerik calendar do not support my date format and I have to replace it with another calendar !)
Thanks in advance
Answer depends on what you have changed, but the simplest way is to deliver patch that should be installed after normal dnn installation. For example, if you have only changed dll, you can ask to follow normal dnn setup instructions and finally relpace dll. If it's more than on file, you can review how dnn upgrade package is built. It follows same folder structure and places only changed files. So if you have couple of dlls changed in bin, the will be placed in bin folder, and if you have changed some ascx file it should be placed in same path by creating same folder hierarchy.
You can also create a package that can be installed to deploy your changes but for smaller set of files it will be complecated.
Let me know if you need more help.
You can package any change into a DNN install package by including the compiled files along with a DNN Manifest file. This can then be installed via the Extensions page. A manifest file is an Xml file which controls where the contents of an install zip are installed. You can make it as simple or as complicated as you need. You can also include xml merge statements to make changes to the web.config file upon install and uninstall. See the wiki for reference : http://www.dotnetnuke.com/Resources/Wiki/Page/Manifests.aspx
Incidentally, you may have been able to deliver your modified telerik source as a separate provider, and configure it via the web.config, thus saving you from modifying the source code. To do something like that, you would build your own module, and plug it in and replace the standard Telerik references.