Archived Forum Post

Index of archived forum posts

Question:

support for delphi firemonkey

May 13 '15 at 11:04

Hello, chilkat together with delphi vcl-applications works great. When I change to delphi firemonkey devellopment (android, ios, mac-os) can I still use chilkat? Kind regards U. Blomeyer


Answer

Chilkat does not have anything pre-packaged for FireMonkey. Customers in the past have used Chilkat in C++ Builder with FireMonkey. I'll share that information below. But first I'll describe at a higher-level needs to be considered:

  1. It must be the case that when a FireMonkey app builds on iOS or Android, it links against the C/C++ standard/system libraries that exist on those platforms. There is nothing about those C/C++ libraries that make them "FireMonkey aware" -- meaning they are the standard libs that are used by FireMonkey, as well as apps in different languages (such as building a Perl module, or a Java JNI shared lib). Chilkat provides C/C++ libs for both Android and iOS, and therefore it should be possible to include these libs as additional "system libs" when linking.
  2. The Chilkat Delphi DLL download includes the generated Delphi wrappers to define the Chilkat functions and indicate they are implemented in an external shared library/DLL. On Android, it's possible to use shared libs in an application. On iOS it is not possible to use shared libs -- your program must link everything into a single exe. Without further research, I don't understand how or if it's possible to write a Delphi .pas wrapper such that the implementation is linked-in C++ code (as opposed to an external DLL/shared lib). On Android, it should be possible to build the equivalent .so as what is provided in the Delphi DLL on Windows. The FireMonkey app on Android would use a "Chilkat Delphi .so for Android" (which does not yet exist).
  3. However, why bother with the "Chilkat Delphi .so for Android" if it's somehow possible to link Delphi code directly with C/C++ code (i.e. use the static libs). This seems to be the only possible way one could use C/C++ libs in iOS -- and given that the system C/C++ iOS lib are linked against, one would think it's somehow possible to add additional libs (i.e. Chilkat static libs) and call them from Delphi..

In C++ Builder, these Delphi --> C++ issues don't exist, and therefore it's easier, as this note describes:

Using Chilkat in C++ Builder for FireMonkey

Here is a customer note with success in getting this to work:

Well I have some good news you might like to hear. I was able to successfully call your Chilkat API’s in a hybrid Win32/Android app from C++ with the same code. (I just have to add some conditional compilations to do things like storing things in different places in the file system depending on whether the app’s running on Windows or Android.)

So what I did was take your Chilkat .a libraries, all four platform directories from the root of that folder, and added them to the FireMonkey Mobile App that I had made, and then also took your C++ Builder .lib libraries, and added them to the project as well. I added your C++ Builder library include and .lib files to the include and library paths (though for some reason I always seem to have to manually add the .lib—and .a—files to the project—are you aware of a way around this perhaps, by the way?) for C++ 32 bit build settings. (Similar process for 64-bit of course.)

Then I went into the Android build settings, and made sure I had your C/C++ Android library C/C++ header files in the Android build’s include path, and the four platform .a library files in the library path.

And voila! The same C++ code, getting deployed to both Android and Win32. I might like to add MacOS and iOS as deployment platforms later, and I noticed you have some perhaps relevant library files for those as well.

Curious, I just read up on the Android NDK. Did you perhaps use the Android NDK to code and produce your core library functions as native Android library files using the Android API, and then JNI to make C/C++ header and wrapper functions? I’ve done some things with JNI in the past. (I’ve also used MS C++ Interop to wrap C++ unmanaged code with C# managed assemblies.. I remember that being a bit more hairy than JNI, especially when figuring out how to marshall some parameter types back and forth.) I’m thinking of, with JNI’s bi-directional capabilities, the possibility of wrapping up some other third party components we have that only come with Win32 and Win64 .lib and .a files, but in the other direction perhaps, so as to be able to access the C/C++ libraries from (in the case of FireMonkey apps) wrapped up back into C++ FireMonkey type wrappers, which would be a wrapper for the Java wrappers of the C++ libraries. LOL, that can get a little convoluted.

Anyway, thanks for your tips. Glad I could help you out with a tip too.. now you can re-brand your libraries for use with FireMonkey applications, no?