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, theFireMonkey (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 theFireMonkey 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, andApple OSX, now also known asmacOS) and mobile (Google Android andApple 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.

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 someTurbo Pascal background knowledge and someone told me to giveBorland 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 runningLinux orMacintosh 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 Windows.

Given that I had limited DOS programming knowledge, I spent a lot of time learning how to build a Windows GUI application and also experimented with other languages (such as Visual Basic,Java, and Visual C++) but Delphi has been my favorite right from the start.

The ability to easily build beautiful Windows applications through a designer is still a great plus and I really think this has been one of the key factors of Delphi's success. The following screenshot shows the Delphi 10.4.1 Sydney splash-screen:

Apart from the convenient GUIRapid Application Development (RAD) approach, built into an effective IDE,Object Pascal was a great language showcasing fullObject-Oriented Programming (OOP) support, great C compatibility (perfect for Windows API calls), and featuring a very fast compiler. Generated applications also had outstanding runtime performances.

Looking at Delphi as a whole product, what surfaces is a fantastic tool, capable of letting developers focus on their application code while building fast, good-looking, modern applications – a shiny gem to easily deliver proper and curated GUI applications for the Microsoft Windows platform. In other words, the product performed very well by being more abstracted than raw C/C++ programming and proving to be way more powerful than Visual Basic (just to cite two of the biggest Delphi competitors over time).

This has been possible thanks to a framework shipped with the product: theVisual Component Library (VCL). It acted as a sort of abstraction over the standard Windows controls, wrapping them in a more suitable and easy-to-use programming interface. A big difference with respect to other products has been that all this provided the ability to go back to being low-level and interact with the primitive control whenever needed.

Using the VCL was convenient and the library naturally evolved over two decades (at least!) of development by covering more and more Windows features and capabilities. Every Delphi developer felt at home while dealing with VCL components and most applications never needed to breach into low-level code. This meant higher productivity for the developer and I myself have seen several projects started with other technologies then being abandoned due to running over time for the project execution. Developer teams struggled to deliver functionalities in years while the same project revamped with Delphi came to a successful conclusion within months.

Today, the general scenario is much more complex than what it looked like in the late 1990s. We have seen the rise of mobile platforms and at the time I am writing this, a mobileOperating System (OS) (that is,Android) is now the most used OS worldwide. Also, the desktop platforms scene has seen some changes and nowApple’sMac OS X (aka macOS) has much more widespread adoption than before (even if this is not equally true in every part of the world).Linux somewhat lost the race for desktop user adoption (I am not considering Android as a Linux family member, even though it is Linux kernel-based) but got a relevant position as a server-side platform (driving the web, one could say).

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 to say is that FMX (and the Delphi RTL parts added by Embarcadero in recent years, available both for FMX and VCL) is much more than a visual framework, that is, it provides powerful abstractions that a developer can use to implement functionalities in a real cross-platform way.

This is true and evident in many areas we will cover throughout this book. Starting frombehavioral services, with the aim of abstracting some device-/platform-specific behaviors (such as tab positioning in tab control or the default presentation mode of some components such as TMultiView, commonly used to implement mobile app menus). We could also abstract audio/video services, where a single, shared interface lets you access device cameras, microphones, or other common (but specific) aspects related to the multimedia area.

Just as a simple example, iOS and Android use different file formats for audio and video, thus to have a singleTMediaPlayer component leveraging this difference is very convenient for the developer, that is, just ask the component to play or record audio/video with the same code.

Accessing the storage of the device (thecamera roll for iOS or theGallery/Photos apps for Android) is another great example. There are many functionalities (the device contact list to name another one), and it is hard to provide an exhaustive list.

You may think this list would represent the playground for the app developer but this is only partially true, that is, the VCL has a great level of abstraction over most Windows controls and APIs. Though, you always had a chance to goback to the metal, breaking this generally convenient abstraction and tweaking your code, adding low-level Windows API calls (without confining your possibilities to what the framework offers) and this is true also in the FMX framework, as we will see in the next section.

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 rather an application framework; this is still true because, even if you can’t handle FMX controls using APIs designed for native controls, you can still have your FMX (and RTL) Delphi code with platform-specific calls to the underlying APIs of the currently running OS.

This means you (from your Delphi code) can call any iOS library functions (as you would do inObjective-C orSwift). The same applies to Android where you can wrap (there is the Java2OP tool available for Embarcadero’s registered users) the Java code you want to reach into Delphi classes and functions and have it available for your application developer. Even though this may seem like a kind of last refuge for the developer, it also represents a guarantee that your framework (FMX) is not closed and you are actually able to get back to the metal as much as you like or need.

For example, it is not unusual, when writing Android apps on custom devices (that is, those including industrial-level optical orNFC/RFID readers) to have the manufacturer of the device provide it with a standard Android OS image with the addition of some externalJAR files with the libraries needed to properly interface with some device-specific features. Also, it guarantees that if Embarcadero is not providing you this or that API wrapper, you may proceed and generate it (manually or with a tool such as Java2OP) without having to wait for official support for that functionality.

In the next section, we'll try to consider the good and the bad coming from the peculiarities of the FMX approach.

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 moving from a single (very specifically, Windows) platform development environment to a multi-platform (and/or cross-platform). The existence of FMX has enabled all those Delphi developers to not have to start from scratch (possibly doing this multiple times, one for each platform to address) while making their first steps into new scenarios (such as mobile platforms).

This is far better than having completely different toolsets, especially if you are building a project supporting multiple platforms and also if you are a developer of several projects targeting different platforms. Today, we are starting to diffusely see software (applications) as the backbone of industries and, more generally, today, everything seems to have a somewhat software core to it, with the IT industry gaining more and more consideration and respect. At the same time, this means a huge increase in the demand for software with sustainable costs in terms of money and delivery time, with more and more demanding quality factors.

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 are new to Delphi and will start with FMX, you will nonetheless find some useful basic information about how FMX works, so turn the page and go ahead!