iOS Native build and method 'optimization'

[nickk...@gmail.com]

Unused methods are erased from iOS builds leaving just an empty return statement. This makes developing native extensions for iOS a little tricky, here's the process I'm using similar to something I've read from Steve I think in the past.

1. Make the native interface and generate native code

2. Send an iOS build including source.

3. Open the source in xcode and implement the Objective-C code

4. Run and test from xcode

5. Copy the working implementation back to that native/ios directory in the Codename One project

6. Build via Codename One as normal.

Problem is with callbacks - if the callbacks aren't used (because the implementation isn't there) then they are reduced to empty return statements and therefore step 4 can't be completed in xcode. 

I've also had an issue in the past where a method that WAS used in the native code was optimized a way and in this case there is no way to get it back. Could this feature be optional, or just apply to release builds, or not apply to 'include source' builds or something to make this process easier.

Thanks!

[Shai Almog]

We actually have code that scans the native code for usage of methods and tries to "deopimize" them. Both Steve and myself have no clue why this code isn't working...

The workaround I use for callbacks is something like this:

boolean flag;


if(flag) {
    MyClass.myCallback();
}

It's important that flag is not private otherwise javac will optimize this away. It can be package protected as javac can't know what you'll add later on. This fools the optimized but doesn't cost you. Notice that the if statement needs to be in a path that you will reach at some point in the code so it doesn't get removed on its own.

Making this feature optional is impractical as it will balloon build sizes and slow it down.
Making it only for release builds is a recipe for disaster, we want as much consistency in builds as possible.

[Dave Dyer]

The build process uses a crude string match process to determine what native methods use.
You ought to be able to fool it by adding false matches as comments; this would require matching
the fully elaborated method name created by the code generation process, but you can get the
pattern by looking at the source code from the build.

[Shai Almog]

This is for callbacks so there is no need for that. The pattern already exists but for some reason it doesn't work