LCL for Android

As the maintainer of LCL-WinCE of course I was quite shocked when Microsoft dropped Windows Mobile into the limbo and announced that native applications would be restricted to a very small list of favorite partners. Because of this, since almost 1 year now I have been trying to port the LCL for Android.

My first success was in 19th January 2011 when I first built a good x86-linux -> arm-linux cross-compiler which I have been using ever since and I hosted here: http://sourceforge.net/projects/p-tools/files/Free%20Pascal%20for%20ARM/

After that I slowly started exploring Android and the SDK with many pauses. My free time floats a lot depending on the work load, my mood and my current interests. I have other hobbies which alternate as my biggest interest from time to time. The most important ones are: trains (reading news and discussing in skyscrapercity as well as travelling), politics (I'm right wing / conservative), keyboard playing and Pascal programming.

Ok, so next thing around in August I got some bounties which motivated me to make a good push. When I started we were in Android 2.2 still, and I bought a HTC Wildfire which came with 2.1 and can be upgraded only up to 2.2. At this time the perspectives for native applications were quite doomed, you had to interface with Java via the horrible JNI, I got pissed off by that and I developed an alternative system which worked by running a native executable and communicating with pipes with a Java machine. I posted about it in the android-ndk Google group and the Google guys hated my idea, they told me to buy and iPhone and try programming for that instead =D Well, I could do that, but seriously the Lazarus community is on a high mood for Android support, I don't remember yet anyone asking about iPhone support ... even requests of WebOS and Bada were heard. My hacky development strategy might sound like a bad idea, but I had many motivators for it:
1> If you can only have a library then the way LCL applications work changes dramatically =( I'm not sure yet how this will be worked around. You cannot keep the same main project file if Android requires a library and you also need changes in the project code flow.
2> FPC has a lot more bugs for library development then for executable development, specially in ARM-Linux
3> Using my method I could access the entire SDK without JNI! A true blessing. So I could quickly push some controls and get things working.
4> I also hoped that if people pushed then Google would flexibilize and support executables, but now I think I was too optimistic. At that time Android 2.3 was released and it brought a lot of improvements for native applications, but ever since there were very few changes in the NDK, so I lost my hope that Google would support native executables.

The alternative way would be creating a native library which draws all controls, and there are enourmous challanges in doing this. So, fast forwarding a bit into the future, after a bounty I got some expertise in NDK development with OpenGL so I got quite animated and I started a huge push to see how far I can push LCL-CustomDrawn until I run out of steam.

These days I feel like soldiers must have felt in the Market Garden operation, running against time to take all bridges in the way. I am not trying to consolidate the entire area, I just need to make as many breakthroughs as possible in as many key areas as possible to make sure that my development strategy works. Every time that we start doing something which was never done before, like LCL in Android you have a huge uncertainty about whether or not it will actually be possible to work, or if I will face a huge wall somewhere, like a compiler bug or a problem which needs a lot more steam then I got to solve ... so I want to clear the way and establish that my strategy indeed will work.

So far I have already taken the following bridges:

1> Lazarus Custom Drawn Controls - The first one to be tackled, it is far from complete, but I advanced it so well and so fast that it is clearly proven that we can have our own set of custom drawn controls inside Lazarus

Reference: http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls

2> Developing the major structure of LCL-CustomDrawn to allow painting with a non-native Canvas into a native surface. I already implemented this for Win32, X11 and Cocoa, so we are quite advanced here.

3> Develop a system to clip the painting of sub-controls and also clip events from sub-controls inside a form. In LCL-CustomDrawn TWinControl will be non-native, because some platforms like the Android surface do not support it. I have achieved success here too.

Now I am trying to push into a last bridge, which is resisting heavily:

4> Achieving a minimal LCL-CustomDrawn application which can run in Android and paint at least a rectangle or something.

I am facing big challanges in this task, the major ones being that when I simply include the LCL the application starts to crash, even if I don't call anything from it =( I have narrowed down to cwstrings, which is a major source of crashes, so I disabled it, but now the application crashes when clicking on it. I tryed to comment out all initialization sections in the LCL, but it didn't help. My greatest fear is a compiler bug somewhere which would reproduce only in big programs like LCL apps and stop me =( But so far it appears that I am going well, let's hope we will succeed here and clear 1 more obstacle in this difficult road.

Edit: I managed to get it working now, the second problem was introduced while debugging the cwstring issue. Now it works fine =) So we are each day closer to have LCL-CustomDrawn running in Android. From what I can see my snapshot compiler has no bug which could defeat us, so the path is ready =)

Edit2: Now it loads the application and it can draw some green stuff =D Really exciting days for LCL-CustomDrawn-Android. It still doesn't do anything useful, but the entire fact that it loads without crashing and can render something is excellent.

Remember, Remember ... The History of Debugging

Debugging your application can be an intriguing task. And analyzing what happens in your application, and what went wrong (or maybe right), often requires the developer to keep an eye on quite a lot of data.
Sometimes that means not only to look at the data as it is on the current step of execution, but also to compare it to what it was on the previous step(s).

Lazarus does now provide a history overview for watched values, locals, and call-stack. Each time your application stops, a record of this data is made and stored.
By default Watches and Locals are recorded for the current stack-frame/thread. But if you browse other frames or threads by selecting them in the stack or threads overview windows, then Lazarus will notice this and keep track of those too.

A new debug window "History" provides access to all recorded values. Currently this is up to 25 history entries. And you can even browse the history after you program terminated.
If you have a history entry selected, you can use the stack-window to change the current stack. If any data was collected for the selected frame, it will be shown. Currently data for extra stack frames is only collected if the frame was selected, while your app was running, and if the watches or locals window where open and active.

There is however a little twist to it. Collecting all the data takes some time. To avoid any slowdown of the debugger, this new feature works on idle time only. It collects data, only if the debugger has no other work. This even means that you can continue the execution of your application, without having to wait the full time it would have taken to get all the data. In this case the snapshot will be incomplete.
If you want to ensure complete snapshots, you can open the watches, locals and stack window, and observe when the information has been fully fetched, as it gets displayed to you.

This feature is available in Lazarus 0.9.31