More than three years have passed since the CodeGear division, which is responsible for the creation of such world famous tools as Delphi, C ++ Builder and JBuilder, as well as the Interbase DBMS, became part of Embarcadero Technologies, known for its tools for design and administration of databases. , 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 of Development Relations and Chief Evangelist of Embarcadero Technologies, and Kirill Rannev, Head of Representative Office of Embarcadero Technologies in Russia. For our youngest readers, we would like to inform you that this is not 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 the products of the Embarcadero company.
ComputerPress: David, your division has been part of Embarcadero for three years now. Two years ago, you were full of enthusiasm that it became part of a company that is close to you in purpose and spirit. Has anything changed during this time? Do you and your colleagues have the same enthusiasm?
Yes, I am still enthusiastic. The major change since we became part of Embarcadero is that there has been a lot of investment in 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 a former innovative product that connected 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 the same code.
The new development platform - FireMonkey - is a collaboration between Embarcadero and the recently acquired Russian firm KSDev from UlanUde, a manufacturer of vector graphics, DirectX and OpenGL, graphics effects technologies and Delphi components using a GPU with PixelShader 2.0. We acquired the KSDev company (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 a user interface for applications, integrating with databases , graphics processing using the GPU and integration with the operating system.
With FireMonkey, you can create an application that runs the CPU and GPU together, and then you can use different compilers and Run-time Libraries (RTLs) to compile it for Windows, Mac OS, or iOS. Instead of learning programming using different graphics libraries, learning APIs of different platforms with different coordinate systems and different capabilities, developers using Delphi and C ++ Builder can use the same component-based approach by visually editing forms and connecting to databases by moving the component with the mouse. This is a fundamentally new way of building applications that run on different platforms, and the future belongs to it. If you want to add support for other operating systems and platforms to your application, you don't need to redesign and develop it - you just need to recompile it.
We are creating new compilers that generate native code. Today there are Delphi compilers for 32-bit and 64-bit Windows, 32-bit Mac OS 10. And we are working on the next generation Delphi and C ++ Builder compilers that will allow you to create high-performance machine code for both the listed and others. platforms such as Android or Linux, and maintain the same design, the same components, the same code through the use of different compilers and runtime libraries.
As you can see, I have enough reasons for enthusiasm. And the developers I meet all over the world know that Embarcadero is investing heavily in Delphi and C ++ Builder as well as PHP development tools.
KP: What progress have you been able to achieve in integrating the tools of the two companies over the past two years? What are Embarcadero's future plans in this area?
DI.: 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 and DBA tools, CodeGear had application development tools, but the latter also use databases. A merger of companies is a combination of expertise, knowledge in the field of databases, code optimization, including server code. The merger also led to the creation of a new product, AppWave, a special technology for turning a regular Windows application into something very easy to use (like applications for the iPhone or other devices). AppWave allows you not to install an application, but simply select it and run it from the prepared application storage server (app), while it will run on the user's computer without making changes to its registry and system area of the file system. By the way, the AppWave application browser is written in Delphi. Embarcadero uses Dephi for in-house development and our application development expertise.
IPhone (iOS) app 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 the SQL directly to DB Optimizer, you can profile it, test it, and put it back into the development environment with its optimized version. Embarcadero's database expertise has also improved DataSnap technology. Thanks to the developers in Toronto, we have gained a lot of knowledge about the architecture of multi-tier systems and databases. We now have joint expertise in server-side code and stored procedure writing at both companies. We have tools like RapidSQL and DB Change Manager, as well as IDEs that make it easy to create server-side code - for example, Code Insight and Code Completion technologies enable SQL insight and SQL Completion technologies. Our common approaches to creating client and server code, our common philosophy, allow us to give common features to 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 supply 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 Development Environment, DB Change Manager, and DB Optimizer, to perform an important part of the development and deployment process by managing changes to the data model, database, code, and more. This is a very good and right combination of technologies.
DI.: However, if needed, developers can use Subversion for source code versioning and DB Change Manager for metadata versioning. You can use code profiling and DB Optimizer to optimize server-side code, RapidSQL to build and debug server-side code, and our IDEs to build and debug applications. This combination of technologies in RAD Studio XE Ultimate Edition demonstrates the parallels between the database and application development models. Most developers building business applications using 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 must start targeting different platforms without significantly increasing their investment in training - that is, they need universal tools. Obviously, it is unrealistic to expect the emergence of universal tools from platform manufacturers, and in this matter we can rely only on independent tool manufacturers. Where can we count on Embarcadero?
DI.: We still have a lot to do in the area of platform support. Today we provide support for the iOS platform for iPhone and iPAD, then smartphones based on the Android platform, Windows 7 and Blackberry will receive our support. In RAD Studio XE 2, we started by building the FireMonkey platform for iOS and then porting FireMonkey to other platforms.
At the same time, there are a large number of operating systems that support touch screens for phones, tablets and devices, desktops, 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 the 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 as well. And we already have examples in which we use motion to control an application in much the same way that a mouse or keyboard is usually used.
When you create applications with a lot of complex graphics, you are generating a whole world of new user interfaces. If we are dealing with a Windows operating system, we encapsulate its Windows API in a VCL (Visual Component Library, which is part of the Delphi and C ++ Builder development tools. - Approx. ed.), which, by the way, can be used further. And in FireMonkey, we encapsulate the operating system API. But today we manipulate shapes and graphics much more widely. You can also add physical properties of the space for animation and special effects. In addition, there are a ton of other additional user experience options that we are looking to implement over the next few years across multiple platforms, mobile and tablet devices.
Microsoft recently released details on Windows 8 due out in a year. We will support these innovations in the VCL 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 build PHP server applications using wizards and tools to generate client-side JavaScript and HTML codes and cascading style sheets. We can create packages from PHP apps and native iPhone iOS client apps, 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 the business.
Development environment RadPHP XE2. Building 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 in the area of support for mobile platforms.
KP: Could you elaborate more on the FireMonkey platform?
DI.: As I noted, the VCL built for Windows will continue to evolve and improve. But today, if you want to actually develop business applications, you have to create them for different platforms. This is what the FireMonkey platform is for. It supports the creation of user interfaces with high resolution, high-performance 3D graphics, high frame rate and, importantly, uses a GPU for this.
You can use these capabilities when creating scientific, engineering and business applications. Such applications can connect to databases using dbExpress technology, while 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, buttons with boxes, fancy tables, and other interface elements, both in 2D and 3D. You can load a ready-made 3D model into the application and connect it to a 2D shape in which it can be rotated and viewed from different angles. You can create a data cube or a 3D business diagram and rotate it using a mouse, keyboard, or even a Kinect device, or you can go inside a cube and look at different surfaces from the inside. And all of this can be done with a GPU at high speed. Then the same application can 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 and light and rotate parts of the user interface. The form designer has a built-in environment to support the 3D user interface directly during development.
On Windows, you can use Direct2D libraries for high-resolution 2D graphics, and Direct3D for 3D graphics. On Mac OS, the Quartz and OpenGL libraries are used for the same purposes. 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 API, 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 deal with resources, menus, dialog boxes, colors, styles, Windows messages. Unlike VCL, a multi-platform "wrapper", 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 platform also comes with a complete animation system for UI elements. It is certainly not a comprehensive animation system like Pixar, but it does allow for effects such as animating bitmaps, highlighting UI element focus, 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, which are now found in almost any computer. The application, built using the FireMonkey platform, sends commands to the GPU, which does all the work of displaying graphics and creating the user interface. In this case, the central processor is free for calculations and calls to the operating system. The developer only has to correctly place the components.
The most fundamental thing about the FireMonkey platform is the way in which it builds the user interface. There are facilities for placing bitmap graphics on interface elements such as menus, buttons, and scroll bars. At FireMonkey, we use vector graphics using the GPU for this purpose. From a programming standpoint, these are all the same controls, but the graphics processor does all the work to display them. 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, the VCL had a limited number of container controls (that is, allowing you to place other items in them), and in FireMonkey, each control is a container. This means that each control can contain any other control. For example, inside the dropdown list items there can be images, buttons, edit fields and other controls. And you can also arrange components in layers.
The FireMonkey rendering system is flexible enough - it can use Direct2D, Direct3D and OpenGL libraries by sending commands to the GPU. To achieve the same in the VCL, it was necessary to generate a separate buffer outside the screen, create an image in it, 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 the 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, and of any type. It can be just an expression, a field from a dataset, data from developer-generated objects, or the results of a method call.
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 logistics applications. 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 the automatic forklift moving through the warehouse and placing the goods on the shelves. And they put the data from the sources onto 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 (open source 3D modeling tool. - Approx. ed.), Maya, OBJ format, which is supported by many 3D graphics vendors.
KP: What other formats are you planning to add?
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. Perhaps we will support other formats as well.
KP: Does the use of 3D models in applications built with FireMonkey require a license for the corresponding 3D modeling tool?
DI.: No, it doesn't. All we do is read the model file. We import the model, but we don't export it (although of course you can write an application that will save the model in your own format). We do not pretend 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 pretty good. For example, a 3D shape with three spheres and three lights can be rendered on a MacBook Pro at 100 frames per second. 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 FireMonkey can be used to create games that are up-to-date?
DI.: We do not position our development tools as a tool for games. Nevertheless, using the high performance of modern graphics processors, you can create games with FireMonkey - after all, they create them using Direct3D or OpenGL.
KP: What kind of work are you doing now in the area of supporting gesture recognition and other newfangled things? Is this support available?
DI.: We don't have gesture support for 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 FireMonkey technology has Russian roots - its foundations were created in our country, and then the technology itself and its developers joined Embarcadero. In general, it is gratifying to see the growth of the Russian component as part of RAD Studio and Delphi. This is both the activity of our development center in St. Petersburg and the contribution of independent Russian developers. For example, the FastReport report generator, known all over the world and very popular in our country, has become part of Rad Studio XE2. He is from Rostov-on-Don.
KP: I would like to talk about compilers. What kind of compiler is used to create iOS apps?
DI.: For the iPhone or iPad, we do not have our own Delphi compiler - we have not yet developed compilers for the ARM processors used in these devices. For iOS, we are temporarily using the Free Pascal compiler and runtime library. But we are working on the next generation of compilers, including for APM processors. But for Windows and Mac OS there are compilers, 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 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 that are compatible with the latest C ++ language standard just adopted by the ISO.
KP: What is happening with cloud computing support in Embarcadero development tools today?
DI.: In RAD Studio XE 2, we support migrating applications to the cloud in Microsoft Azure or Amazon EC2 using 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 release 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.: All-Access solution and AppWave cloud tool are widely used in the world. They are designed to simplify the use of applications from both our company and other manufacturers. In fact, it is a solution for managing licenses and application applications, and it is convenient for large companies. Smaller firms, on the other hand, that do not have a dedicated team of people responsible for managing applications, can put an application in a repository, select usernames from a database, and ensure that those applications are used 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 the users are so diverse that it is impossible to cover all needs with one solution. Therefore, we strive for a variety of "packaging" solutions. We've done a great job of unifying the licensing, license management, and product installation methods. This line of solutions includes license management and granting tools not only for Embarcadero products, but also for any other product, including internal development of companies.
Work on bundling development tools into effective kits for users is still ongoing. We have All-Access, a superset that brings together all Embarcadero products. If the customer purchases the All-Access Platinum version, he receives all the tools that Embarcadero has. But sometimes this set turns out to be redundant, for example, for database specialists, we made two other sets - DB Power Studio Developer Edition and DB Power Studio DBA Edition. The difference between them is that for the developer we offer RapidSQL - a server code development tool, and for the administrator, DBArtizan is built in there - a database administration tool, a broader product than RapidSQL. For professionals, we have the following All-Access Kits: All Products, DB Power Studio for Developers, DB Power Studio for Administrators, ER Studio Enterprise Edition for Architects and anyone else involved in modeling. There are combinations for application development and for administrators. Delphi is a developer tool, and it makes sense to add SQL development and optimization tools to it. Finally, DB Change Manager is a logical tool for managing the complexity of those changes that occur to databases during their life cycle.
Thus, All-Access is the head of a large family of different product suites.
KP: If it's not a secret, who uses All-Access in Russia?
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 release, and they switched from Delphi to All-Access a year ago. Two tools that are guaranteed to be used by all developers at this company are Delphi and DBArtisan. And there are customers who came to All-Access from the database side. Their main job is to administer databases, but they sometimes do application development. All-Access customers include media companies, engineering companies, and other industries.
I would also like to dwell on small companies. Very often in small teams, a developer does everything, and such a company sometimes buys large All-Access grocery kits for one or two developers. In large teams, it is discouraged for a developer to perform, for example, also the role of a database administrator, so usually small product sets are popular there, and in small companies such a combination of duties is quite acceptable.
Delphi Architect is a heavily marketed product that includes modeling and programming tools. The number of copies sold is, however, less than the Delphi Enterprise version, but it is also large. I would like to note that in 2010 we turned out to be the best country in terms of sales, despite the fact that all countries went through 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 sales growth.
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 it is legalized, because previously the software was not so actively bought. Starting with the RAD Studio XE version, the license covers versions 2010, 2009, 2007 and even Delphi 7 - a widespread 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. Nobody is translating them to newer versions, but they are maintained in a viable state. 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 rate the current state of the Embarcadero community?
DI.: This community is large and very demanding. They need everything immediately - they are the 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 into Linux desktops. Now we see that this 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 device access. Different platforms may have different flow control or exception handling models, but we see the same try blocks in the application code. Our job is to make it easier 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 support for it in FireMonkey, will it be possible?
DI.: With next-generation compilers that have a platform-independent front-end and a platform-specific back-end, this is entirely possible. In the meantime, for each operating system, we create a compiler and run-time library from scratch.
Any modern new device usually has a graphical user interface (many have a dual-core processor and GPU) and standard developer SDKs. This all makes it easy to create device support in FireMonkey. If the new device will only have libraries for two-dimensional graphics such as Quartz, we will be able to provide support in FireMonkey for such a device, 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 dialog boxes, and you cannot put the corresponding components on the forms of such applications.
KP: Has anything changed in the partner policy? What is being done to increase the share of users of your products? What is happening in Russia?
DI.: Our partner ecosystem is wide - there are hundreds of tool and component manufacturers that are not in our products, and we have a technology partnership program. Therefore, developers have access to a wide range of components, technologies and tools. And the solutions they create for their customers turn out to be better than if only our products were used. And for sales, we have offices in many countries, resellers and distributors.
K.R .: It is not the number of partners that is important to us, but the quality of work of each specific 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 seriously invested in Embarcadero as a business line - they have trained specialists, marketing 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 selling 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. Let me, on behalf of our publication and our readers, wish your company continued success in creating your amazing tools that developers need so much!
Questions were asked by Natalia Elmanova
FireMonkey is the core technology of the "new Delphi". Please tell us about the goals, capabilities and technical aspects of the device of this fundamentally new library. With the passage of time, in hindsight, how difficult and justified was your refusal to further develop the hugely popular VCL?
It was chosen as the main direction of 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 cardinal retraining of developers. Within the framework of the now classic and super 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 layer in terms of the interface and the mechanisms for their display. Functional level- how it behaves as a control, what events it reacts to, what kind of user interaction it provides. Display- Calling platform-oriented visualization methods as a kind of image formed by raster objects and vector primitives. FireMonkey initially implemented the principle of strict separation of the control into two components: "behavioral" and "visual".
Vsevolod Leonov, Embarcadero Technologies
The first will generally 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 generated dynamically, it is not hardcoded in the component class. The image or "style" in FireMonkey is loaded into the component when the application starts. We have some functional skeleton for a component, and the "skin" or "cladding" can be changed, but why? Precisely so that FireMonkey applications look authentic on any platform - Windows 7, Windows 8, Mac OS, iOS and, in the near future, Android. The traditional monolithic class structure of the VCL could not provide this.
The technological effectiveness of the approach plays a special role here. Basically, you can take the VCL library and stuff WinAPI and all the other possible platform calls. This can still be done on a very limited subset of components, but the VCL contains several hundred components, so this approach could just kill the VCL. It was decided not to touch VCL, but to develop new opportunities on a new platform - FireMonkey. This technology even has a certain technical sophistication - at the time of building a project for a specific platform, the Delphi IDE connects the required compiler, and the interface components get the platform style.
For the user, this is one click and the same source code, for Delphi, it is a long-term 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, it was necessary to choose the right coexistence strategy: Embarcadero did not want to negatively impact VCL users in any way. Therefore, we chose the following plan: VCL remains ideologically and architecturally stable to ensure the highest possible compatibility, facilitating the migration of 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 functionality of their resulting application. After the release of XE4 with iOS support, we can already talk about the bright competitive advantages of Delphi for starting mobile development in an enterprise environment, which will be increased after the implementation of the planned Android support.
Therefore, as such, there is no explicit "rejection" of the development of the VCL. The VCL part of Delphi also evolves in newer versions. This includes 64-bit support, and the introduction of styling for visual components, and the implementation of the mechanism of flexible dynamic links or "binding", and the inclusion of the FireDAC library for working with databases in VCL projects. Just against the background of a giant qualitative leap due to FireMonkey, progress in the VCL looks somewhat undeveloped. But, be that as it may, VCL is an integral part of Delphi and will remain so for many years to come. While platform evolution and the current state of the art in desktop and mobile OS are such that the future is clearly with FireMonkey.
In the interview, we have already discussed iOS support, let's tell our readers about the support for other latest technologies from the latest RAD Studio XE4, such as Windows 8 and WinRT, 64-bit systems, macOS and so on. Can I list what else you can offer a modern programmer spoiled by innovations?
Most likely, a 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 the new platform. But it turns out that even very professional teams are not ready for this. Compiled 64-bit code does not mean workable. The "sins of youth" began to emerge, for example, the use of instructions on the assumption of a 4-byte address size. Lack of culture of conducting tests, coupled with technological unavailability 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 are about various innovations ranging from the appearance of the "button" in the interface to "syntactic sugar" in the compiler.
One of such “problematic” achievements was the release of Windows 8. Personally, as a PC user and just a modern IT specialist, Windows 8 is a delight. But for developers who were sent a batch of computers running Windows 8 with a technical specification for development for a new OS in the load, this means certain difficulties.
We tried to provide as comfortable and painless as possible support for development for the new interface of this OS. Therefore, special styles have been introduced for both VCL and FireMonkey, and the programmer can either rebuild the application interface, or re-create the application, which will be indistinguishable from the "native" Windows 8 in appearance. Of course, there is a need for "native" support for Windows 8 through WinRT. But this is where the prioritization of goals is affected in modern conditions. Mac OS, iOS, Android in the near future do not yet give the opportunity to talk about full support for WinRT in the near future.
Embarcadero's strategic goal is, of course, to be multi-platform. The release of RAD Studio XE4 was a key one, primarily due to support for iOS. 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 that this is just a new compiler for FireMonkey and a new style to match the iOS interface.
It 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 come in sync - both 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 high-quality "native" interface on any Apple desktop computer.
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 simply will not have time to create new systems on existing ones - they will only do what to migrate from one environment to another, from the old library to a new one, from one language to another.
But we do not profess to reject everything new. We just want to ensure the continuity of everything - code, interface, project, even professional skills when new platforms and devices appear. We can say that we are fighting an unhealthy conservatism about 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, classic languages, "native" code, and let the new target platforms be for your applications, created in the same proven classic way.
03/06/2013 12:46 pm
I suffered a lot due to the lack of a browser component in FireMonkey. The well-known project Delphi Chromium Embedded did include FMX support in the latest build. But despite the fact that quite a long time has passed, the author is in no hurry to add support for FMX2. As a result, I had to take the situation into my own hands.
The TChromiumFMX component from the official assembly works quite well in FireMonkey (in XE2), but it doesn't even compile in FMX2. I had to figure out a little about how it works and fix it. Fortunately, no major changes were required.
In FMX2, two things that the component needs have changed.
First, TBitmap no longer has ScanLine and StartLine properties. Direct access to the contents of TBitmap has been redesigned (I wonder why?) And now it is available through the TBitmapData class, which returns the TBitmap.Map method.
Well, the second, more famous - Platform. * Is no longer there, now you need to get the desired interface through TPlatformServices.GetPlatformService. Everything is pretty straightforward here and there are no problems.
I did not test it especially inventively, but for my purposes the component is quite suitable - you can view sites through it. Download it. Also, I will probably send my edits to the author, it may be necessary to add them to the official version.
07/30/2012 2:43 am
Jason Southwell proposes to develop a set of FireMonkey wrappers for native Windows / OSX controls and is raising money for this. He plans to collect 20 thousand dollars for a start.
The idea is clear. Existing FireMonkey components are rendered using Delphi almost from scratch, which, on the one hand, largely ensures their cross-platform functionality, but on the other hand, as a result, we get components that do not look quite natural in both currently supported operating systems. And this is half the trouble - in addition to the appearance, you have to independently develop the logic of these components. For example, RichEdit is rather complicated; it is not a trivial task to repeat its logic within FireMonkey on your own. Both the VCL and CLX did not reinvent the wheel; they used a ready-made one.
Now for the bad news. Everything works at runtime, but I haven't found any way to add my new tab type to the Items Designer. And it looks like all list controls have the same problem: TListBox, TGrid, etc. At first I really liked the approach to their implementation, but now I even somehow doubt it. A search on the Internet showed that I am not alone with this problem.
The help is silent, I didn't find anything in the code either. Really? It would be extremely unpleasant.
What is FireMonkey?
FireMonkey (FMX) is a framework for cross-platform development both for desktop systems (Windows, Mac OS + in the near future, it is planned to support the server side on Linux) and mobile (iOS and Android) using the Delphi / C ++ language.
Peculiarities:
a single codebase for all platforms;
any control (visual component) can be a container (parent) for other components;
the presence of a very advanced relative position (20 types) of components on the form;
LiveBinding allows you to connect any type of data or information to any user interface or graphical object;
the presence of the styles of the form / components;
Multi-Device Preview allows you to customize the visual presentation for each platform;
FireUI Live Preview - displaying the view of the application on real devices in real time.
Possibilities:
using the native API of each platform, as well as the ability to call third-party native libraries;
interaction with all sensors (GPS, Accelerometer, Compass, Bluetooth (including LE) and others);
support for push notifications, IoT;
support for asynchronous HTTP requests;
support for most databases (MsSQL, MySql, Oracle, PostgreSQL, MongoDB, etc.);
work with Cloud Service (Amazon, Azure);
support for Android Service.
Cons (currently):
lack of support for customizing native classes;
the implementation of specific things is either impossible (widgets, extensions (iOS), etc.) or a dance with a tambourine is necessary (background service, broadcast message, etc.);
customization of the Splash screen (initial screen), to put it mildly, no;
FMX controls use their own rendering (visualization, drawing), which is visually similar to the native one;
using native controls is associated with large body movements;
with a lot of nesting of components, incredible things happen: the application crashes in various places, it loses focus, freezes, etc.;
information content of application debugging on mobile platforms is zero;
descriptions of errors on mobile platforms are reduced to useless “Error 0x00000X”;
compilation time wants to be the best for medium to large projects;
the need to use a file to fine-tune mobile applications for each platform;
no support for Intel Atom architecture;
inadequate price compared to competitors.
Pros:
very active development of both the product and the community recently, support for more and more new technologies;
the presence of a huge number of free and commercial components;
the speed of the application is very close to the native one;
a very advanced visual editor and the environment in general, the presence of styles;
the ability to test an application on Win, and only then deploy it on devices, which greatly speeds up development;
changing the mode / platform with a slight movement of the hand;
PAServer provides easy interaction with MacOs when developing for Apple OS;
support for 3D graphics out of the box.
In conclusion, I want to say that FireMonkey has grown over the past couple of years into a professional tool for cross-platform development of business applications and not only. Many shortcomings are gradually being resolved and with each release the product becomes more and more modern and self-sufficient, the existing skepticism towards the Delphi language itself, associated with many years of stagnation, also disappears. Writing new projects with FireMonkey is “safe” and forward-looking.
Enough time has passed since the term FireMonkey became more or less familiar, if not for all developers, then at least those who use Delphi. During this time, books on FireMonkey appeared, articles on FireMonkey, entries about FireMonkey in numerous blogs. All this is very interesting to read. But no theory can replace practice. And I, like many before, had an itch to try to write something using FireMonkey.
In doing so, however, a problem arose. For some reason, I decided that I just needed to implement some not very complex working project.
To explain why this turned out to be a problem for me, it will take some (I really want to write, lyrical) digression. An excursion into my past as a developer. Explain some of my views on programming with 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 learning VCL. Studied in the original, so to speak. I watched, addressed, traced the sources. 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 quality control before being included. Some of these components continue to ship today. 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: no set has been so deeply thought out and so well implemented as a huge and diverse VCL. No, I do not pretend to be the ultimate truth, and, of course, in the VCL itself there are many errors, solutions that cause misunderstanding, cause rejection and with which you want to disagree. But I always got the impression of a certain uniform style. There is, in my opinion, a beautiful and solid core in the VCL that supports the entire Delphi design, and around which the software infrastructure and the developer community itself are built. It is thanks in large part to the VCL that, again, in my opinion, rumors of Delphi's death are still rumors to this day. And when third-party components were included in the VCL delivery, 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 to 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 anytime. And I hear it from various sources. And quite persistently. No, no one kills the VCL. he stays with us. But he's not number one now. He has to become a stunt double. At least that's how I understand what is being said about the future of the product.
In principle, I understand this alignment. The course is set for multi-platform and, more importantly, for cross-platform. After all, what is VCL? Visual Component Library. Library of visual components. One can disagree 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, extension of the VCL. Well, I can't consider the successors of TDataset as 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 quite separate, but, nevertheless. And if we accept this point of view, FireMonkey is intended to replace the visual part of the VCL (what should I call the complete library of classes and components, 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 descriptors, fonts, windows themselves, input elements, messages, device contexts and much more - these are not concepts of a library supplied with Delphi, but concepts of an operating system. Yes, exactly, Windows. And if you want to build a cross-platform library, then it is logical to abandon the infrastructure offered by the operating system that executes a 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 in various operating systems, capable of replacing the service offered by the operating systems themselves.
Many people remember trying to makecross-platform not only the library, but also Delphi itself... In parallel with 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 lacks many of the basic GUI concepts that Windows does. The windowed interface for Linux is not a native phenomenon at all. This application is optional. 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 of not disappointment, no, rather, annoying inconvenience that I experienced when I tried to use the analogs of the visual components from CLX. I began to miss a lot. What I used to do without thinking when developing using the VCL turned out to be difficult, completely different, or simply impossible, using the CLX.
I felt about the same when switching from BDE to DBExpress. Old, familiar with the Field Test BDE (Borland then already used it in Quattro Pro for Windows and 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. All the time I was 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 solutions that led to their appearance. It is only about my impressions, sometimes, first impressions.
Now, it probably becomes a little clearer why the decision to write a small working project using FireMonkey brought a number of problems. Over the course of many years, during the development of projections, 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 needed to be changed. Because you cannot transfer everything that you are used to using VCL into a project built on FireMonkey.
At the start of the project, I experienced a certain sense of déjà 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 associated with knowledge of some peculiarities of the operating system, do not pass in the new context. Not to mention, some of the components have changed radically.
Well, and another important nuance. What kind of projects do you usually have to do at work, if it (work) is not related to writing compilers, modeling systems or something else highly scientific? I think that for most of them this is developing something related to 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 a database, you find yourself not quite ready for this (to put it mildly). Although I have already read about this many times and you know (theoretically) what to use. It's about Live Bindings.
I do not want to get involved in a dispute about whether real cool programmers should use db-aware components or not. In practice, starting a new project, I was faced with the fact: I have to get used to both new visual components and a new way of extracting data for display, edit and ultimately save. Which, again, is neither bad nor good. It just happened that way for me.
This concludes the post about first impressions. Next in line are the stories about what and how was overcome while working on the project.
