For those who expect native Android / iOS apps in Delphi here a good article to read by TGrubb
[SHOWTOGROUPS=4,20]
Delphi for iOS and Android: The Natives are restless
One of the major marketing points from Embarcadero is that Delphi will create applications that are “native” to your mobile platform. One of the major complaints that I see from people trying Delphi for mobile platforms is the disappointment about the speed and appearance of these “native” applications. This is a classic case of a company overselling their product, inflating the expectations of their customers, and then disappointing them.
So is Delphi creating “native” applications for iOS and Android? The answer is yes, yes-ish, and not at all. What you need to realize is that there are many ways that an application can be native (or not) to a platform. I am going to talk about 3 ways to help you understand what Delphi is good and not-so-good for. There is native to the hardware, native to the OS, and native look and feel.
Native to the hardware
Native to the hardware means that your code is compiled down to actual machine instructions of the hardware. This is the area that Embarcadero has done a great job and is really what their marketing department is selling you. Unlike Java or Python or php, Delphi’s code is not interpreted by some engine or virtual machine. After the compiling and linking are finished, that code that adds 2 numbers goes directly to the hardware without any layer in-between. This is true for Windows, for MacOS, for iOS, and for Android.
Note that this doesn’t mean that you cannot write fast interpreted code or slow compiled code. The algorithms you write and the optimizations that the interpreter/compiler does and does not perform can greatly affect execution speed. It does mean that Delphi has an in-built advantage over interpreted code here though.
Note 2: Native to the Hardware could also mean direct access to the hardware (such as GPS, camera, etc) of the device, but unless you are writing device drivers, noone does direct access to that kind of hardware. It is more properly a function of the OS APIs which is discussed in the following section.
Native to the OS
What I mean by native to the OS is does a program have direct access to the API and controls of the Operating System of the device? For Delphi and iOS, this is an *equivocal* yes. For Delphi and Android, this is a *good enough*. Almost by definition, unless your development language is the same language used by the OS, you will always have to use a hopefully thin application programming interface to the OS and its controls (this is one area where C++Builder can do better than Delphi on iOS). Since iOS’ “native” language is objective-C and (even worse from Delphi’s standpoint), Android’s “native” language is Java, Delphi is not “native” to the OS. However, that does not mean it is a second class citizen for development.
You see, Delphi, at least the Delphi that everyone thinks about, has never had direct access to the API and controls of the Operating System. One of the things that made Delphi great is its true Rapid Application Development of applications using its VCL. The VCL is not direct access to the Window’s API. At best from the standpoint of direct access, you had to use C headers to access Window’s services and at worst, the VCL was a thin wrapper around Window’s controls. The TListBox is not native to Windows – it is a beautifully logical wrapper around a Window’s object. Delphi sacrificed native access to the API and controls to give you Rapid Application Development (RAD). The goal, however, has been to keep the layer’s between Delphi and the OS as thin and fast as possible, while keeping RAD and now adding cross-platform development.
So Native to the OS is a qualified yes. For Windows, OSX, and iOS (as they are all based on C/C++), access to OS services through APIs is fast and clean. For Android, the access is not so good as Delphi needs to use a JNI (Java Native Interface) layer, which is expensive relative to C APIs.
Delphi’s cross-platform library, Firemonkey or FMX, wrap services like Location and the Camera in what I believe is a very good way for cross-platform development. These classes help hide the complexity of the underlying service and abstracts it for all platforms that Delphi supports. They are thin but good layers to the underlying OS services.
However, access to the native OS controls is another story and is the subject of my next section.
Native Look and Feel
Native Look and Feel is the area where everyone is getting disappointed. Delphi mobile apps can look slightly wrong, feel slightly sluggish, and act in a non-standard way (relative to OS controls). This is the consequence of the path Embarcadero chose to implement cross-platform controls like TListBox, TMemo, etc.
The VCL, unlike FMX, is a thin wrapper around native Window’s controls and so shares Windows look and feel and smooth responsiveness (insert Mac fanboy disparaging comments here ;-)). When you click and drag your mouse on Windows, you are clicking and dragging on Window’s controls. When the application runs on a new Windows OS, it inherits (mostly) the new look and feel. The VCL communicates through Windows messages with the underlying OS controls and everything just works.
FMX emulates all controls of the underlying OS. It draws every pixel itself and handles every user interaction. This is the cause of the slightly wrong look and feel. This is why a Delphi TListBox will have different bugs than Android’s list box. This is why it will refresh slower and respond slower than the iOS list box. This is also why, when a new OS is published, Delphi apps do not update their look and feel and can look out of date.
So, despite Embarcadero’s claims of pixel-perfect compatibility, Delphi does not have NATIVE look and feel. FMX still provides the RAPID in RAD, just not native look and feel.
I wrote that this is a consequence of Embarcadero’s decision, and it is. And I really cannot blame them for the decision. With the VCL, Embarcadero/Borland chose the thin wrapper over the OS approach. It works beautifully, but it ties the component library to the OS. Embarcadero could have chosen this approach for FMX but it is really, really hard and we would still be waiting for cross-platform compatibility. They would have had to develop a cross-platform abstraction for every control in FMX (a herculean task by itself and maybe not possible). Then, for every platform they support, they would have to develop and maintain an FMX version. Embarcadero chose to “get in the game” as fast as possible. I believe it was the right decision, but it does mean that they have to deal with the consequences of their choice.
Note: the bugginess and responsiveness will improve (and God do I know that there are bugs!). Every version Embarcadero has been improving the FMX library. While it will never have native look and feel, improved look and feel will occur.
Note 2: you can have native look and feel on Windows and iOS. Choose the VCL for Windows, and choose something like D.P.F Delphi iOS Native Components (Для просмотра ссылки Войдиили Зарегистрируйся) or TMS’s iCL (Для просмотра ссылки Войди или Зарегистрируйся), which do the same thing for iOS. Of course, you sacrifice the cross-platform development… though you get to keep using your Delphi skillset and with proper modularization can hopefully keep the incompatibilities to a minimum.
Delphi’s Strengths and Weaknesses
So what does all this mean for developers? It means that Delphi has its strengths and weaknesses, and as long as you are aware of them, you can choose Delphi for the right jobs.
If you need cross-platform compatibility and want to deal with only one code base (mostly), Delphi is an excellent choice. It provides nice abstractions of the OS and its services, a relatively pretty GUI library, and native (very fast) access to the CPU. Delphi also has excellent DB connectivity, web services connectivity, and networking in general. This means Delphi is a good choice for
Happy CodeSmithing!
This entry was posted in Для просмотра ссылки Войдиили Зарегистрируйся on Для просмотра ссылки Войди или Зарегистрируйся.
Michael JustinДля просмотра ссылки Войдиили Зарегистрируйся
Source: Для просмотра ссылки Войдиили Зарегистрируйся
[/SHOWTOGROUPS]
Delphi for iOS and Android: The Natives are restless
One of the major marketing points from Embarcadero is that Delphi will create applications that are “native” to your mobile platform. One of the major complaints that I see from people trying Delphi for mobile platforms is the disappointment about the speed and appearance of these “native” applications. This is a classic case of a company overselling their product, inflating the expectations of their customers, and then disappointing them.
So is Delphi creating “native” applications for iOS and Android? The answer is yes, yes-ish, and not at all. What you need to realize is that there are many ways that an application can be native (or not) to a platform. I am going to talk about 3 ways to help you understand what Delphi is good and not-so-good for. There is native to the hardware, native to the OS, and native look and feel.
Native to the hardware
Native to the hardware means that your code is compiled down to actual machine instructions of the hardware. This is the area that Embarcadero has done a great job and is really what their marketing department is selling you. Unlike Java or Python or php, Delphi’s code is not interpreted by some engine or virtual machine. After the compiling and linking are finished, that code that adds 2 numbers goes directly to the hardware without any layer in-between. This is true for Windows, for MacOS, for iOS, and for Android.
Note that this doesn’t mean that you cannot write fast interpreted code or slow compiled code. The algorithms you write and the optimizations that the interpreter/compiler does and does not perform can greatly affect execution speed. It does mean that Delphi has an in-built advantage over interpreted code here though.
Note 2: Native to the Hardware could also mean direct access to the hardware (such as GPS, camera, etc) of the device, but unless you are writing device drivers, noone does direct access to that kind of hardware. It is more properly a function of the OS APIs which is discussed in the following section.
Native to the OS
What I mean by native to the OS is does a program have direct access to the API and controls of the Operating System of the device? For Delphi and iOS, this is an *equivocal* yes. For Delphi and Android, this is a *good enough*. Almost by definition, unless your development language is the same language used by the OS, you will always have to use a hopefully thin application programming interface to the OS and its controls (this is one area where C++Builder can do better than Delphi on iOS). Since iOS’ “native” language is objective-C and (even worse from Delphi’s standpoint), Android’s “native” language is Java, Delphi is not “native” to the OS. However, that does not mean it is a second class citizen for development.
You see, Delphi, at least the Delphi that everyone thinks about, has never had direct access to the API and controls of the Operating System. One of the things that made Delphi great is its true Rapid Application Development of applications using its VCL. The VCL is not direct access to the Window’s API. At best from the standpoint of direct access, you had to use C headers to access Window’s services and at worst, the VCL was a thin wrapper around Window’s controls. The TListBox is not native to Windows – it is a beautifully logical wrapper around a Window’s object. Delphi sacrificed native access to the API and controls to give you Rapid Application Development (RAD). The goal, however, has been to keep the layer’s between Delphi and the OS as thin and fast as possible, while keeping RAD and now adding cross-platform development.
So Native to the OS is a qualified yes. For Windows, OSX, and iOS (as they are all based on C/C++), access to OS services through APIs is fast and clean. For Android, the access is not so good as Delphi needs to use a JNI (Java Native Interface) layer, which is expensive relative to C APIs.
Delphi’s cross-platform library, Firemonkey or FMX, wrap services like Location and the Camera in what I believe is a very good way for cross-platform development. These classes help hide the complexity of the underlying service and abstracts it for all platforms that Delphi supports. They are thin but good layers to the underlying OS services.
However, access to the native OS controls is another story and is the subject of my next section.
Native Look and Feel
Native Look and Feel is the area where everyone is getting disappointed. Delphi mobile apps can look slightly wrong, feel slightly sluggish, and act in a non-standard way (relative to OS controls). This is the consequence of the path Embarcadero chose to implement cross-platform controls like TListBox, TMemo, etc.
The VCL, unlike FMX, is a thin wrapper around native Window’s controls and so shares Windows look and feel and smooth responsiveness (insert Mac fanboy disparaging comments here ;-)). When you click and drag your mouse on Windows, you are clicking and dragging on Window’s controls. When the application runs on a new Windows OS, it inherits (mostly) the new look and feel. The VCL communicates through Windows messages with the underlying OS controls and everything just works.
FMX emulates all controls of the underlying OS. It draws every pixel itself and handles every user interaction. This is the cause of the slightly wrong look and feel. This is why a Delphi TListBox will have different bugs than Android’s list box. This is why it will refresh slower and respond slower than the iOS list box. This is also why, when a new OS is published, Delphi apps do not update their look and feel and can look out of date.
So, despite Embarcadero’s claims of pixel-perfect compatibility, Delphi does not have NATIVE look and feel. FMX still provides the RAPID in RAD, just not native look and feel.
I wrote that this is a consequence of Embarcadero’s decision, and it is. And I really cannot blame them for the decision. With the VCL, Embarcadero/Borland chose the thin wrapper over the OS approach. It works beautifully, but it ties the component library to the OS. Embarcadero could have chosen this approach for FMX but it is really, really hard and we would still be waiting for cross-platform compatibility. They would have had to develop a cross-platform abstraction for every control in FMX (a herculean task by itself and maybe not possible). Then, for every platform they support, they would have to develop and maintain an FMX version. Embarcadero chose to “get in the game” as fast as possible. I believe it was the right decision, but it does mean that they have to deal with the consequences of their choice.
Note: the bugginess and responsiveness will improve (and God do I know that there are bugs!). Every version Embarcadero has been improving the FMX library. While it will never have native look and feel, improved look and feel will occur.
Note 2: you can have native look and feel on Windows and iOS. Choose the VCL for Windows, and choose something like D.P.F Delphi iOS Native Components (Для просмотра ссылки Войди
Delphi’s Strengths and Weaknesses
So what does all this mean for developers? It means that Delphi has its strengths and weaknesses, and as long as you are aware of them, you can choose Delphi for the right jobs.
If you need cross-platform compatibility and want to deal with only one code base (mostly), Delphi is an excellent choice. It provides nice abstractions of the OS and its services, a relatively pretty GUI library, and native (very fast) access to the CPU. Delphi also has excellent DB connectivity, web services connectivity, and networking in general. This means Delphi is a good choice for
- Enterprise developers, who want to provide mobile access and don’t really care about pixel-perfect look and feel
- Scientific and number crunching developers, who need fast processing and a way to nicely display their results
- Game developers, surprisingly enough, who want to develop cross-platform games which don’t have “native” interfaces anyway and where FMX can provide fast-enough graphics. (In other words, not Madden level graphics but Angry Birds).
- “Light” Apps which don’t use a bazillion controls to interact with the user and don’t need “pixel-perfect” responsiveness
- Compelling apps where the user will forgive some idiosyncrasies because the app is so good. I mention this because Delphi allows you to concentrate on the app. Delphi provides the RAD and the cross-platform compatibility, you can concentrate on making the killer app.
Happy CodeSmithing!
This entry was posted in Для просмотра ссылки Войди
Michael JustinДля просмотра ссылки Войди
- Java code is not interpreted. Java uses a two step compilation process. In the end it is machine code, this is true both for the main JREs and for the Dalvik virtual machine since version 2.2 (a.k.a. “Froyo”) – see Для просмотра ссылки Войди
или Зарегистрируйся – So there is not such a big difference between Delphi and Java on Android regarding generated code. It is just that Delphi code is compiled to platform (CPU-) specific machine code on the developer machine, while Android does on the target device this as the last step before execution. This makes Dalvik virtual machine code portable (processor independent), while still using native machine code on all processor architectures where Dalvik can run.
Source: Для просмотра ссылки Войди
[/SHOWTOGROUPS]
Последнее редактирование:
