Continuing the theme about "True Native Crossplatform Delphi Library"

Continuing the theme about "True Native Crossplatform Delphi Library"

During the development of my framework. I ran into serious limitations in Delphi - Android bridge. Namely, in limiting the number of simultaneously used classes (~30-40).

What does it mean for developers?

It means, that you cannot use in your android application more that ~30-40 classes in the same time. Once you exceed this limit, your app will fall in different places on the Delphi side.
However it doesn't limits on instance count, which are allocated from one class. In other words, you can create alot of object java instances of one class, but you cannot create by one object of a lot of java classes. Since FMX is not very integrated with the native API, this issue while it is not critical. Because you are "in a bounce of limit". However, if you want to limit yourself to just Delphi with a functionality, and still use the android api directly, it can become a very serious problem in future.

As you know, for a native library, this limit is quite a serious problem. Because native Libs is tight integration with the native API and is used by a large variety of classes. This problem I faced when I started to extend the set of native components in my library. And as soon as I have exceeded the limit on the number of classes to be used, the application began to fall with crash.

After researching the problem, I realized that the problem is only on the side of the implementation of the top of the bridge in Delphi. So I switched to connecting the project to implement alternative Java bridge. The development took me one month and was a success. After the transfer the "True Native Delphi Crossplatform Library" on the new bridge, the problems went away.

All the details of the new bridge, I'll tell you later. I just want to mention that from the point of view of the developer, it can use Android API in the same way as conventional Delphi objects. Now you do not need to write:

TJView.JavaClass.Init(Context)
and can write simply in delphi style:
TJView.Create(Context)

Of the other possibilities, it will support Delphi strings as arguments to the Java API. And you will not need to perform endless conversion
StringToJString and Vice versa.

My bridge includes 2 parts:
1. Base for binding delphi wrappers and java classes
2. Special command line tools generator wich can create for you interesting delphi wrappers

I will tell you about it more detail later. Below screenshot of generated delphi wrapper for java.lang.Boolean object.