I got several build errors on my very new Codename One application:
The build complains on the FileNotfoundException class and the String split() method. Any idea why ?
xxx\Page.java:11: error: cannot find symbol
import java.io.FileNotFoundException;
symbol: class FileNotFoundException
location: package java.io
and
xxx\Page.java:97: error: cannot find symbol
final String[] parts = number_label.split("-");
symbol: method split(String)
location: variable number_label of type String
By the way, is that true that there is a restriction to use java 1.5 in CodenameOne ? I couldn't find where to say to compile with java 7.
Kind regards,
EDIT: This reply is somewhat out of date. Codename One supports a subset of Java 8 now although string.split() is still a problematic API call.
Codename One supports a subset of Java 5, you shouldn't try and change that since the server translation code relies on bytecode behaviors of the target Java 5 and only supports a very specific subset of the API.
The reasoning is simple, since Codename One has multiple VM implementations (iOS, Dalvik/ART, XMLVM/ParparVM, blackberry etc.) its really hard to test new stuff (e.g. newer bytecodes) and its really hard to add new API's in a way that will be totally cross platform. You can use StringUtils.split() to implement this functionality as well as StringTokenizer.
Limiting the API's also allows us to keep the executable efficient and small (relatively). Compared to a more full featured VM we are at least 5 times smaller in production. This is a big deal for mobile apps...
We are working on consolidating the various VM's on the server side which will allow us to add core VM API's more easily in the future as well as features like Java 8 support.
You can learn more in this answer:
How does Codename One work?
Related
Sometimes I don't notice that Netbeans imports the wrong packages inside a Codename One project. It causes me to waste time until I notice a such sneaky mistake. This happens me a lot of times, especially when I'm a bit tired of coding...
Is there any way to force Netbeans to don't propose and don't do any automatic import from packages different from the ones provided by Codename One and created by me inside my project?
Of course, if it's possible, it should be applied only to Codename One projects. I have also a Spring Boot project that, of course, needs different imports.
Currently I'm using Netbeans 10 with Java 8. Thanks for any hint.
Short answer is, it's theoretically possible but really hard. It would open the door for far worse problems.
The last time we checked about that it was only possible in two ways:
If we copied the entire Java module and built on top of that
If we built Codename One as a JDK
Both options are a bit problematic. The former would mean we would need to maintain the full Java package code and update it with changes to the IDE. We don't want to do that.
The latter would also be problematic since we don't support any officially supported subset of a JDK. It would also break the existing project structure and make things like running the project much harder.
I'm working on an app written in Codename One together with the parse4cn1 library, the combination of which is a real pleasure to use. However, I need support for a few things in parse4cn1 that are not implemented, most importantly ACL and was wondering if Chidiebere has any hints on how to do this (e.g. how did you implement parse4cn1 yourself - from scratch or copying the open source Parse SDK for Android)? If I manage to do something of a decent quality I will try to share back. Thanks in advance
I never got around implementing ACLs (it's still on the TODO list). parse4cn1's interface closes resembles the Parse Android SDK interface and I'll like it to stay that way for convenience. In this case, the interface of interest would be the ParseACL which is documented here.
The actual implementation will need to be done via REST API calls.
Things to bear in mind:
We use the Android SDK API simply for defining methods and signatures for the corresponding class in ParseACL but do not use the SDKs for anything can be be done via REST.
By design, any calls requiring the master key will not be supported in parse4cn1 due to security considerations. If really needed, the functionality should be exposed via server-side cloud code.
Pull requests without unit tests for the added functionality or breaking existing tests will be rejected.
See also the Contributions section of the parse4cn1 github repo.
Good luck with your implementation and I hope to see a PR from you soon ;)
It was implemented from a Java port on top of the REST API's here but was later modified to use the SDK's to allow things like push (which are now no longer relevant).
In the past I just contributed pull a request to the project to get the fixes/features I needed. It was really easy to work with and compile.
Say there we have the package encoding/json. Can I just create a package mypackage and embed all the functions (at least the public functions) into my package without to copy them by hand and basically do calls back to the actual json package? I'm developing a cross platform (Google app engine / native ) solution and I would find a such solution quite useful.
No.
It sounds like you want some sort of package inheritance, this is not a supported feature.
I'm working on a very simple web app, written in Go language.
I have a standalone version and now port it to GAE. It seems like there is very small changes, mainly concerning datastore API (in the standalone version I need just files).
I also need to include appengine packages and use init() instead of main().
Is there any simple way to merge both versions? As there is no preprocessor in Go, it seems like I must write a GAE-compatible API for the standalone version and use this mock module for standalone build and use real API for GAE version. But it sounds like an overkill to me.
Another problem is that GAE might be using older Go version (e.g. now recent Go release uses new template package, but GAE uses older one, and they are incompatible). So, is there any change to handle such differences at build time or on runtime?
Thanks,
Serge
UPD: Now GAE uses the same Go version (r60), as the stable standalone compiler, so the abstraction level is really simple now.
In broad terms, use abstraction. Provide interfaces for persistence, and write two implementations for that, one based on the datastore, and one based on local files. Then, write a separate main/init module for each platform, which instantiates the appropriate persistence interface, and passes it to your main application to use.
My immediate answer would be (if you want to maintain both GAE and non-GAE versions) that you use a reliable VCS which is good at merging (probably git or hg), and maintain separate branches for each version. The GAE API fits in reasonably well with Go, so there shouldn't be too many changes.
As for the issue of different versions, you should probably maintain code in the GAE version and use gofix (which is unfortunately one-way) to make a release-compatible version. The only place where this is likely to cause trouble is if you use the template package, which is in the process of being deprecated; if necessary you could include the new template package in your GAE bundle.
If you end up with GAE code which you don't want to run on Google's servers, you can also look into AppScale.
I have a class library which is a set of helper classes to develop windows phone 7 applications.
One of core helper classes I have in this library is responsible to provide location service functionalities, so it uses ILocationWatcher and references to System.Device.
Now the problem is even if I don't use this helper class (i.e. LocationWatcher will never be started) after submitting the app in marketplace, it shows "Location services" as one of capabilities my app is using.
I believe the way marketplace detects this, is more or less analysing all codes and libraries within the project.
How can we somehow override this behaviour?
Capabilites are detected using static analysis when your xap is submitted to the marketplace.
The location capabiltiy is reported if you reference the assembly System.Device and use the namespace System.Device.Location.
All assemblies in your XAP are analysed. Even ones you get from 3rd parties.
If you don't want the capability to be reported in the marketplace then remove the references which triggers its detection.
You may want to consider how you structure your shared/common libraries/code with this in mind.
You can check your used capabilities with the free capability detection tool supplied with the second Mango SDK beta. If you use location without defining it at the WMAppManifest.xml, the user will get a "Access denied" message and your app will throw an UnauthorizedAccessException. Afaik there is no possible way to circumvent this behaviour. It is meant as a security feature to warn users before they install a app so they can check on marketplace what features the application will want to use.
I don't believe it is analyzing the code. Rather it is using the manifest's Capabilities section to determine what is required. You can learn more about that section here:
http://msdn.microsoft.com/en-us/library/ff769509(v=vs.92).aspx#BKMK_Capabilities
Does the application's manifest include ID_CAP_LOCATION? If it does, and you aren't using it - it can safely be removed.