How do I - Use Include Source to debug native code - Trasnscript.pdf

How do I?
In this video I’ll discuss the “include source” feature. With include source we can get the native OS source code as a result of a build. This allows us to debug & profile on
devices.

Notice that this isn’t meant for manual native OS coding as we have the native interfaces feature that allows you to write native code. Include source is a very useful tool
when working with native interfaces and I recommend checking that video out too

Use Include Source
devices.

Notice that this isn’t meant for manual native OS coding as we have the native interfaces feature that allows you to write native code. Include source is a very useful tool
when working with native interfaces and I recommend checking that video out too

© Codename One 2017 all rights reserved
devices.

Notice that this isn’t meant for manual native OS coding as we have the native interfaces feature that allows you to write native code. Still include source is a very useful
tool when working with native interfaces and I recommend checking that video out too.

We can activate include source by launching Codename One Settings and checking the include source flag, once that is done we can send a build to the servers

Results
The resulting builds for iOS and Android will include an additional sources file that includes a native OS project. In this case we see two builds of the kitchen sink demo

For iOS we have the sources tar.bz2 file which includes an xcode project

For Android we have a sources.zip file which includes an Android Studio gradle project. We’ll go over both soon but first I want to discuss a couple of points

Include Source
✦Includes the source code generated in the server
in the build results
✦Slows down the build process
✦Requires basic subscription or higher
✦Works for UWP & Desktop too
When you build a Codename One project with include source turned on we just zip the project we generated in the server

This slows down the build which is why this isn’t on by default

You need a basic or higher subscription for this to work since it slows down the build

I’ll only discuss iOS & Android in this video but include source works for other platforms too

Results
When we download and unzip the respective source archives we can see the Android & iOS source structures

Results
The iOS sources are stored under the dist directory

You will notice two important files the xcodeproj which intuitively seems like the “right file” but it’s not and you shouldn’t open it!

Instead you need to open the xcworkspace file… This file includes the full project and that’s the project that will run. When we double click the xcworkspace file we get a
warning about a file downloaded from the internet and then xcode launches

In the launched file we can just press play to run the project in the native simulator or on device. Notice you can connect your device and run directly on it!

The iOS simulator launches and you can run the app using Apples native functionality although Apple doesn’t implement all features in the simulator. A good example is
push which doesn’t work on the native simulator and only works on the device

Running in the native OS is valuable because you can debug and profile on the device. This is the about dialog for the app, lets put a breakpoint on the dialog show
functionality so we can debug that

I’ll put a breakpoint on all dialogs by searching for the Dialog class. This class is translated to native code as a file ending with Dialog.m. Notice the files are just the
package names and class names with underscores.

I’ll search for the show method that accepts 4 strings. The method naming convention is three underscores after the method name followed by the argument types. This
allows method overloading. Objects are listed with their full class name of java lang String. This makes finding the right show method pretty easy, we can now set a
breakpoint here

In the simulator I reopen the dialog and now the breakpoint is triggered. I can inspect the variables by hovering over them. I can look at them in the variable section at the
bottom too. Printouts appear on the bottom right and the full stack is on the left where I can see the full class and method names. I can click specific stack frames and
walk up the stack to inspect the methods that triggered the show method all the way back to the original lambda call from the kitchen sink demo.

This is a remarkably powerful tool and it’s especially useful when debugging native interfaces.

Moving on to Android we launch Android Studio and open an existing Android Studio Project. We select the directory containing the gradle script file. We get a warning
about the gradle location in the server and then wait a long while for Android studio to launch…

Once Android studio launched it will fail to compile the code, we need to open the preferences UI for Android studio to fix that

The preferences can be opened from the menu in Mac and Windows although in slightly diﬀerent locations

Inside the preferences we need to select the build tools section and pick the current local copy of gradle which you can download from the web. Right now we need
gradle 2.11 but this could change so we suggest checking out with our support if this changes in the future. Once the local gradle is configured you can just press OK
and everything will update automatically

Now we can just press the debug button and pick the device in the UI, notice that on Android debugging on devices is MUCH faster than using the Android emulator
which is why I’m using a device here

Let’s place a breakpoint in Dialog like we did in the iOS version, we can see the source code of Codename One and the Android implementation right here and open the
Dialog class. Within this class we can find the show method with 4 strings and set a breakpoint here. Now I can just click the dialog button on the device…

And we hit the breakpoint… Again we can step thru the stack and inspect variables but notice an interesting thing. When I try to go to the classes from the kitchen sink it
shows me binaries not sources.

The reason for this is simple. When you build a native app only the binary classes are sent to the server. In Android we can just package the class files and move along, in
iOS we translate all the class files to C files so we have native sources for everything.

Thank You!
Thanks for watching, I hope you found this helpful

How do I - Use Include Source to debug native code - Trasnscript.pdf

More Related Content

Similar to How do I - Use Include Source to debug native code - Trasnscript.pdf

More from ShaiAlmog1

Recently uploaded

How do I - Use Include Source to debug native code - Trasnscript.pdf