Firemonkey from simple to complex. firemonkey. What to read and see? FireUI Live Preview -- Display the app view on real devices in real time

TRippleEffect class for creating an effect that superimposes ripples of waves on the texture of visual objects.

The center of the ripple is specified in the property Center. Other aspects of the ripple can be customized using properties Amplitude(Amplitude), AspectRatio, and Phase(Phase). The number of ripple waves is determined by the property Frequency(Frequency).

The following table shows the impact results TRippleEffect to a PNG photo placed on the form (using the object). The center of the ripple is in the middle of the image. Other properties TRippleEffect are used with their default values ​​( Amplitude = 0,1, AspectRatio = 1,5, Frequency = 70, Phase = 0).

In this tutorial, you will be using a few basic image effects in a FireMonkey application.

Step 1: Apply the effect to the image.

In FireMonkey, applying an image effect to an image is a simple process. Just create a component that can contain an image and then apply one of the image effects.

Create a new FireMonkey application ( File > New > FireMonkey Desktop Application > HD FireMonkey Application).

Place the component on the form.

Select the component on the toolbar.

Position the TImage on the form in the constructor.

You can see that the component is not placed in the center of the form designer. As shown in the figure, it is necessary that the size of the image area be as large as possible. To do this, select the component on the designer form and then change the properties Align v alClient in the Object Inspector so that the size of the component becomes the same as the client size of the form region.

Select the image you want to apply the effect to. The component stores the picture in a property bitmap. Select property bitmap in the object inspector, and using Edit... to select an image.

1. Now you can choose an effect for the image. On the tool palette, select TRippleEffect.

Now Ripple Effect displayed in the window structure.

To apply an effect, it must be defined as a child of another component. In this case, RippleEffect1 must be defined as a child Image1. To do this, drag RippleEffect1 and place it on Image1 on the structure panel.

1. Now you can see that Ripple Effect already working on Form Designer.

1. Change the property Frequency on the 20 .

Step 2: Apply an animation effect to the RippleEffect.

Highlight Ripple Effect on the panel structure.

Highlight a property Phase in the Object Inspector and run the command Create New TFloatAnimation from the dropdown menu.

Make sure that FloatAnimation1 defined as a child element RippleEffect1.

Change properties FloatAnimation1 as below:

And finally, let's add an event procedure OnMouseMove To .

More than three years have passed since the CodeGear division responsible for creating such world-famous tools as Delphi, C++Builder and JBuilder, as well as the Interbase DBMS, became part of Embarcadero Technologies, a company known for its database design and administration tools. , and two years since we discussed on the pages of our magazine what to expect in the development of tools that are so popular among Russian developers. We asked David Intersimone, Vice President for Developer Relations and Chief Evangelist of Embarcadero Technologies, and Kirill Rannev, Head of Representative Office of Embarcadero Technologies in Russia. For our youngest readers, we will inform you that this is far from the first interview that David and Kirill give to ComputerPress - our cooperation has been going on for the second decade. And for about the same number of years, we periodically publish reviews of database management tools, in which a lot of attention is paid to Embarcadero products.

ComputerPress: David, your division has been part of Embarcadero for three years now. Two years ago, you were full of enthusiasm about the fact that it became part of a company close to you in purpose and spirit. Has anything changed during this time? Do you and your colleagues feel the same enthusiasm?

Yes, I'm still enthusiastic. The main change that has taken place since we became part of the Embarcadero company is that there has been a lot of investment in the development of Delphi. The number of employees working on development tools has increased, the number of technologies that we can develop or, if necessary, acquire has increased.

The release of RAD Studio XE 2, which we plan to demonstrate in Moscow, is the largest release of this product with huge capabilities and a large number of supported platforms since the first version of Delphi, created for 16-bit Windows and the former innovative product that connected the component approach and compilation to machine code. Now we support development not only for Windows but also for Macintosh, not to mention web development and creation of applications for mobile devices, and these applications for different platforms can have a single code.

The new development platform, FireMonkey, is a collaboration between Embarcadero and the recently acquired Ulan-Ude-based Russian firm KSDev, a maker of vector graphics components, DirectX and OpenGL, graphics effects technologies, and Delphi components using a GPU with PixelShader 2.0. We acquired the company KSDev (see ksdev.ru) a year ago and started working together to create a multi-platform development tool that includes a platform for developing FireMonkey applications with components for Delphi and C ++ Buider for creating application user interfaces, integrating with databases , graphics processing using a graphics processor and integration with the operating system.

Using FireMonkey, you can create an application that runs the CPU and GPU together, and then using different compilers and run-time libraries (Run-time Libraries, RTL) you can compile it for Windows, Mac OS or iOS. Rather than learning programming with different graphics libraries, learning APIs from different platforms that have different coordinate systems and different capabilities, developers using Delphi and C++Builder can use the same component approach, visually editing forms and connecting to databases by moving the component with the mouse. This is a fundamentally new way to create applications that run on different platforms, and is the future. If you want to add support for other operating systems and platforms to your application, you do not need to redesign and develop it - it will be enough just to recompile it.

We create new compilers that generate native code. Today there are Delphi compilers for 32-bit and 64-bit versions of Windows, 32-bit versions of Mac OS 10. And we are working on next-generation Delphi and C++Builder compilers that will allow you to create high-performance native code for both these and others. platforms like Android or Linux and keep the same design, the same components, the same code by using different compilers and runtime libraries.

As you can see, I have enough reasons for enthusiasm. And the developers I meet around the world know that Embarcadero is investing a lot in Delphi and C++Builder as well as PHP development tools.

KP: What progress have you made in integrating the tools of the two companies over the past two years? What are Embarcadero's plans for the future in this area?

DI.: At the time when the CodeGear division became part of Embarcadero, this company had development teams in Toronto, Monterrey and Romania, we were and still are in Scotts Valley and in Russia, in St. Petersburg. Embarcadero had developer tools and database administrators, CodeGear had application development tools, but the latter also use databases. The merger of companies is a combination of expertise, knowledge in the field of databases, code optimization, including server code. The merger also resulted in the creation of a new product, AppWave, a special technology for turning an ordinary Windows application into something very easy to use (like applications for iPhone or other devices). AppWave allows you not to install an application, but simply select it and run it from the prepared application storage (app) server, while it will be executed on the user's computer without making changes to its registry and file system system area. By the way, the AppWave application browser is written in Delphi. Embarcadero uses Dephi for its own development and our application development expertise.

iPhone app (iOS) created by
using the FireMonkey platform

You can also use the integration of our development tools and DB Optimizer to optimize SQL queries when building applications. By passing SQL code directly to DB Optimizer, you can profile it, test it, and return an optimized version of it back to the development environment. Embarcadero's database expertise has also improved the DataSnap technology. Thanks to the developers from Toronto, we have gained a lot of knowledge about the architecture of multi-tier systems and databases. We now have joint expertise in server code and stored procedures in both companies. We have tools like RapidSQL and DB Change Manager, and development environments that make it easy to create server-side code, such as Code Insight and Code Completion technologies that have made it possible to create SQL insight and SQL Completion technologies. Our common approach to creating client and server code, our common philosophy, allows us to share common features between database management tools and application development tools.

Kirill Rannev: I want to add something important. From a commercial point of view it is very important how we deliver our tools. For example, the new release of RAD Studio XE 2 Ultimate includes the full set of DB Power Studio tools. It is a very powerful set of tools, including the RapidSQL query authoring environment, the DB Change Manager change management tool, and the DB Optimizer query optimization tool, that allow you to perform an important part of the development and deployment process, managing changes in the data model, database, code, etc. This is a very good and correct combination of technologies.

DI.: But, if needed, developers can use Subversion to manage source code versions and DB Change Manager to manage metadata versions. You can use code profiling and DB Optimizer to optimize server code, RapidSQL to build and debug server code, and our development environments to build and debug applications. This combination of technologies in RAD Studio XE Ultimate Edition demonstrates the parallels between database and application development models. Most developers building business applications with Delphi and C++Builder work with databases and need these tools, and RAD Studio XE Ultimate Edition is a great combination for those developers.

KP: The modern user is no longer a user of the Windows platform alone. We use mobile devices, iPhone, iPad, devices based on the Android platform. This means that developers should start targeting different platforms without a significant increase in investment in training - that is, universal tools are needed. Obviously, it is unrealistic to expect the emergence of universal tools from platform manufacturers, and in this matter we can only rely on independent tool manufacturers. Where can we rely on Embarcadero?

DI.: We still have a lot to do in the area of ​​platform support. Today we are introducing support for the iOS platform for iPhone and iPad, followed by support for Android, Windows 7 and Blackberry smartphones. In RAD Studio XE 2, we started by building the FireMonkey platform for iOS and will later port FireMonkey to other platforms.

At the same time, there are a large number of operating systems that support touch screens (touch screen), for phones, tablets and devices, desktop computers, and we will continue to add support for them. In addition, there are voice control systems, motion control systems, biometric systems, accelerometers, so we must continue to expand FireMonkey so that all developers can take advantage of new platforms. For example, the Microsoft Kinect device was designed for the Xbox 360, and now there is a corresponding SDK (Software Development Kit) for Windows. And we already have examples where we use motion to control an application in much the same way that we would normally use a mouse or keyboard.

When you create applications with lots of complex graphics, you generate a whole world of new user interfaces. If we are dealing with the Windows operating system, we encapsulate its Windows API in the VCL library (Visual Component Library - a visual component library that is an integral part of the Delphi and C ++ Builder development tools. - Note. ed.), which, by the way, can be applied further. And in FireMonkey, we encapsulate the operating system API. But today we manipulate forms and graphics much more widely. You can also add physical space properties for animation and special effects. In addition, there are a huge number of other additional features for creating user interfaces that we are going to implement in the next few years for different platforms, mobile and tablet devices.

Microsoft recently released details on Windows 8, which is due out in a year. We will support these innovations in the VCL library and in the FireMonkey platform. But Delphi is a development tool designed not only for Windows, but also for Macintosh, iPhone and iPad. We also develop our PHP products, support jQuery Mobile, use the iOS API to develop mobile client applications, and create server-side PHP applications using wizards and tools to generate client-side JavaScript, HTML, and Cascading Style Sheets. We can package PHP applications and iPhone iOS native client applications, with the client talking to the PHP server. And that, in turn, will communicate with the database server and with web services - with everything that is needed for business.

RadPHP XE2 development environment. Create a mobile web application
using jQuery Mobile components for iPhone 3G

In other words, we plan to expand the capabilities of FireMonkey and VCL, including support for mobile platforms.

KP: Could you elaborate more on the FireMonkey platform?

DI.: As I already noted, the VCL library created for Windows will continue to develop and improve. But today, if you want to actually develop business applications, you must create them for different platforms. This is what the FireMonkey platform is designed for. It supports the creation of high-resolution user interfaces, high-performance 3D graphics, high frame rates, and, importantly, uses a GPU for this.

You can use these features when creating scientific, engineering and business applications. Such applications can connect to databases using dbExpress technology, still using non-visual components familiar to developers, such as ClientDataSet or DataSource, use DataSnap technology, connect to any databases, SOAP and REST servers. You can create attractive controls, boxed buttons, fancy tables, and other interface elements in 2D and 3D. You can load a ready-made 3D model into the application and combine it with a 2D shape, in which it can be rotated and viewed from different angles. You can create a data cube or a 3D business chart and rotate it using your mouse, keyboard or even a Kinect device, or you can go inside the cube and look at its different surfaces from the inside. And all this can be done with a high-speed GPU. The same application can then be compiled for another platform, such as Mac OS.

Application containing a rotating cube with data,
placed on its edges

Or you can create a 3D shape from scratch and use cameras and lights to light and rotate parts of the user interface. The form designer already has a built-in environment to support the 3D user interface directly at design time.

On Windows, you can use the Direct2D libraries for high-resolution 2D graphics, and Direct3D for 3D graphics. Mac OS uses the Quartz and OpenGL libraries for the same purpose. For iOS, the Quartz and OpenGL ES libraries are used. But all this is hidden from the developer - he uses the FireMonkey platform, its coordinate system and application programming interface, without thinking about these libraries, and can compile the same application for different platforms.

Let's remember what VCL is. The VCL is a component "wrapper" around the Windows API. We are dealing with resources, menus, dialog boxes, colors, styles, Windows messages. Being a multi-platform wrapper unlike VCL, FireMonkey retains the same event and component models, allowing you to think in terms of events (for example, OnClick, OnHasFocus, onMouseDown, and onKeyDown events), but handle Macintosh or iPhone events.

The FireMonkey framework also comes with a complete system for animating user interface elements. It's certainly not a comprehensive Pixar-style animation system, but it allows you to apply effects such as animating bitmaps, highlighting the focus of a user interface element, and working with vector graphics. More than 50 visual effects are available to the developer: blurring, turning an image into black and white, dissolving, transitions, reflection, creating shadows - all types of effects available in modern GPUs that are now in almost any computer. An application built using the FireMonkey platform sends commands to the GPU, which does all the work of displaying graphics and creating the user interface. At the same time, the central processor is free for calculations and accesses to the operating system. The developer only needs to correctly place the components.

The most fundamental thing about the FireMonkey platform is the way it builds the user interface. There are facilities for placing bitmap graphics on interface elements such as menus, buttons, and scrollbars. In FireMonkey, we use GPU vector graphics for this purpose. From a programming standpoint, these are all the same controls, but all the work on displaying them is carried out by the graphics processor. We can apply styles to controls, make the application look like an application for Mac OS or Windows, create our own style, apply our styles to interface elements (for example, make a button rectangular or round by changing its style in the form editor) - for this the development environment has a style editor. You can create your own style, or you can change the style of an already finished application.

FireMonkey Platform - Development Tools
and supported platforms

If you remember, in the VCL library there was a limited number of controls - containers (that is, allowing you to place other elements in them), and in FireMonkey each control is a container. This means that every control can contain any other control. For example, dropdown list items can contain images, buttons, edit boxes, and other controls. And you can also place components on layers.

The FireMonkey rendering system is quite flexible - it can use the Direct2D, Direct3D and OpenGL libraries by sending commands to the GPU. To achieve the same in VCL, it was necessary to generate a separate off-screen buffer, create an image in it by calling the appropriate functions of the graphics libraries, and then display it on the form.

Examples of graphic effects supported by FireMonkey

If you don't have a GPU, you can still apply 2D or 3D shapes and use FireMonkey controls. In this case, the FireMonkey platform will use the GDI+ libraries or other similar libraries and perform the same effects and animation or manipulation of 3D objects.

Another feature of FireMonkey is a new system for binding interface elements to data, which is open and flexible. There are two types of interface elements in the VCL: data-bound and non-data-bound (for example, TDBEdit and TEdit). In FireMonkey, every control can be associated with data, of any type. It can be just an expression, a field from a dataset, data from developer-created objects, or the results of method calls.

In addition, when creating an application, you can load a ready-made 3D model into it and use it - such capabilities are often required in both business and engineering applications. We have a client who creates applications for logistics. They had an information system built with Delphi, and in it, an application that drew a plan and displayed information from data sources. They recently did something interesting - they drew a fully automated 3D warehouse in AutoCAD, and their application allows you to see how an automatic loader moves through the warehouse and places goods on shelves. And they lay out data from sources on the corresponding image.

Examples of Changing Application Styles

KP: What 3D model formats are currently supported?

DI.: In this release, we support loading models from AutoCAD, Collada (an open source 3D modeling tool. - Note. ed.), Maya, an OBJ format supported by many 3D graphics vendors.

KP: What other formats are planned to be added?

DI.: We plan to add 3DS (3D Studio MAX), SVG (usually this format is used for 2D vector graphics, but sometimes for 3D), Google SketchUp. We may support other formats as well.

KP: Does the use of 3D models in applications built with FireMonkey require a license for the appropriate 3D modeling tool?

DI.: No, it doesn't. All we do is read the model file. We are importing the model but not exporting it (although of course you can write an application that saves the model in your own format). We do not claim to be a manufacturer of 3D modeling tools - for this you can use AutoCAD, 3D Studio Max, Maya or any other 3D modeling tool, and import the created models into our applications.

KP: How performant are applications built with FireMonkey on modern hardware platforms?

DI.: The performance is quite high. For example, a 3D shape with three spheres and three lights can be rendered at 100 frames per second on a MacBook Pro. And it can reach 600 - it depends on what exactly we are doing. Again, it all depends on the power of the GPU.

KP: Does this mean that with the help of FireMonkey you can create games that meet modern requirements?

DI.: We do not position our development tools as a tool for games. However, using the high performance of modern GPUs, you can also create games with FireMonkey - after all, they are created using Direct3D or OpenGL.

KP: What work are you doing now in the field of support for gesture recognition and other newfangled things? Is such support available?

DI.: We don't have gesture support in this release yet. Gesture control will be added in a future release of FireMonkey, but for now, you can use the gesture support built into the operating system.

Mikhail Filippenko, director of Fast Reports, Inc.

K.R.: We have already said that the FireMonkey technology has Russian roots - its foundations were created in our country, and then the technology itself and its developers merged into Embarcadero. In general, it is gratifying to see the growth of the Russian component in RAD Studio and Delphi. This is the activity of our development center in St. Petersburg, and the contribution of independent Russian developers. For example, Rad Studio XE2 includes the FastReport report generator, which is known all over the world and very popular in our country. He is from Rostov-on-Don.

KP: I would like to talk about compilers. What compiler is used to create iOS apps?

DI.: We do not have our own Delphi compiler for the iPhone or iPad - we have not yet developed compilers for the ARM processors used in these devices. For iOS, we temporarily use the Free Pascal compiler and runtime library. But we are working on the next generation of compilers, including those for ARM processors. But there are compilers for Windows and Mac OS, since both hardware platforms are based on Intel processors.

KP: And what has been done in the field of compiler development in the last two years?

DI.: We have 32 and 64 bit Delphi compilers for Windows and Mac OS. And we are working on a new generation of Delphi and C++ compilers. Work on them is still ongoing, but when it is completed, we will have Delphi compilers for ARM processors, Android platforms, Linux and whatever. And we will have 64-bit C++ compilers for Windows and other platforms compatible with the latest C++ language standard just adopted by ISO.

KP: What's going on with cloud computing support in Embarcadero development tools today?

DI.: With RAD Studio XE 2, we support migrating applications to the Microsoft Azure or Amazon EC2 cloud using the Platform Assistant. And we have server components for Cloud Storage for Azure and Amazon S3 for storing tables, binary data, message queues. In the previous version of RAD Studio XE, we also supported deploying applications to Amazon EC2, but there was no storage support.

Cloud computing support in RAD Studio XE 2

KP: Two years ago you talked about the new All-Access solution. How much was it in demand? What are its benefits for system integrators and developers?

DI.: The All-Access solution and the AppWave cloud tool are widely used around the world. They are designed to make it easier to use both our company's and third-party applications. In fact, this is a solution for managing licenses and applications, and it is convenient for large companies. Smaller firms that don't have a dedicated application management team can put the application into a repository, select usernames from a database, and make those applications available to use without having to remember where the license key is and how many licenses are available. All-Access and the AppWave browser are designed to manage both versioning and access control.

K.R.: The market is so diverse, and users are so different, that it is impossible to cover all needs with one solution. Therefore, we strive for a variety of "packaging" solutions. We've done a lot of work to unify licensing, license management, and product installation. This line of solutions includes license and access management tools not only for Embarcadero products, but also for any other products, including internal developments of companies.

The work of bundling development tools into effective user kits is still ongoing. We have All-Access - a superset that combines all Embarcadero products. If the customer purchases the All-Access Platinum version, he receives all the tools that are in Embarcadero. But sometimes this set turns out to be redundant, for example, we made two other sets for database specialists - DB Power Studio Developer Edition and DB Power Studio DBA Edition. The difference between them is that for the developer we offer RapidSQL - a tool for developing server code, and for the administrator there is built-in DBArtizan - a database administration tool, a wider product than RapidSQL. For professionals, we have the following All-Access suites: the all-product suite, DB Power Studio for developers, DB Power Studio for administrators, ER Studio Enterprise Edition for architects and anyone involved in modeling. There are combinations for application development and for administrators. Delphi is a developer's tool, and it makes a lot of sense to add SQL development tools and optimization tools to it. Finally, DB Change Manager is a very logical tool for managing the complexity of the changes that occur to databases during their life cycle.

Thus, All-Access is the head of a large family of different product sets.

KP: If it's not a secret, who in Russia uses All-Access?

K.R.: We have customers who bought All-Access based on Delphi. Many of them are building complex client-server systems with SQL Server and Oracle, and they immediately liked our cross-platform database toolkit. We have a client company that has been working with Delphi since the first version and moved from Delphi to All-Access a year ago. Two tools that are guaranteed to be used by all developers in this company are Delphi and DBArtisan. And there are customers who came to All-Access from the database side. Their primary job is to administer databases, but they also occasionally develop applications. Clients using All-Access include media companies, machine builders and other industries.

Separately, I would like to dwell on small companies. Very often in small teams, the developer does everything, and such a company sometimes buys large All-Access food packages for one or two developers. In large teams, it is not encouraged that the developer also perform the role of a database administrator, for example, so small food packages are usually popular there, and in small companies this combination of duties is quite acceptable.

Delphi Architect is a heavily marketed product that includes modeling and programming tools. The number of copies sold, however, is less than the Delphi Enterprise versions, but it is also large. I note that in 2010 we were the best country in terms of sales, despite the fact that all countries survived the crisis. This growth was due not so much to economic factors as to the fact that the version of RAD Studio XE, released at the end of 2009, turned out to be in great demand. And while we expect further growth in sales.

We have taken another reasonable step, which is highly demanded in Russia. The degree of legalization of different versions of our products is different: the higher the version, the more legalized it is, because earlier the software was not so actively bought. Starting with RAD Studio XE, the license covers versions 2010, 2009, 2007, and even Delphi 7, a widely used product.

Today, developers are faced with the fact that they have both new projects and projects in a state of support. A large number of projects have been migrated from early versions of Delphi to version 7 and remain within this version, continuing to work on relatively small resources. No one is moving them to newer versions, but they are kept viable. And now we allow for little money (less than the price of a Delphi 7 license) to get both RAD Studio XE and Delphi 7 - that is, we legalize the developer both for the implementation of new projects and for support projects.

KP: How do you assess the current state of the Embarcadero community?

DI.: This community is large and very demanding. They need everything and immediately - they are developers. But sometimes it takes a long time to get something right.

A few years ago we took the Windows component architecture and put it on Linux desktops. Now we see that it was not the right decision. The right decision is to create a platform for applications. Applications even for different platforms have menus, windows, graphics, network access and access to devices. Different platforms may have different flow control or exception handling models, but we see the same try blocks in application code. Our job is to make it easy for developers to create business applications and compile them for the platforms on which they are supposed to be used, regardless of how the instruction system of the corresponding processors is arranged and what other features of these platforms are. And FireMonkey is exactly what you need to solve this problem.

KP: If a company creates a new device and wants to have FireMonkey support for it, would that be possible?

DI.: With new generation compilers that will have a platform-independent front-end and a platform-dependent back-end, this will be quite possible. In the meantime, for each operating system, we create a compiler and runtime library from scratch.

Any modern new device usually has a graphical user interface (many of them have a dual-core processor and GPU) and standard SDKs for developers. All this simplifies the creation of device support in FireMonkey. If the new device only has libraries for 2D graphics such as Quartz, we will be able to support such a device in FireMonkey, but this will take approximately several months. However, a lot depends on the platform: not all platforms support all features, for example, iOS does not have menus and dialogs, and you will not be able to place the corresponding components on the forms of such applications.

KP: Has anything changed in the policy of working with partners? What is being done to increase the share of users of your products? What is being done in Russia?

DI.: Our partner ecosystem is wide - there are hundreds of manufacturers of tools and components not found in our products, and we have a technology partnership program. Therefore, a wide range of components, technologies and tools are available to developers. And the solutions they create for their customers are better than if only our products were used. And for sales, we have offices in many countries, resellers and distributors.

K.R.: What matters to us is not the number of partners, but the quality of work of each particular partner. For now, we want to focus on working closely with existing partners, although the pool of partners remains open. We have many partners, and we must help them in terms of technology. We work with developers, and they know what they want and know what is available on the market, and the capabilities of partners must match this.

We have business partners who have invested heavily in Embarcadero as a line of business - they have trained specialists, marketing of our products, dedicated employees who are responsible for this area and monitor what happens with our products, price list, marketing. Naturally, they are more successful in terms of sales of our products than companies that sell our products on a case-by-case basis.

KP: David, Kirill, thank you very much for the interesting interview. On behalf of our publication and our readers, let me wish your company continued success in creating your amazing tools that developers need so much!

Questions were asked by Natalia Elmanova

Enough time has passed since the term FireMonkey has become more or less familiar, if not to all developers, then at least to those who use Delphi. During this time, there were books on FireMonkey, articles on FireMonkey, entries about FireMonkey in numerous blogs. Reading all this is very interesting. But no theory can replace practice. And I, like many before, had an itch to try writing something using FireMonkey.

In doing so, however, a problem arose. For some reason, I decided that I just needed to implement some not very complicated working project.

To explain why this turned out to be a problem for me, it will take some (one wants to write, lyrical) digression. An excursion into my past as a developer. Explain some of my views on programming using Delphi.

I must say that I started using Delphi on Windows 3.1, that is, from the first version. And since then I have been studying VCL. Studied in the original, so to speak. Watched, addressed, traced source codes. Again and again.

It is known that at various times the set of components shipped with Delphi included third-party components that were supposed to fill in the gaps in the VCL, and which probably went through some kind of quality control before being included. Some of these components continue to be supplied to this day. Take the same Indy. I don’t want to offend anyone, this is purely my personal opinion, which also applies to myself as a component developer: not a single set has been so deeply thought out and implemented as well as a huge and diverse VCL. No, I do not pretend to be the ultimate truth, and, of course, there are many errors in the VCL itself, decisions that cause misunderstanding, cause rejection and with which you want to disagree. But I always got the impression of a certain single style. There is in VCL, in my opinion, a beautiful and strong core that supports the entire Delphi design, and around which both the software infrastructure and the developer community itself are built. Thanks in large part to the VCL, again, in my opinion, the rumors about the death of Delphi are still rumors. And when third-party components were included in the delivery of the VCL, it was immediately noticeable, they were different.

But then the moment comes and I hear that VCL is a technology that is outdated. A technology that should be left in the past. Developers should implement all their new projects on FireMonkey, but about old ones ... it would be nice to transfer them to new rails. FireMonkey is everywhere and always. And I hear it from different sources. And quite persistently. No, nobody kills VCL. he stays with us. But he is no longer number one. He should be a stand-in. At least that's how I understand what is being said about the future of the product.

In principle, I understand this alignment. A course has been taken for multi-platform, and, more importantly, for cross-platform. After all, what is VCL? Visual Component Library. Library of visual components. You may not agree with this. For example, I have always considered a lot of non-visual components, and not components, but just classes, an integral part of the VCL, and a huge number of third-party classes and components - a continuation, an extension of the VCL. Well, I can't consider the TDataset's heirs as not part of the VCL. Although, for example, the term DBExpress Library says that it is, as it were, not a VCL. Apparently, Embarcadero really divides the monolithic, from my point of view, VCL into a number of separate libraries. No, of course, not entirely separate, but nonetheless. And if you take this point of view, FireMonkey is intended to replace the visual part of the VCL (how should I still call the complete class and component library, maybe Borland Component Library?).

What are the visual components of the library built around? Around the low-level, basic elements provided by the operating system. Window handles, fonts, windows themselves, input elements, messages, device contexts, and much more - these are not the concepts of the library that comes with Delphi, but the concepts of the operating system. Yes, that's right, Windows. And if you want to build a cross-platform library, then it is logical to refuse the infrastructure offered by the operating system that executes the program written using the library.

This is exactly what FireMonkey is trying to do. They are trying to create an infrastructure based on the underlying mechanisms supported by various operating systems that can replace the service that the operating systems themselves offer.

Many remember trying to makecross-platform not only the library, but Delphi itself. Parallel to Delphi 6, the Kylix product and the CLX library were released. All this was done in order to be able to develop for Linux. However, Linux does not have many of the basic GUI windowing concepts that Windows does. The window interface for Linux is generally not a native phenomenon. This is an optional application. And I had to write some kind of synthetic library. With its help, it was possible to write a program for both Windows and Linux. However, I still remember that feeling, not of disappointment, rather of annoying inconvenience, that I experienced when I tried to use the analogues of visual components from CLX. I started missing a lot. What I used to do without thinking when developing with the VCL turned out to be difficult, very different, or simply impossible to do using the CLX.

I felt about the same when switching from BDE to DBExpress. Old, familiar from Field Test-a BDE (Borland then already used it in Quattro Pro for Windows and in Paradox for Windows, and it was called ODAPI, and then IDAPI, and was a cut above, in my opinion, Microsoft's ODBC) was declared obsolete technology, which should give way in new projects to a new library. I was always missing something in DBExpress at first, especially knowledge.

At the same time, I in no way want to scold or criticize either the libraries listed above, or the decisions that led to their appearance. It's just about my impressions, sometimes first impressions.

Now, perhaps, it becomes a little clearer why the decision to write a small working project using FireMonkey brought a number of problems. For many years, in the development of projects, projects and projects, a certain stereotype has been formed, a certain template of what and how to do. And in my case, I had to face the fact that the template needs to be changed. Because you can't transfer everything you're used to using VCL to a project built on FireMonkey.

At the start of the project, I experienced a certain sense of deja vu. Namely, a feeling of discomfort. For example, the usual input elements do not have many properties. Tricks that have become firmly established in practice, based on tricks related to the knowledge of some features of the operating system, do not work in a new context. Not to mention that some components have changed radically.

Well, another important nuance. What kind of projects usually have to be done at work, if it (work) is not related to writing compilers, modeling systems, or anything else highly scientific? I think for most it's about developing something that involves using databases. Moreover, something highly scientific can also use the services provided by the DBMS.

Here another ambush awaited me. For some reason, when you come across in practice that FireMonkey does not contain elements focused on working with data stored in the database, you are not quite ready for this (to put it mildly). Although I have already read about this many times and you know (theoretically) what you should use. It's about Live Bindings.

I don't want to get into an argument about whether real cool programmers should use db-aware components or shouldn't. display, edit and ultimately save. Which, again, is neither bad nor good. It just happened that way for me.

This concludes my first impressions post. Next in line are stories about what and how they overcame while working on the project.

In the context of this blog, this project is primarily interesting because it is implemented on FireMonkey and is an amazing demonstration of the capabilities of this platform. And so, just last week, the public beta of the product was released. Thus, blog readers can “feel” the really complex firemonkey Appendix.

A few words about the program. First of all, it should be noted that the current version of Sphere is positioned a little differently. Yes, sometimes it happens...

New SphereLive This is not just another messenger. First of all, it is a tool that allows you to effectively organize the educational process. It allows remote lectures, private consultations, individual lessons and other similar events. At the same time, it is equipped with almost everything necessary for work. Starting with a unique file transfer system and ending with a powerful billing subsystem.

At this stage, the prices for using the product are quite democratic. Subject to a limited number of listeners and a small amount of resources, the product can be used for free.

Naturally, the Sphere uses the main advantage firemonkey- cross-platform. Now the application is available in Windows and MacOS editions. Android version is expected any day.

Nevertheless, for me, SphereLive is interesting, first of all, as an innovative product with a whole range of original solutions. Sometimes just on the level of “…wow, how did you do that?” By the way, one of the developers of the Sphere actively participates in discussions on the FireMonkey forum. By itself, this can be a reason to download the application and discuss technical issues directly with the author. Believe me, there is something to see, there is something to learn.

TListView is one of the key components for building a mobile application interface in firemonkey. This component is not the easiest to use, often involves a significant amount of code, but provides the developer with considerable freedom of action. Of course, applications can also use TListBox where everything is much easier. But TListBox, perhaps good for displaying a fixed number of records, for displaying data from data sources, you should definitely use TListView.

The main differences between TListView and TListBox are:

1. TListBoxItem- control, TListViewItem- No
2. V TListBoxItem You can add any controls using Parent. V TListVIewItem- No.
3. TListVIewItem stores only display data
4. TListVIewItem itself performs rendering of the stored data through the method Render
5. Due to the actual manual rendering in TListVIewItem, an increase in speed and low memory consumption are achieved (storing only actual data)
6. To create your own TListViewItem, you need to create your own item class, implement the required data in it (for example, time) and create an in-place editor to edit the time, register it, etc.

By itself, the fact of improving performance and reducing memory consumption is a strong argument in favor of using TListView. But there is also something else.

In many Android applications, I have seen the following implementation of lists. When you click on a list item (Item, if you stick to the chosen terminology), a certain action is performed. Usually a new form is called to edit the data. But when you press and hold (Long Tap), a completely different action is performed. And these events do not intersect. In other words, Android applications can clearly distinguish between a “long press” and a “normal” one. Moreover, none of these events are triggered when the list is scrolled. A good example is the list of letters in Yandex Mail.

First of all, I want to congratulate all readers of the blog on the past holidays and wish you all the best in the coming year.

Due to understandable circumstances, I did not make a traditional New Year's report, as well as make any plans for the year. Nevertheless, life does not stand still, work is being done, and certain events in the Delphi world are taking place. I undertake to publish a selection of missed “news from the world of Delphi” during the Christmas holidays in the near future. In the meantime, I'll tell you about the new device that I purchased.

You can find the specifications on the official website. And the subjective impression is very pleasant. Noteworthy is the fact that the device is literally crammed with proprietary software from the manufacturer. Yes, and from the sellers got an impressive set of software as a gift. In operation, the smartphone is fast enough and fully justifies its cost (about $200). By the way, I bought my previous GSmart 1362 phone for about the same money 2 years ago. But, as you probably guessed, the main interest for me was how the firemonkey applications.

Before continuing the story about the timer - two news.

First, the first XE7 update has been released. By tradition, it is available to registered users. You can find a list of fixed bugs. I wanted to see how the application behaves in the updated environment. Actually, no corrections had to be made, although the field for experiments remained.

Second news. Embarcadero special offers extended until the end of the year:

Well, now directly to the topic of the post. In principle, all that remains for us is to try to run an already created application for Android. For this, we use what I wrote about in previous posts. Namely, the new one. I debugged this application on Nexus 7, accordingly added the view of Android 7″ Tablet. The design had to be “tweaked” only a little.

Probably only the lazy did not write their timer. And in the context of development support for mobile platforms, the task of writing a timer in Delphi can generally be considered a cult one. So I thought, why not as an example of development firemonkey Applications do not parse exactly the timer. Under Android, of course. Of course, this will be exactly my view of the task, which, although not particularly difficult, still has its own nuances. Perhaps you have any comments or suggestions, it would be great to discuss them in the comments. I am by no means an expert in the field of writing mobile applications, so any of your remarks will be valuable to me.

We will develop exactly the timer, in the English sense of this term. That is, the screen will display a dial and four buttons - “Start”, “Pause”, “Stop” and “Cancel”. The countdown will be forward (i.e. the time will increase). The option in which the time is set and the countdown is going on in English terminology is called Stop Watch, maybe I'll try to implement it later. The application that we will deal with is closer in functionality to a stopwatch.

Delphi XE7 allows us to greatly simplify the development process, due to the fact that now we can create and debug a real application for Win32, and then simply add form views for the necessary mobile devices and, after slightly correcting them, get a working mobile application. Sounds too good to be true? Maybe. But I also want to check this statement by realizing the task.

The more frequently I’m asked my colleagues in private conversations if it’s possible to develop mobile applications in firemonkey or is it a prototype rather than a production solution?

I think, now I can ensure even the out-and-out skeptics.

My bosom friend and colleague Tagir Yumaguzin told me about the project he took part a long time ago. Now, when this project is in pre-release state, we decided that this description will be interesting for the Delphi community. In the essence, this is a really large project implemented in FM. We are talking about Sphere Live project. A little article dedicated to that project was recently published in Habrahabr.ru Alexey Glyzin, chief of ‘ ‘ development department agreed to tell more about the project taking into consideration the audience of my blog.

A.B.– Alexey, in general, what is your project?

A.G.: – The idea has not appeared at once and instantly. Before the ‘Sphere’ project our team had been working on the project where stream audio/video technologies were implemented. Later we created our own software that was able to deliver multimedia streams to an unlimited amount of users including the feedback. But we needed to have a billing feature included.
The application had to comply with the several requirements. First, the maximally simplified organization of conferences or transmission to the participants which amount we cannot predict. Second, the most important, is to give to our clients an opportunity to earn with our application and to reduce the complexity of the system, the amount of instruments needed to use to reach the goal. The ease of organization of courses, webinar or just a consultation.

A small memory notch regarding FireDAC in the current version Delphi XE6. But first, a few words about where to look for answers to questions regarding firemonkey. Russian-speaking users are in a privileged position here.

While preparing for the Kharkiv event as part of the RAD Studio XE5 World Tour, I encountered a small problem in working with SQLite via FireDAC. If the database filled in the Windows application is transferred along with the application to Android, Cyrillic lines in the database are no longer readable (question marks are displayed instead of letters). However, if you fill in the database directly on a mobile device, Russian characters are read quite correctly. Data from a database filled in a third-party application, or in Delphi an application using other data access components also displayed normally. The rally failed to find a solution, and I had to quote a well-known Ukrainian football specialist: “We will figure it out!”

Unlike the latter, I managed to deal with the described problem. By default, when connected to SQLite v FireDAC ANSI string format is used.

If you force Unicode, then everything will work as it should. But there is also an unpleasant moment. Having changed the format of the lines, you will have to recreate the list of fields in all data sets, as well as reconnect the components responsible for displaying and entering data. Therefore, it is better to take care of the encoding right away.

In the previous parts of this mini-series, we dealt with creating a database, its structure and connecting to it from Delphi. In this part, I propose to deal with displaying data from tables, starting with the simplest case.

A simple table data editor is usually part of a complex application. To edit tables, I usually use a separate form. Let's start with the list of products. First of all, we need to create a DataSet to access the table data. In our case, it is quite possible to use the component TADTable. Let's put it in the DataModule and specify the value of the property connection. In the property editor table name a list of tables will appear, from which we select a table Products. If you did everything correctly, you can assign the property Active True value. It is better to rename the component right away (for example, ADTProduct). After that, I usually create a set of fields for the DataSet. We call the field editor (double-click on the component) and select the Add All Fields item in the context menu.

For those who do not know, I will explain the essence of this operation. Here we create a predefined set of DataSet fields. If we do not do this manually in the design mode, then, in principle, nothing terrible will happen. At RunTime, this set will be created automatically. But I still prefer to create it manually. There are several reasons for this. Firstly, it is more convenient to manage a set of fields, because we can create additional (calculated or lookUp) fields ourselves in the design mode. We can also change the properties of the fields themselves. And besides, we get the opportunity to refer to fields in the code by the name of the TField component, which, in my opinion, greatly simplifies writing code.

As in the case with the VCL application, we will connect the component to the dataset TDataSource. This component will provide the link between the dataset and the visual controls. The component's DataSet property should refer to our data set (ADTProduct). Below I give a fragment of the DFM file

object ADTProduct: TADTable IndexFieldNames = "ID" Connection = ADConnection UpdateOptions. UpdateTableName = "Product" TableName = "Product" Left = 64 Top = 192 object ADTProductID: TADAutoIncField FieldName = "ID" Origin = "ID" ProviderFlags = [pfInWhere, pfInKey] ReadOnly = True end object ADTProductTitle: TStringField FieldName = "Title" Origin = "Title" Size = 50 end object dsProduct: TDataSource DataSet = ADTProduct Left = 120 Top = 192 end

Pay attention to one curious feature, the DataModule form file is not saved in the FMX format, like a regular FireMonkey form, but in the DFM format, like in the VCL.

The next step is to create a procedure for opening a dataset, which we will need to call at RunTime when the program starts. Let's create it in the same DataModule. The procedure code is extremely simple:

procedure TDM. ConnectToDB ; begin ADConnection. open(); ADT Product. open(); end ;

The procedure call will be placed in the OnCreate event handler for the DataModule.

FireMonkey is the core technology of the "new Delphi". Please tell us about the goals, capabilities and technical aspects of this fundamentally new library. After a while, looking back, how hard and justified was your refusal to further develop the super popular VCL?

It was chosen as the main direction for the development of Delphi technology to achieve a specific goal - multi-platform development from one environment, based on a single source code base, and without the need for radical retraining of developers. Within the framework of the now classic and extremely popular VCL, this was impossible, its connection with WinAPI was too close, one might say, “at the genetic level”.

VCL components did not have an "abstract" layer between the functional level in terms of interface and their mapping mechanisms. Functional level- how it behaves as a control, what events it reacts to, what kind of user interaction it provides. Display- calling platform-oriented rendering methods as a kind of image formed by raster objects and vector primitives. FireMonkey initially implemented the principle of strictly dividing the control into two components: "behavioral" and "visual".

Vsevolod Leonov, Embarcadero Technologies

The first one as a whole will repeat not even the basics of VCL, but the essence of object-oriented programming. A component is a class, component classes form a hierarchy where families and modules can be distinguished. The class of a component has little to do with how it is rendered.

The visual "picture" is formed dynamically, it is not hardcoded in the component class. An image or "style" in FireMonkey is loaded into a component when the application starts. We have some kind of functional framework for the component, and the "skin" or "cladding" can be changed, but why? That is why FireMonkey applications look authentic on any platform - Windows 7, Windows 8, Mac OS, iOS and, in the near future, Android. The traditional monolithic VCL class structure could not provide this.

Here, the technological approach plays a special role. In principle, you can take the VCL library and “stuff” WinAPI with all other possible platform calls. On a very limited subset of components, this can still be done, but the VCL contains several hundred components, so this approach could simply "kill" the VCL. It was decided not to touch the VCL, and to develop new features on the new platform - FireMonkey. This technology even has a certain technical elegance - at the time of assembling a project for a specific platform, the Delphi IDE connects the necessary compiler, and the interface components receive a platform style.

For the user, this is one click of the mouse and the same source code, for Delphi, it is many years of hard work of developers to create such a multi-platform library.

When it became clear that FireMonkey would be introduced as a separate new platform, the right coexistence strategy had to be chosen: Embarcadero didn't want to negatively impact VCL users in any way. Therefore, we have chosen the following plan: VCL remains ideologically and architecturally stable to ensure the greatest possible compatibility, making it easier to migrate projects to modern versions. The development of FireMonkey will follow a natural and parallel path, without looking back at the VCL.

The weak point of this solution is the rather problematic migration from VCL to FireMonkey within one project. But on the other hand, for a new project, a developer can choose FireMonkey to ensure the multi-platform nature of his resulting application. With the release of XE4 with iOS support, we can already talk about Delphi's strong competitive advantage for mobile development in the corporate environment, which will be increased after the implementation of the planned support for Android.

Therefore, as such, there is no explicit "refusal" from the development of VCL. In new versions, the VCL part of Delphi is also being developed. This includes support for 64-bit, and the introduction of styling for visual components, and the implementation of a mechanism for flexible dynamic links or "binding", and the inclusion of the FireDAC library for working with databases in VCL projects. It's just that against the backdrop of a giant qualitative leap due to FireMonkey, progress in the VCL looks somewhat unmanifested. But be that as it may, VCL is an integral part of Delphi and will remain so for many years to come. Although the evolution of platforms and the current state of affairs in the field of OS for desktop systems and mobile devices are such that the future is clearly with FireMonkey.

We have already discussed iOS support in the interview, let's tell our readers about the latest RAD Studio XE4 support for other latest technologies, such as Windows 8 and WinRT, 64-bit systems, MacOS and so on. Can you list what else you can offer to a modern programmer spoiled by innovations?

Most likely, the modern programmer is not "spoiled" by innovations. For large projects, any "innovation" often turns into a gigantic amount of work.

For example, everyone waited a long time, many immediately rushed to transfer their codes to a new platform. But it turns out that even very professional teams are not ready for this. Compilable 64-bit code does not mean workable. "Sins of youth" began to emerge, such as using instructions assuming a 4-byte address size. The lack of a culture of conducting tests, coupled with the technological unwillingness to implement this process in a short time.

And here - the larger the project, measured, for example, by the number of lines of source code, the more carefully and balanced programmers treat various kinds of innovations ranging from the appearance of a "button" in the interface to "syntactic sugar" in the compiler.

One of these “problematic” achievements was the release of Windows 8. Personally, as a PC user and just a modern IT specialist, I am delighted with Windows 8. But for developers who were sent a batch of Windows 8 computers with technical specifications for development under the new OS as a load, this means certain difficulties.

We tried to provide support for development under the new interface of this OS as comfortably and painlessly as possible. Therefore, special styles have been introduced for both VCL and FireMonkey, and the programmer can either rebuild the application interface or create a new application that will be indistinguishable from the “native” one for Windows 8 in appearance. Of course, there is a need for "native" support for Windows 8 through WinRT. But here the prioritization of goals in modern conditions affects. Mac OS, iOS, Android in the near future do not yet give the opportunity to talk about the full support of WinRT in the near future.

The strategic goal of Embarcadero is, of course, multi-platform. The release of RAD Studio XE4 was a key one, primarily because of iOS support. An active programmer using the VCL can start developing for iOS in a matter of hours. Even a simple mobile application can be instantly transformed into a powerful project that works within the existing infrastructure. Don't think it's just a new compiler for FireMonkey and a new style to match the iOS interface.

This includes a new visual designer, built-in support for various form factors, and data access libraries, including the new FireDAC, and LiveBindings technology for flexible and dynamic binding to corporate data. All these innovations are coming simultaneously - for Windows, and for Mac OS, and for iOS. The Mac OS operating system is not developing so rapidly, so there are no such problems as the transition from Windows 7 to Windows 8. But Retina displays appeared, and this required special attention. Now any MacOS application created in Delphi XE4 automatically includes two styles - "normal" and "high-definition".

That. the same application can have the same quality "native" interface on any desktop computer from Apple.

Embarcadero does not want to "surprise", "amaze" or even "entertain" developers with its new innovative releases. Rather, on the contrary, the IT sphere is already full of various surprises: new devices, new platforms, new users, their new needs, new interaction scenarios. Add new software development technologies to this, and programmers will simply not have time to create new systems and on existing ones - they will only do what to migrate from one environment to another, from an old library to a new one, from one language to another.

But we do not confess the rejection of everything new. We just want to ensure the continuity of everything - the code, the interface, the project, even professional skills as new platforms and devices appear. We can say that we are fighting an unhealthy conservatism in relation to new platforms at the expense of a healthy conservatism in development tools. Don't expect exotic products, non-standard programming languages ​​and outlandish development tools from Embarcadero.

With us you will always find visual development, classical languages, "native" code, and let the target platforms for your applications created in the same proven classical way be new.