Mobile application development in Embarcadero FireMonkey (FMX 6)
No one likes to write the same code several times, but this is exactly what has to be done if the mobile application has to be implemented for several platforms at once. It is a shame that the programmers of the company, in each case, need to use different tools, skills and approaches. Of course, there is a desire that, when transferring an application, at least, it was not necessary to change the programming language.
So this time, reflecting on the complexities of developing applications for mobile, we could not resist the temptation to try on the ancient Russian dream, and, like the hero of the fairy tale “By the will of the horse”, ride the stove. Looking ahead, we say that the "oven" went, albeit with some squeak.
So, as you know, there are several approaches used in the cross-platform development of mobile applications. Each of these solutions has its drawbacks, and, perhaps, we will present a comparative analysis of various approaches in one of the following publications. Here we will discuss only one such instrument, which, as it seems to us, is somewhat overlooked by the audience, although it has several unique features.
FireMonkey is a product of the notorious Embarcadero company. FireMonkey is part of the RAD Studio development environment. The underlying FMX engine was once developed by our compatriot and is a Flash Platform-like cross-platform framework for building user interfaces. At the same time, like the mentioned products, FMX uses vector graphics and hardware acceleration. The product appeared only a few years ago, but during this time 5 updates have already been released. I want to believe that the product will not suffer the fate of the infamous Delphi .NET.
')
Applications are compiled directly into machine code, and this is one of the main distinguishing features of the solution in question. Due to these remarkable circumstances, Embarcadero, in theory, promises us overall performance at the level of native applications. Being built into Delphi and C ++ Builder, FireMonkey allows you to implement the logic of applications in Pascal and C ++. The same FireMonkey (FM) application code can be compiled to work on Windows, iOS, and Android. We were attracted by the opportunity to develop in C ++, since the company had a large number of programmers in this area. Therefore, to test the functionality, the C ++ Builder version of RAD Studio XE6 was installed, although the Delphi edition should not differ by anything other than the programming language used.
Having behind his back a turbulent past associated with the creation of compilers, the manufacturer equipped FireMonkey with native C ++ compilers for x86 and ARMv7. This allows you to compile directly on the computer running the development environment. It is the presence of our own compilers that gives us the opportunity to program in C ++ or even Pascal, obtaining the necessary machine code ARM at the output. However, the original application toolkit from the development tools (SDK) of mobile platforms is still used to build the application (link), sign it, launch it on devices, and debug it. Thus, before starting work, you still need to do the following:
Since both RAD Studio and Android toolkit work on PCs, Android development requires slightly less body movements than iOS. To build iOS applications, you need a Mac OS (since only for it does Apple release an SDK). Thus, if an application is being developed on a PC, they must somehow communicate. From the diagram below, you can see how using the supplied Embarcadero PAServer (Platform Assistant Server) you can build iOS applications via a PC:
As part of the FireMonkey sample, we developed a simple application (at the Hello world level), by the example of which we wanted to test the functionality of the proposed technology.
Below is a screenshot of the version of this application for Windows and a short video so you can see its simple work in dynamics:
Our application contains almost no code. Nevertheless, we will tell you exactly what we did.
In this case, we were interested in the mutation of the user interface on different platforms, as well as performance, but in its "everyday" understanding of it. That is, the user doesn’t care about the number of floating-point operations per second, but how softly and quickly the application responds to its actions.
The application consists of several standard controls and contains a pair of user action handlers. At the top of the screen is a "twist", moving which you can rotate the image on the left. This part of the test was needed to test the ability of FMX to draw two-dimensional graphics, or rather, to perform raster operations.
The progress indicator located just below displays the current value of the angle on which the wheel is set. It is needed to test the interactions in the UI stream and, also, to look at the style of this element on different platforms.
Handler wheel rotation:
As you can see, this is the usual C ++, but a bit "soiled" by the legacy of Delphi.
Below is the traditional button (which, however, is not so similar to the button) with the following HW handler:
To the right you can see the date selection field (DateTimePicker). We were interested, first of all, in its appearance on mobile operating systems: whether the native control will be used in each case or something drawn. For the same reason, below is a slider and ON / OFF switch. This switch, however, gained another function: it includes one of the standard FMX visual effects (radial blur): we wanted to see whether the FMX draws the controls itself or delegates this work to the mobile OS. Below we will return to this issue, since the result was not obvious .
At the bottom is a table with two columns. The table has distinct features of a desktop application, albeit with inertial scrolling. We wanted to see what it would use on a mobile phone. The table is filled at the start of the application, just so that the eye has something to cling to:
The compilation is very slow - as usual C ++ Builder does it somehow strained. However, for many years, the C ++ compiler has not made them nearly faster.
It's time to see the same application in the version for mobile devices. You do not need to change the code or user interface of your application. It is enough to change some of the settings in the project, which, as it were, were created so that the “easy movement” could change the target platform.
Platform switching is carried out effortlessly - in IDE, this aspect of the interface is made deliberately and uncompromisingly. You must choose: Debug or Release compilation, target platform, simulator or device, and separately mark whether the build is for internal use or for publication. In the latter case, you will be required to sign certificates. Certificates Android, if you do not have them yet, you will immediately be kindly offered to generate directly from the development environment; Well, iOS profiles should be on the Mac where the final build step will be performed.
It is easy to see that the Android section lists all simulators configured in the Android SDK, as well as all connected devices.
In the iOS section, the options exactly repeat the set of XCode - this is not surprising, given that the build and launch of the simulator will be performed on a remote Mac OS machine.
The left shows how the applications look on the main mobile platforms.
As it is easy to notice - and it is gratifying - the appearance has hardly changed, or rather, on the contrary: the application has changed in an incomprehensible way, but now it looks exactly the same as if we made its interface from scratch for each of the platforms. This is the temptation for which we wanted to test FMX. Sounds like the excitement of first using Qt!
It can be seen that this is still the same application, but all the controls have changed to “native” for each of the platforms. This, in our opinion, could be called a truly cross-platform GUI application development.
Mobile application is ready! We invite you to look at his work live on the example of a screen video made on a physical Android device (HTC One). The videos are almost identical, we made two videos for statistics.
Some aspects of the work of our application are noticeable on the video.
Let's see what is inside our freshly assembled Android application.
APK archive has a very significant size of 6 MB. Apparently, according to the old Delphi tradition, the entire runtime library was dragged into it.
Inside the APK archive, we see the following folder structure (shown on the right). The presence of dynamic libraries (so) is striking, as if hinting to us what exactly the native ARMv7 compiler and NDK were used for.
Note that the lib folder contains subfolders with the name of the architecture, and each of them contains our application, which is named for some reason libProject1.so. So, only in the folder armeabi-v7a it is real, and has a size of about 21 MB (in unpacked form). The rest of the library files are ready-made flapper plugs that fire a message in the face of the user if his architecture is different from ARMv7. In this, the manufacturer honestly admits and leaves us nothing else so far.
The classes.dex file contains not our application at all, but the Java loader for the main FMX library application and the implementation of wrappers for Android native controls. It is this fragment that allows the application to interact with the OS and “pretend” to the usual Android application.
As it becomes noticeable on the video, the FMX effects continue to work perfectly on Android’s “native” controls, interfering in their rendering (for example, we even turned on the lighting of the contours of the controls, which means that the FMX works with Android controls not just as with pictures, but very tightly).
Sebastian Gingter (SEBASTIAN PR GINGTER) in his well-known article on FMX speaks about the framework very unflatteringly, criticizing the fact that the user interface is drawn independently and does not look native to any of the platforms. Apparently, at some point, this was exactly the case, but now such criticism cannot be considered fair. The author denies the very idea of ​​cross-platform GUI applications, without looking at specific implementations, denying the potential advantages of such an approach.
The considered tool, of course, is the successor of all VCL traditions: glorious and inglorious. We were convinced that the assembly technology of truly cross-platform mobile applications works and shows very good performance. For a certain class of applications, FMX will be a good help.
Negative aspects include a noticeable time delay at the start and not a small size of the resulting application.
So this time, reflecting on the complexities of developing applications for mobile, we could not resist the temptation to try on the ancient Russian dream, and, like the hero of the fairy tale “By the will of the horse”, ride the stove. Looking ahead, we say that the "oven" went, albeit with some squeak.
So, as you know, there are several approaches used in the cross-platform development of mobile applications. Each of these solutions has its drawbacks, and, perhaps, we will present a comparative analysis of various approaches in one of the following publications. Here we will discuss only one such instrument, which, as it seems to us, is somewhat overlooked by the audience, although it has several unique features.
FireMonkey is a product of the notorious Embarcadero company. FireMonkey is part of the RAD Studio development environment. The underlying FMX engine was once developed by our compatriot and is a Flash Platform-like cross-platform framework for building user interfaces. At the same time, like the mentioned products, FMX uses vector graphics and hardware acceleration. The product appeared only a few years ago, but during this time 5 updates have already been released. I want to believe that the product will not suffer the fate of the infamous Delphi .NET.
')
Applications are compiled directly into machine code, and this is one of the main distinguishing features of the solution in question. Due to these remarkable circumstances, Embarcadero, in theory, promises us overall performance at the level of native applications. Being built into Delphi and C ++ Builder, FireMonkey allows you to implement the logic of applications in Pascal and C ++. The same FireMonkey (FM) application code can be compiled to work on Windows, iOS, and Android. We were attracted by the opportunity to develop in C ++, since the company had a large number of programmers in this area. Therefore, to test the functionality, the C ++ Builder version of RAD Studio XE6 was installed, although the Delphi edition should not differ by anything other than the programming language used.
Build applications
Having behind his back a turbulent past associated with the creation of compilers, the manufacturer equipped FireMonkey with native C ++ compilers for x86 and ARMv7. This allows you to compile directly on the computer running the development environment. It is the presence of our own compilers that gives us the opportunity to program in C ++ or even Pascal, obtaining the necessary machine code ARM at the output. However, the original application toolkit from the development tools (SDK) of mobile platforms is still used to build the application (link), sign it, launch it on devices, and debug it. Thus, before starting work, you still need to do the following:
| iOS | Android |
|---|---|
| Have a Mac | --- |
| Sign up for iOS Developer Program | Register on Android Developer site |
| Get certificates (developer, provisioning) | Generate a key for signing applications |
| Download and install iOS SDK | Download and install the Android SDK and NDK |
| Download and install PAServer on Mac | --- |
| Configure the connection between RAD Studio and PAServer | --- |
Since both RAD Studio and Android toolkit work on PCs, Android development requires slightly less body movements than iOS. To build iOS applications, you need a Mac OS (since only for it does Apple release an SDK). Thus, if an application is being developed on a PC, they must somehow communicate. From the diagram below, you can see how using the supplied Embarcadero PAServer (Platform Assistant Server) you can build iOS applications via a PC:
Example
As part of the FireMonkey sample, we developed a simple application (at the Hello world level), by the example of which we wanted to test the functionality of the proposed technology.
Below is a screenshot of the version of this application for Windows and a short video so you can see its simple work in dynamics:
Our application contains almost no code. Nevertheless, we will tell you exactly what we did.
In this case, we were interested in the mutation of the user interface on different platforms, as well as performance, but in its "everyday" understanding of it. That is, the user doesn’t care about the number of floating-point operations per second, but how softly and quickly the application responds to its actions.
The application consists of several standard controls and contains a pair of user action handlers. At the top of the screen is a "twist", moving which you can rotate the image on the left. This part of the test was needed to test the ability of FMX to draw two-dimensional graphics, or rather, to perform raster operations.
The progress indicator located just below displays the current value of the angle on which the wheel is set. It is needed to test the interactions in the UI stream and, also, to look at the style of this element on different platforms.
Handler wheel rotation:
//--------------------------------------------------------------------------- void __fastcall TForm1::DialAngleChange(TObject *Sender) { // Every time the angle dialer is spinned, assign // its current value to the Image control... imgLogo->RotationAngle = 360 - DialAngle->Value; // The progress bar will get updated with a normalized angle value pbAngle->Value = (int)fabs(DialAngle->Value)%360; } //--------------------------------------------------------------------------- As you can see, this is the usual C ++, but a bit "soiled" by the legacy of Delphi.
Below is the traditional button (which, however, is not so similar to the button) with the following HW handler:
//--------------------------------------------------------------------------- void __fastcall TForm1::btnHelloClick(TObject *Sender) { // A simple HW assignment btnHello->Text = "Hello world!"; } //--------------------------------------------------------------------------- To the right you can see the date selection field (DateTimePicker). We were interested, first of all, in its appearance on mobile operating systems: whether the native control will be used in each case or something drawn. For the same reason, below is a slider and ON / OFF switch. This switch, however, gained another function: it includes one of the standard FMX visual effects (radial blur): we wanted to see whether the FMX draws the controls itself or delegates this work to the mobile OS. Below we will return to this issue, since the result was not obvious .
At the bottom is a table with two columns. The table has distinct features of a desktop application, albeit with inertial scrolling. We wanted to see what it would use on a mobile phone. The table is filled at the start of the application, just so that the eye has something to cling to:
//--------------------------------------------------------------------------- __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { // Initialize the string grid with a bit of texts // Define the number of items gdDemo->RowCount = 1000; // Generate the texts for every Row and Column for(int r = 0; r < gdDemo->RowCount; r++) { gdDemo->Cells[0][r] = "iResearchFX"; gdDemo->Cells[1][r] = IntToStr(r+1); } } //--------------------------------------------------------------------------- Compilation
The compilation is very slow - as usual C ++ Builder does it somehow strained. However, for many years, the C ++ compiler has not made them nearly faster.
It's time to see the same application in the version for mobile devices. You do not need to change the code or user interface of your application. It is enough to change some of the settings in the project, which, as it were, were created so that the “easy movement” could change the target platform.
Platform switching is carried out effortlessly - in IDE, this aspect of the interface is made deliberately and uncompromisingly. You must choose: Debug or Release compilation, target platform, simulator or device, and separately mark whether the build is for internal use or for publication. In the latter case, you will be required to sign certificates. Certificates Android, if you do not have them yet, you will immediately be kindly offered to generate directly from the development environment; Well, iOS profiles should be on the Mac where the final build step will be performed.
It is easy to see that the Android section lists all simulators configured in the Android SDK, as well as all connected devices.
In the iOS section, the options exactly repeat the set of XCode - this is not surprising, given that the build and launch of the simulator will be performed on a remote Mac OS machine.
The left shows how the applications look on the main mobile platforms.
As it is easy to notice - and it is gratifying - the appearance has hardly changed, or rather, on the contrary: the application has changed in an incomprehensible way, but now it looks exactly the same as if we made its interface from scratch for each of the platforms. This is the temptation for which we wanted to test FMX. Sounds like the excitement of first using Qt!
It can be seen that this is still the same application, but all the controls have changed to “native” for each of the platforms. This, in our opinion, could be called a truly cross-platform GUI application development.
Mobile application is ready! We invite you to look at his work live on the example of a screen video made on a physical Android device (HTC One). The videos are almost identical, we made two videos for statistics.
Some aspects of the work of our application are noticeable on the video.
- Start time. It is believed that all applications on Android-e do not start very quickly if we are talking about a "cold" start. It also clearly shows that we lose about 2 seconds at the start (black screen at the very beginning of the video). Whether it is a lot or not is up to you, but, in our opinion, it strongly depends on the type of application.
- Work speed There are no special complaints - the interface works quite well.
- Controls. All elements are replaced by native ones and make quite the Androydov impression.
- Grid. It looks interesting for a mobile platform and, quite, working - there is even inplace editing of cells.
Post mortem
Let's see what is inside our freshly assembled Android application.
APK archive has a very significant size of 6 MB. Apparently, according to the old Delphi tradition, the entire runtime library was dragged into it.
Inside the APK archive, we see the following folder structure (shown on the right). The presence of dynamic libraries (so) is striking, as if hinting to us what exactly the native ARMv7 compiler and NDK were used for.
Note that the lib folder contains subfolders with the name of the architecture, and each of them contains our application, which is named for some reason libProject1.so. So, only in the folder armeabi-v7a it is real, and has a size of about 21 MB (in unpacked form). The rest of the library files are ready-made flapper plugs that fire a message in the face of the user if his architecture is different from ARMv7. In this, the manufacturer honestly admits and leaves us nothing else so far.
The classes.dex file contains not our application at all, but the Java loader for the main FMX library application and the implementation of wrappers for Android native controls. It is this fragment that allows the application to interact with the OS and “pretend” to the usual Android application.
Degree of nativeness
As it becomes noticeable on the video, the FMX effects continue to work perfectly on Android’s “native” controls, interfering in their rendering (for example, we even turned on the lighting of the contours of the controls, which means that the FMX works with Android controls not just as with pictures, but very tightly).
Sebastian Gingter (SEBASTIAN PR GINGTER) in his well-known article on FMX speaks about the framework very unflatteringly, criticizing the fact that the user interface is drawn independently and does not look native to any of the platforms. Apparently, at some point, this was exactly the case, but now such criticism cannot be considered fair. The author denies the very idea of ​​cross-platform GUI applications, without looking at specific implementations, denying the potential advantages of such an approach.
Conclusion
The considered tool, of course, is the successor of all VCL traditions: glorious and inglorious. We were convinced that the assembly technology of truly cross-platform mobile applications works and shows very good performance. For a certain class of applications, FMX will be a good help.
Negative aspects include a noticeable time delay at the start and not a small size of the resulting application.
Used materials:
Source: https://habr.com/ru/post/222307/
All Articles