Welcome to the first chapter of this book! We are at the beginning of a journey to gain knowledge about a great application framework, that is, the FireMonkey (FMX) framework. These days, developers face a hard-to-solve problem—building effective cross-platform applications. From a project management point of view, one of the most wanted features is to achieve this goal through a single source code base, not, for example, having a different code base for each supported platform.
The introduction of the FireMonkey framework represented a crucial point, putting Embarcadero Delphi in a magic spot in the global software development scenario. Developers are enabled to design and build native applications for the most popular platforms, including both desktop (Microsoft Windows, Linux, and Apple OS X, now also known as macOS) and mobile (Google Android and Apple iOS), using a single toolset and language (thus reducing the effort needed).
This chapter will go through the following topics, to provide some background about what FMX is, why it was created, and its most evident strengths:
- Approaching FireMonkey
- Abstracting the visual part of your apps
- Looking beyond the UI
- Back to the metal
- Understanding the strengths and weaknesses of the FMX approach
After reading this chapter, you will be familiar with the general context in which this framework has been developed, including a general understanding of the underlying philosophy of the chosen approach.
Technical requirements
Here is the source code used in this chapter: https://github.com/PacktPublishing/Delphi-GUI-Programming-with-FireMonkey/tree/master/Chapter%2001/HelloWorld.
Generally speaking, for the whole book, you need a computer with Delphi set up and a few additional libraries installed (such as Radiant Shapes (https://getitnow.embarcadero.com/?q=radiant+shapes) and CodeSite Logging (https://getitnow.embarcadero.com/?q=codesite)). Having other physical devices and setting up multiple platforms (iOS, Android, OS X/macOS, and Linux) other than Windows is a plus but not strictly needed to follow the flow of the book.
Approaching FireMonkey
In this section, we will explore the general background we need to properly introduce the FMX framework. Delphi is a longevous environment and it existed way before the FMX framework. We need to delve a bit into the roots of the Delphi tool to understand FMX in a better way.
When I was still a teenager, Delphi was the best development environment to build Microsoft Windows applications. I had some Turbo Pascal background knowledge and someone told me to give Borland Delphi a try in order to easily get into visual application development. That was during the time of Windows 95 and the world, from an IT point of view, was much simpler than today. DOS and Windows had a very large share of personal computer coverage. The remaining part of the world was running Linux or Macintosh but with a limited share and only in very specific contexts. Even though the mainframe (such as IBM AS400) was still a thing, business companies were mostly running...
Abstracting the visual part of your apps
The first version of the FMX framework was released in 2011 and already had one of its fundamental features, that is, the rendering of the UI was done completely from scratch, using the GPU. At the time, the GPU already supported technologies such as shaders (https://en.wikipedia.org/wiki/Shader), opening up a way to implement high-quality vector graphics, also considering the CPU growth in terms of computational power.
It became possible to build complex UIs, decorated with stunning effects and transitions, reaching the same appealing visuals typical of technologies such as Flash (the leading technology in modern and good-looking UIs, at the time). Given that WinAPI (thus, the VCL) and the new (at that time) .NET alternatives - Windows Presentation Foundation (WPF) were not covering the capabilities, the development team of FMX saw a great opportunity to build a new framework and, thankfully, they decided to take the chance...
Looking beyond the UI
Even though many current prototyping tools tend to see an application as a bunch of views, we all know that a real application is not made only of a set of mere visual assets.
While building a cross-platform application, you obviously wish your visual application framework (FMX in the case) to deal with visual aspects but at the same time, to provide actual functionalities. This is because you will end up needing some level of interaction with the platform your application is running on.
Modern applications have to provide advanced functionalities, including some that are really basic (not always trivial, though), such as (multi-)touch support, and interaction with the system clipboard or with the filesystem. There are some possibly more specific topics, such as sensor integration (camera and positioning, for example), or other device-/platform-specifics such as notification systems, voice recognition, text-to-speech, and other advanced capabilities.
What I am trying...
Back to the metal
Each strong abstraction can easily become a golden cage for its user. This also applies to software development and frameworks where you may obviously like the fact the framework is hiding the complexity underneath and providing a simple, clean, and comfortable place where the developer can live with fewer worries with respect to a more raw approach where everything is the developer's responsibility (embracing the subsequent complexity as much as they can afford).
At the same time, this kind of safe playground (always) has some boundaries and the developer can sometimes reach one of these boundaries and will go (or need to go) further.
Delphi always shined in this, letting you stay warm and safe with your VCL components wrapping Windows controls but, at the same time, letting you directly call whatever external function was available, including, of course, all WinAPI functions. When coming to FMX, as I said, I considered it to be more than a visual framework but...
Understanding the strengths and weaknesses
So far, we have simply introduced the FMX framework, exploring both the surroundings in which an FMX application should live and the context the technology was created in.
In this section, we will discuss how the FMX framework performs in the context that it is intended to be used in (the development of cross-platform applications). We'll consider some topics representing the strengths and weaknesses of the FMX approach. This should help you understand where in the big picture of multi-platform development tools we are.
At first, consideration is given to the available continuity from VCL to FMX. At first sight, you can appreciate the fact that an experienced Delphi (VCL) developer has been provided with a chance to reuse part of their knowledge and experience while...
Summary
In this chapter, we introduced the FMX framework, including the historical reasons behind its creation and the context of where it all began. The philosophy of the framework (and its inner evolution) should act as support for the rest of the book and should provide you with some basic understanding for the rest of the content of the book.
If you are an experienced Delphi developer, this chapter should have provided you with a non-technical bridge from classic Delphi to the newer versions, now including this second application framework, other than the original VCL. At the same time, if you are a developer addressing Delphi for the first time, a little background information should help you go through the rest of the content of this book.
In the next chapter, we will explore differences and similarities with respect to the VCL. This will serve experienced developers to learn how many of their skills they can reuse and what they need to keep in mind for their new projects. If you...