Registrado: may 2003
Ubicación: Bogotá, Colombia
True Native Crossplatform Delphi Library (spoiler)
Les comparto un "comunicado" publicado en el grupo Delphi Developers
de google, para los que no están aun suscritos.
el comunicado fue escrito por Yaroslav Brovin
y lo copio aqui tal cual para los que les da pereza ir a los links...
True Native Crossplatform Delphi Library (spoiler)
I'm glad to announce 3 news in Delphi world: 2 positive and one negative.
I had been working on development FireMonkey library for 5 years in Embarcadero. It was a usefull time for deep understanding how library should work. And after closing offices i have been started to work on creating new crossplatform really native library from scratch. It never uses firemonkey anymore. Library something similar to VCL, but uses modern approach in development. It uses only small part of rtl. Framework uses native components and native graphics of each os. There are few advantages, which will be available in final version:
1. Look and Feel. All components are native. It means they are using native implementation system components aka VCL. Now you don't need to worry, that your application works on android not so like a application, which was created in XCode or Android Studio.
2. UI response. All components of new library workds so fast, as a system application.
3. Good quality of drawing. Only native OS graphics, which provide a lot of possibility for drawing (gradient, text, primitive, effects) and guarantees that you drawing will be the same on different devices.
4. Design taking into account the specifics of mobile platforms. Mobile platforms differs from desktop platforms and provides new controls, which are special only for mobile design. It's a fact. Framework includes it (Status bars, mobile services, no desktop features and so on).
5. Supporting non visual components DB access components, REST and etc. which allow to create your buisness application
6. Simplification of Stylization. As you know styles in Fmx is a greate features with alot of possibilities. You can put TEdit into style of TPanel (but why?). For each of this posibility framework pays by performance and flexibility for creating you style. You cannot understand which controls you should use for create for ex style for TEdit. But in common you need just change only graphics (like a skins). Libary will support also styling, but it will not provide put any controls to each other for reducing complexity of style using and increasing performance.
7. Extensibility. In this time libraries have already have base for creating components. which are using os native controls or components, which are self drew themself.
8. Modularity. Framwork designed to reflect a decrease in the connectivity of the components and modules between them. You can be sure, that if you are create empty one form application it will not load web browsers, buttons and other controls like a FMX. It one of the way for reducing application size. On this moment application which is created by my framework takes in 3 time less memory space, then the same fmx application.
I will provide more information about details in development process. There is still a lot of work, but not a small part of the work is already done and left behind.
There are just a screenshot from my demo application of really native application with my library. It doesn't use any FMX.
P.S. The topic is very interesting, and will likely cause a lot of questions. I will try to answer whenever possible.
P.S.P.S. Soon there will be a resource where you can learn more about the project, and meet with a Road map and to learn about the progress of project development.
Its' a good news. Bad will be in a next post (It relates with Delphi - Android bridge)
éste es el segundo post, sobre las malas noticias (limitaciones):
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:
and can write simply in delphi style:
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.