Firemonkey du simple au complexe. FireMonkey. Début. Fond. Impressions. pas de prise en charge de l'architecture Intel Atom

Plus de trois ans se sont écoulés depuis que la division CodeGear, qui est responsable de la création d'outils de renommée mondiale tels que Delphi, C ++ Builder et JBuilder, ainsi que le SGBD Interbase, fait partie d'Embarcadero Technologies, connu pour ses outils de conception et administration de bases de données. , et deux ans que nous discutions dans les pages de notre magazine de ce à quoi s'attendre dans le développement d'outils si populaires parmi les développeurs russes. Nous avons interrogé David Intersimone, vice-président des relations de développement et évangéliste en chef d'Embarcadero Technologies, et Kirill Rannev, directeur du bureau de représentation d'Embarcadero Technologies en Russie. Pour nos plus jeunes lecteurs, nous tenons à vous informer que ce n'est pas la première interview que David et Kirill accordent à ComputerPress - notre coopération dure depuis la deuxième décennie. Et pendant à peu près le même nombre d'années, nous publions périodiquement des revues d'outils de gestion de bases de données, dans lesquelles une grande attention est accordée aux produits de la société Embarcadero.

Presse informatique : David, votre division fait partie d'Embarcadero depuis trois ans maintenant. Il y a deux ans, vous étiez très enthousiaste à l'idée de faire partie d'une entreprise qui vous est proche dans sa raison d'être et son esprit. Quelque chose a-t-il changé pendant cette période ? Vous et vos collègues avez le même enthousiasme ?

Oui, je suis toujours enthousiaste. Le changement majeur depuis que nous faisons partie d'Embarcadero est qu'il y a eu beaucoup d'investissements dans Delphi. Le nombre d'employés travaillant sur des outils de développement a augmenté, le nombre de technologies que nous pouvons développer ou, si nécessaire, acquérir, a augmenté.

La version de RAD Studio XE 2, que nous prévoyons de présenter à Moscou, est la plus grande version de ce produit avec d'énormes capacités et un grand nombre de plates-formes prises en charge depuis la première version de Delphi, créée pour Windows 16 bits et une ancienne version innovante produit qui connecte l'approche des composants et la compilation au code machine. Nous prenons désormais en charge le développement non seulement pour Windows, mais aussi pour Macintosh, sans parler du développement Web et de la création d'applications pour appareils mobiles, et ces applications pour différentes plates-formes peuvent avoir le même code.

La nouvelle plate-forme de développement - FireMonkey - est une collaboration entre Embarcadero et la société russe récemment acquise KSDev d'UlanUde, un fabricant de graphiques vectoriels, DirectX et OpenGL, de technologies d'effets graphiques et de composants Delphi utilisant un GPU avec PixelShader 2.0. Nous avons acquis la société KSDev (voir ksdev.ru) il y a un an et avons commencé à travailler ensemble pour créer un outil de développement multi-plateforme qui comprend une plate-forme pour développer des applications FireMonkey avec des composants pour Delphi et C ++ Buider pour créer une interface utilisateur pour les applications , intégration aux bases de données , traitement graphique à l'aide du GPU et intégration au système d'exploitation.

Avec FireMonkey, vous pouvez créer une application qui exécute le CPU et le GPU ensemble, puis vous pouvez utiliser différents compilateurs et bibliothèques d'exécution (RTL) pour la compiler pour Windows, Mac OS ou iOS. Au lieu d'apprendre la programmation à l'aide de différentes bibliothèques graphiques, d'apprendre les API de différentes plates-formes avec différents systèmes de coordonnées et différentes capacités, les développeurs utilisant Delphi et C ++ Builder peuvent utiliser la même approche basée sur les composants en éditant visuellement les formulaires et en se connectant aux bases de données en déplaçant le composant avec la souris. Il s'agit d'une façon fondamentalement nouvelle de créer des applications qui s'exécutent sur différentes plates-formes, et l'avenir lui appartient. Si vous souhaitez ajouter la prise en charge d'autres systèmes d'exploitation et plates-formes à votre application, vous n'avez pas besoin de la reconcevoir et de la développer - il vous suffit de la recompiler.

Nous créons de nouveaux compilateurs qui génèrent du code natif. Aujourd'hui, il existe des compilateurs Delphi pour Windows 32 bits et 64 bits, Mac OS 10 32 bits. Et nous travaillons sur les compilateurs Delphi et C++ Builder de nouvelle génération qui vous permettront de créer du code machine hautes performances pour les deux. les plates-formes répertoriées et autres telles qu'Android ou Linux, et conservent la même conception, les mêmes composants, le même code grâce à l'utilisation de différents compilateurs et bibliothèques d'exécution.

Comme vous pouvez le voir, j'ai suffisamment de raisons d'être enthousiaste. Et les développeurs que je rencontre partout dans le monde savent qu'Embarcadero investit massivement dans Delphi et C++ Builder ainsi que dans les outils de développement PHP.

KP : Quels progrès avez-vous pu réaliser dans l'intégration des outils des deux sociétés au cours des deux dernières années ? Quels sont les futurs projets d'Embarcadero dans ce domaine ?

DI. : Lorsque la division CodeGear a rejoint Embarcadero, cette société avait des équipes de développement à Toronto, Monterrey et en Roumanie, nous étions et sommes toujours à Scotts Valley et en Russie, à Saint-Pétersbourg. Embarcadero disposait d'outils de développement et de DBA, CodeGear disposait d'outils de développement d'applications, mais ces derniers utilisent également des bases de données. Une fusion d'entreprises est une combinaison d'expertises, de connaissances dans le domaine des bases de données, de l'optimisation de code, notamment de code serveur. La fusion a également conduit à la création d'un nouveau produit, AppWave, une technologie spéciale pour transformer une application Windows ordinaire en quelque chose de très facile à utiliser (comme des applications pour l'iPhone ou d'autres appareils). AppWave vous permet de ne pas installer une application, mais simplement de la sélectionner et de l'exécuter à partir du serveur de stockage d'applications préparé (application), tandis qu'elle s'exécutera sur l'ordinateur de l'utilisateur sans apporter de modifications à son registre et à la zone système du système de fichiers. Soit dit en passant, le navigateur d'applications AppWave est écrit en Delphi. Embarcadero utilise Dephi pour le développement interne et notre expertise en développement d'applications.

Application iPhone (iOS) créée par
en utilisant la plate-forme FireMonkey

Vous pouvez également utiliser l'intégration de nos outils de développement et de DB Optimizer pour optimiser les requêtes SQL lors de la création d'applications. En passant le SQL directement à DB Optimizer, vous pouvez le profiler, le tester et le remettre dans l'environnement de développement avec sa version optimisée. L'expertise d'Embarcadero en matière de bases de données a également amélioré la technologie DataSnap. Grâce aux développeurs de Toronto, nous avons acquis beaucoup de connaissances sur l'architecture des systèmes et des bases de données multi-niveaux. Nous avons maintenant une expertise commune en écriture de code côté serveur et de procédure stockée dans les deux sociétés. Nous avons des outils tels que RapidSQL et DB Change Manager, ainsi que des IDE qui facilitent la création de code côté serveur - par exemple, les technologies Code Insight et Code Completion activent les technologies SQL Insight et SQL Completion. Nos approches communes de création de code client et serveur, notre philosophie commune, nous permettent de donner des fonctionnalités communes aux outils de gestion de bases de données et aux outils de développement d'applications.

Kirill Rannev : Je veux ajouter quelque chose d'important. D'un point de vue commercial, la manière dont nous fournissons nos outils est très importante. Par exemple, la nouvelle version de RAD Studio XE 2 Ultimate inclut l'ensemble complet des outils DB Power Studio. Il s'agit d'un ensemble d'outils très puissant, comprenant l'environnement de développement de requêtes RapidSQL, DB Change Manager et DB Optimizer, pour gérer une partie importante du processus de développement et de déploiement en gérant les modifications apportées au modèle de données, à la base de données, au code, etc. C'est une très bonne et juste combinaison de technologies.

DI. : Cependant, si nécessaire, les développeurs peuvent utiliser Subversion pour la gestion des versions du code source et DB Change Manager pour la gestion des versions des métadonnées. Vous pouvez utiliser le profilage de code et DB Optimizer pour optimiser le code côté serveur, RapidSQL pour créer et déboguer le code côté serveur et nos IDE pour créer et déboguer des applications. Cette combinaison de technologies dans RAD Studio XE Ultimate Edition démontre les parallèles entre la base de données et les modèles de développement d'applications. La plupart des développeurs créant des applications métier à l'aide de Delphi et C ++ Builder travaillent avec des bases de données et ont besoin de ces outils, et RAD Studio XE Ultimate Edition est une excellente combinaison pour ces développeurs.

KP : L'utilisateur moderne n'est plus seulement un utilisateur de la plate-forme Windows. Nous utilisons des appareils mobiles, iPhone, iPad, appareils basés sur la plate-forme Android. Cela signifie que les développeurs doivent commencer à cibler différentes plates-formes sans augmenter de manière significative leur investissement dans la formation - c'est-à-dire qu'ils ont besoin d'outils universels. Evidemment, il est irréaliste d'attendre l'émergence d'outils universels de fabricants de plateformes, et en la matière on ne peut compter que sur des fabricants d'outils indépendants. Où peut-on compter sur Embarcadero ?

DI. : Nous avons encore beaucoup à faire dans le domaine du support des plateformes. Aujourd'hui, nous fournissons un support pour la plate-forme iOS pour iPhone et iPAD, puis les smartphones basés sur la plate-forme Android, Windows 7 et Blackberry recevront notre support. Dans RAD Studio XE 2, nous avons commencé par créer la plate-forme FireMonkey pour iOS, puis par le portage de FireMonkey sur d'autres plates-formes.

Dans le même temps, il existe un grand nombre de systèmes d'exploitation qui prennent en charge les écrans tactiles pour les téléphones, les tablettes et les appareils, les ordinateurs de bureau, et nous continuerons à les prendre en charge. De plus, il existe des systèmes de commande vocale, des systèmes de contrôle de mouvement, des systèmes biométriques, des accéléromètres, nous devons donc continuer à étendre FireMonkey afin que tous les développeurs puissent profiter des nouvelles plates-formes. Par exemple, l'appareil Microsoft Kinect a été conçu pour la Xbox 360, et il existe désormais un SDK (Software Development Kit) correspondant pour Windows également. Et nous avons déjà des exemples dans lesquels nous utilisons le mouvement pour contrôler une application de la même manière qu'une souris ou un clavier est habituellement utilisé.

Lorsque vous créez des applications avec beaucoup de graphiques complexes, vous générez tout un monde de nouvelles interfaces utilisateur. Si nous avons affaire à un système d'exploitation Windows, nous encapsulons son API Windows dans une VCL (Visual Component Library, qui fait partie des outils de développement Delphi et C++ Builder. - Environ. éd.), qui, soit dit en passant, peut être utilisé davantage. Et dans FireMonkey, nous encapsulons l'API du système d'exploitation. Mais aujourd'hui, nous manipulons beaucoup plus largement les formes et les graphiques. Vous pouvez également ajouter des propriétés physiques de l'espace pour l'animation et les effets spéciaux. En outre, il existe une tonne d'autres options d'expérience utilisateur supplémentaires que nous cherchons à mettre en œuvre au cours des prochaines années sur plusieurs plates-formes, appareils mobiles et tablettes.

Microsoft a récemment publié des détails sur Windows 8 qui devraient sortir dans un an. Nous prendrons en charge ces innovations dans la VCL et dans la plate-forme FireMonkey. Mais Delphi est un outil de développement conçu non seulement pour Windows, mais aussi pour Macintosh, iPhone et iPad. Nous développons également nos produits PHP, prenons en charge jQuery Mobile, utilisons l'API iOS pour développer des applications clientes mobiles et construisons des applications serveur PHP à l'aide d'assistants et d'outils pour générer des codes JavaScript et HTML côté client et des feuilles de style en cascade. Nous pouvons créer des packages à partir d'applications PHP et d'applications clientes iPhone iOS natives, le client parlant au serveur PHP. Et cela, à son tour, communiquera avec le serveur de base de données et avec les services Web - avec tout ce qui est nécessaire pour l'entreprise.

Environnement de développement RadPHP XE2. Création d'une application web mobile
en utilisant les composants jQuery Mobile pour iPhone 3G

En d'autres termes, nous prévoyons d'étendre les capacités de FireMonkey et de VCL, notamment dans le domaine du support des plateformes mobiles.

KP : Pourriez-vous en dire plus sur la plate-forme FireMonkey ?

DI. : Comme je l'ai noté, la VCL conçue pour Windows continuera d'évoluer et de s'améliorer. Mais aujourd'hui, si vous voulez réellement développer des applications métier, vous devez les créer pour différentes plateformes. C'est à cela que sert la plate-forme FireMonkey. Il prend en charge la création d'interfaces utilisateur avec des graphiques 3D haute résolution et hautes performances, une fréquence d'images élevée et, surtout, utilise un processeur graphique pour cela.

Vous pouvez utiliser ces capacités lors de la création d'applications scientifiques, d'ingénierie et commerciales. De telles applications peuvent se connecter aux bases de données à l'aide de la technologie dbExpress, tout en utilisant des composants non visuels familiers aux développeurs, tels que ClientDataSet ou DataSource, utiliser la technologie DataSnap, se connecter à toutes les bases de données, serveurs SOAP et REST. Vous pouvez créer des commandes attrayantes, des boutons avec des boîtes, des tableaux sophistiqués et d'autres éléments d'interface, à la fois en 2D et en 3D. Vous pouvez charger un modèle 3D prêt à l'emploi dans l'application et le connecter à une forme 2D dans laquelle il peut être tourné et visualisé sous différents angles. Vous pouvez créer un cube de données ou un diagramme d'entreprise 3D et le faire pivoter à l'aide d'une souris, d'un clavier ou même d'un appareil Kinect, ou vous pouvez aller à l'intérieur d'un cube et regarder différentes surfaces de l'intérieur. Et tout cela peut être fait avec un GPU à haute vitesse. Ensuite, la même application peut être compilée pour une autre plate-forme, telle que Mac OS.

Application contenant un cube tournant avec des données,
placé sur ses bords

Ou vous pouvez créer une forme 3D à partir de zéro et utiliser des caméras et des lumières et éclairer et faire pivoter des parties de l'interface utilisateur. Le concepteur de formulaires dispose d'un environnement intégré pour prendre en charge l'interface utilisateur 3D directement pendant le développement.

Sous Windows, vous pouvez utiliser les bibliothèques Direct2D pour les graphiques 2D haute résolution et Direct3D pour les graphiques 3D. Sur Mac OS, les bibliothèques Quartz et OpenGL sont utilisées aux mêmes fins. Pour iOS, les bibliothèques Quartz et OpenGL ES sont utilisées. Mais tout cela est caché au développeur - il utilise la plate-forme FireMonkey, son système de coordonnées et son API, sans penser à ces bibliothèques, et peut compiler la même application pour différentes plates-formes.

Rappelons-nous ce qu'est VCL. La VCL est un wrapper de composant autour de l'API Windows. Nous nous occupons des ressources, des menus, des boîtes de dialogue, des couleurs, des styles, des messages Windows. Contrairement à VCL, un « wrapper » multi-plateforme, FireMonkey conserve les mêmes modèles d'événements et de composants, ce qui vous permet de penser en termes d'événements (par exemple, OnClick, OnHasFocus, onMouseDown et onKeyDown), mais gère les événements Macintosh ou iPhone.

La plate-forme FireMonkey est également livrée avec un système d'animation complet pour les éléments de l'interface utilisateur. Ce n'est certainement pas un système d'animation complet comme Pixar, mais il permet des effets tels que l'animation de bitmaps, la mise en évidence des éléments de l'interface utilisateur et le travail avec des graphiques vectoriels. Plus de 50 effets visuels sont à la disposition du développeur : floutage, transformation d'une image en noir et blanc, dissolution, transitions, réflexion, création d'ombres - tous les types d'effets disponibles dans les GPU modernes, que l'on trouve désormais dans presque tous les ordinateurs. L'application, construite à l'aide de la plate-forme FireMonkey, envoie des commandes au GPU, qui fait tout le travail d'affichage des graphiques et de création de l'interface utilisateur. Dans ce cas, le processeur central est libre pour les calculs et les appels au système d'exploitation. Le développeur n'a qu'à placer correctement les composants.

La chose la plus fondamentale à propos de la plate-forme FireMonkey est la manière dont elle construit l'interface utilisateur. Il existe des fonctions permettant de placer des graphiques bitmap sur des éléments d'interface tels que des menus, des boutons et des barres de défilement. Chez FireMonkey, nous utilisons des graphiques vectoriels utilisant le GPU à cette fin. Du point de vue de la programmation, ce sont tous les mêmes contrôles, mais le processeur graphique fait tout le travail pour les afficher. Nous pouvons appliquer des styles aux contrôles, faire ressembler l'application à une application pour Mac OS ou Windows, créer notre propre style, appliquer nos styles aux éléments d'interface (par exemple, faire un bouton rectangulaire ou rond en changeant son style dans l'éditeur de formulaire) - pour cela l'environnement de développement dispose d'un éditeur de style. Vous pouvez créer votre propre style ou modifier le style d'une application déjà terminée.

Plateforme FireMonkey - Outils de développement
et plates-formes prises en charge

Si vous vous en souvenez, la VCL avait un nombre limité de contrôles de conteneur (c'est-à-dire vous permettant d'y placer d'autres éléments), et dans FireMonkey, chaque contrôle est un conteneur. Cela signifie que chaque contrôle peut contenir n'importe quel autre contrôle. Par exemple, à l'intérieur des éléments de la liste déroulante, il peut y avoir des images, des boutons, des champs d'édition et d'autres contrôles. Et vous pouvez également organiser les composants en couches.

Le système de rendu FireMonkey est suffisamment flexible - il peut utiliser les bibliothèques Direct2D, Direct3D et OpenGL en envoyant des commandes au GPU. Pour obtenir la même chose dans la VCL, il était nécessaire de générer un tampon séparé à l'extérieur de l'écran, d'y créer une image, d'appeler les fonctions appropriées des bibliothèques graphiques, puis de l'afficher sur le formulaire.

Exemples d'effets graphiques pris en charge par FireMonkey

Si vous n'avez pas de GPU, vous pouvez toujours appliquer des formes 2D ou 3D et utiliser les commandes FireMonkey. Dans ce cas, la plate-forme FireMonkey utilisera les bibliothèques GDI + ou d'autres bibliothèques similaires et effectuera les mêmes effets et animations ou manipulations d'objets 3D.

Une autre caractéristique de FireMonkey est un nouveau système de liaison des éléments d'interface aux données, qui est ouvert et flexible. Il existe deux types d'éléments d'interface dans la VCL : liés aux données et non liés aux données (par exemple, TDBEdit et TEdit). Dans FireMonkey, chaque contrôle peut être associé à des données, et de tout type. Il peut s'agir simplement d'une expression, d'un champ d'un ensemble de données, de données d'objets générés par le développeur ou des résultats d'un appel de méthode.

De plus, lors de la création d'une application, vous pouvez y charger un modèle 3D prêt à l'emploi et l'utiliser - de telles capacités sont souvent requises dans les applications commerciales et d'ingénierie. Nous avons un client qui crée des applications logistiques. Ils avaient un système d'information construit avec Delphi, et dans celui-ci, une application qui dessinait un plan et affichait des informations à partir de sources de données. Ils ont récemment fait quelque chose d'intéressant : ils ont dessiné un entrepôt 3D entièrement automatisé dans AutoCAD et leur application vous permet de voir le chariot élévateur automatique se déplacer dans l'entrepôt et placer les marchandises sur les étagères. Et ils mettent les données des sources sur l'image correspondante.

Exemples de modification des styles d'application

KP : Quels formats de modèle 3D sont actuellement pris en charge ?

DI. : Dans cette version, nous prenons en charge le chargement de modèles à partir d'AutoCAD, Collada (outil de modélisation 3D open source. - Environ. ed.), Maya, format OBJ, qui est pris en charge par de nombreux fournisseurs de graphiques 3D.

KP : Quels autres formats envisagez-vous d'ajouter ?

DI. : Nous prévoyons d'ajouter 3DS (3D Studio MAX), SVG (généralement ce format est utilisé pour les graphiques vectoriels 2D, mais parfois pour la 3D), Google SketchUp. Peut-être que nous prendrons également en charge d'autres formats.

KP : L'utilisation de modèles 3D dans des applications créées avec FireMonkey nécessite-t-elle une licence pour l'outil de modélisation 3D correspondant ?

DI. : Non, ce n'est pas le cas. Tout ce que nous faisons est de lire le fichier modèle. Nous importons le modèle, mais nous ne l'exportons pas (bien que vous puissiez bien sûr écrire une application qui enregistrera le modèle dans votre propre format). Nous ne prétendons pas être un fabricant d'outils de modélisation 3D - pour cela, vous pouvez utiliser AutoCAD, 3D Studio Max, Maya ou tout autre outil de modélisation 3D, et importer les modèles créés dans nos applications.

KP : Quelle est la performance des applications créées avec FireMonkey sur les plates-formes matérielles modernes ?

DI. : Les performances sont plutôt bonnes. Par exemple, une forme 3D avec trois sphères et trois lumières peut être rendue sur un MacBook Pro à 100 images par seconde. Et cela peut atteindre 600 - cela dépend de ce que nous faisons exactement. Encore une fois, tout dépend de la puissance du GPU.

KP : Cela signifie-t-il que FireMonkey peut être utilisé pour créer des jeux à jour ?

DI. : Nous ne positionnons pas nos outils de développement comme un outil pour les jeux. Néanmoins, en utilisant les hautes performances des GPU modernes, vous pouvez créer des jeux avec FireMonkey - après tout, ils les créent en utilisant Direct3D ou OpenGL.

KP : Quel genre de travail faites-vous actuellement dans le domaine de la prise en charge de la reconnaissance des gestes et d'autres nouveautés ? Cette prise en charge est-elle disponible ?

DI. : Nous n'avons pas encore de prise en charge des gestes pour cette version. Le contrôle des gestes sera ajouté dans une future version de FireMonkey, mais pour l'instant, vous pouvez utiliser la prise en charge des gestes intégrée au système d'exploitation.

Mikhail Filippenko, directeur de Fast Reports, Inc.

K.R. : Nous avons déjà dit que la technologie FireMonkey a des racines russes - ses fondations ont été créées dans notre pays, puis la technologie elle-même et ses développeurs ont rejoint Embarcadero. En général, il est gratifiant de voir la croissance du composant russe dans le cadre de RAD Studio et Delphi. C'est à la fois l'activité de notre centre de développement de Saint-Pétersbourg et la contribution de développeurs russes indépendants. Par exemple, le générateur de rapports FastReport, connu dans le monde entier et très populaire dans notre pays, fait désormais partie de Rad Studio XE2. Il est de Rostov-sur-le-Don.

KP : Je voudrais parler des compilateurs. Quel type de compilateur est utilisé pour créer des applications iOS ?

DI. : Pour l'iPhone ou l'iPad, nous n'avons pas notre propre compilateur Delphi - nous n'avons pas encore développé de compilateurs pour les processeurs ARM utilisés dans ces appareils. Pour iOS, nous utilisons temporairement le compilateur et la bibliothèque d'exécution Free Pascal. Mais nous travaillons sur la prochaine génération de compilateurs, y compris pour les processeurs APM. Mais pour Windows et Mac OS, il existe des compilateurs, car les deux plates-formes matérielles sont basées sur des processeurs Intel.

KP : Et qu'est-ce qui a été fait dans le domaine du développement de compilateurs au cours des deux dernières années ?

DI. : Nous avons des compilateurs Delphi 32 et 64 bits pour Windows et Mac OS. Et nous travaillons sur une nouvelle génération de compilateurs Delphi et C++. Le travail sur eux est toujours en cours, mais une fois terminé, nous aurons des compilateurs Delphi pour les processeurs ARM, les plates-formes Android, Linux et autres. Et nous aurons des compilateurs C ++ 64 bits pour Windows et d'autres plates-formes compatibles avec la dernière norme de langage C ++ qui vient d'être adoptée par l'ISO.

KP : Que se passe-t-il aujourd'hui avec la prise en charge du cloud computing dans les outils de développement Embarcadero ?

DI. : Dans RAD Studio XE 2, nous prenons en charge la migration des applications vers le cloud dans Microsoft Azure ou Amazon EC2 à l'aide de Platform Assistant. Et nous avons des composants de serveur pour Cloud Storage pour Azure et Amazon S3 pour stocker des tables, des données binaires, des files d'attente de messages. Dans la version précédente de RAD Studio XE, nous prenions également en charge le déploiement d'applications sur Amazon EC2, mais il n'y avait pas de prise en charge du stockage.

Prise en charge du cloud computing dans RAD Studio XE 2

KP : Il y a deux ans, vous parliez de la nouvelle solution All-Access. Combien était-il demandé ? Quels sont ses avantages pour les intégrateurs de systèmes et les développeurs ?

DI. : La solution All-Access et l'outil cloud AppWave sont largement utilisés dans le monde. Ils sont conçus pour simplifier l'utilisation des applications de notre société et d'autres fabricants. En fait, c'est une solution de gestion des licences et des applications applicatives, et elle est pratique pour les grandes entreprises. Les petites entreprises, en revanche, qui n'ont pas d'équipe dédiée de personnes chargées de gérer les applications, peuvent placer une application dans un référentiel, sélectionner des noms d'utilisateur dans une base de données et s'assurer que ces applications sont utilisées sans avoir à se rappeler où se trouve la licence. est la clé et combien de licences sont disponibles. All-Access et le navigateur AppWave sont conçus pour gérer à la fois la gestion des versions et le contrôle d'accès.

K.R. : Le marché est si diversifié et les utilisateurs si divers qu'il est impossible de couvrir tous les besoins avec une seule solution. Par conséquent, nous nous efforçons d'obtenir une variété de solutions "d'emballage". Nous avons fait un excellent travail d'unification des licences, de la gestion des licences et des méthodes d'installation des produits. Cette gamme de solutions comprend des outils de gestion et d'octroi de licences non seulement pour les produits Embarcadero, mais également pour tout autre produit, y compris le développement interne des entreprises.

Le travail sur le regroupement des outils de développement dans des kits efficaces pour les utilisateurs est toujours en cours. Nous avons All-Access, un sur-ensemble qui rassemble tous les produits Embarcadero. Si le client achète la version All-Access Platinum, il reçoit tous les outils dont dispose Embarcadero. Mais parfois, cet ensemble s'avère redondant, par exemple, pour les spécialistes des bases de données, nous avons créé deux autres ensembles - DB Power Studio Developer Edition et DB Power Studio DBA Edition. La différence entre eux est que pour le développeur, nous proposons RapidSQL - un outil de développement de code serveur, et pour l'administrateur, DBArtizan y est intégré - un outil d'administration de base de données, un produit plus large que RapidSQL. Pour les professionnels, nous avons les kits All-Access suivants : Tous les produits, DB Power Studio pour les développeurs, DB Power Studio pour les administrateurs, ER Studio Enterprise Edition pour les architectes et toute autre personne impliquée dans la modélisation. Il existe des combinaisons pour le développement d'applications et pour les administrateurs. Delphi est un outil de développement, et il est logique d'y ajouter des outils de développement et d'optimisation SQL. Enfin, DB Change Manager est un outil logique pour gérer la complexité des modifications qui se produisent dans les bases de données au cours de leur cycle de vie.

Ainsi, All-Access est à la tête d'une grande famille de suites de produits différentes.

KP : Si ce n'est pas un secret, qui utilise All-Access en Russie ?

K.R. : Nous avons des clients qui ont acheté All-Access basé sur Delphi. Beaucoup d'entre eux construisent des systèmes client/serveur complexes avec SQL Server et Oracle, et ils ont immédiatement aimé notre boîte à outils de base de données multiplateforme. Nous avons une entreprise cliente qui travaille avec Delphi depuis la première version, et elle est passée de Delphi à All-Access il y a un an. Delphi et DBArtisan sont deux outils garantis pour être utilisés par tous les développeurs de cette société. Et il y a des clients qui sont venus à All-Access du côté de la base de données. Leur travail principal est d'administrer des bases de données, mais ils font parfois du développement d'applications. Les clients All-Access incluent des sociétés de médias, des sociétés d'ingénierie et d'autres secteurs.

Je voudrais aussi m'attarder sur les petites entreprises. Très souvent en petites équipes, un développeur fait tout, et une telle entreprise achète parfois de gros kits d'épicerie All-Access pour un ou deux développeurs. Dans les grandes équipes, il est déconseillé à un développeur de jouer, par exemple, également le rôle d'administrateur de base de données, donc généralement les petits ensembles de produits y sont populaires, et dans les petites entreprises, une telle combinaison de tâches est tout à fait acceptable.

Delphi Architect est un produit fortement commercialisé qui comprend des outils de modélisation et de programmation. Le nombre d'exemplaires vendus est cependant inférieur à la version Delphi Enterprise, mais il est également important. Je tiens à souligner qu'en 2010, nous nous sommes révélés être le meilleur pays en termes de ventes, malgré le fait que tous les pays aient traversé la crise. Cette croissance n'était pas tant due à des facteurs économiques qu'au fait que la version de RAD Studio XE sortie fin 2009 s'est avérée très demandée. Et alors que nous nous attendons à une nouvelle croissance des ventes.

Nous avons pris une autre mesure raisonnable, qui est très demandée en Russie. Le degré de légalisation des différentes versions de nos produits est différent : plus la version est élevée, plus elle est légalisée, car auparavant le logiciel n'était pas aussi activement acheté. A partir de la version RAD Studio XE, la licence couvre les versions 2010, 2009, 2007 et même Delphi 7 - un produit très répandu.

Aujourd'hui, les développeurs sont confrontés au fait qu'ils ont à la fois de nouveaux projets et des projets en état d'accompagnement. Un grand nombre de projets ont été migrés des premières versions de Delphi vers la version 7 et restent dans cette version, continuant à travailler sur des ressources relativement petites. Personne ne les traduit vers des versions plus récentes, mais ils sont maintenus dans un état viable. Et maintenant, nous permettons à peu d'argent (moins que le prix d'une licence Delphi 7) d'obtenir à la fois RAD Studio XE et Delphi 7 - c'est-à-dire que nous légalisons le développeur à la fois pour la mise en œuvre de nouveaux projets et pour les projets de support.

KP : Comment évaluez-vous l'état actuel de la communauté Embarcadero ?

DI. : Cette communauté est grande et très exigeante. Ils ont besoin de tout immédiatement - ce sont les développeurs. Mais parfois, il faut beaucoup de temps pour bien faire quelque chose.

Il y a quelques années, nous avons pris l'architecture des composants Windows et l'avons intégrée aux postes de travail Linux. Maintenant, nous voyons que ce n'était pas la bonne décision. La bonne décision est de créer une plate-forme pour les applications. Les applications, même pour différentes plates-formes, ont des menus, des fenêtres, des graphiques, un accès réseau et un accès aux périphériques. Différentes plates-formes peuvent avoir différents modèles de contrôle de flux ou de gestion des exceptions, mais nous voyons les mêmes blocs try dans le code de l'application. Notre travail consiste à permettre aux développeurs de créer plus facilement des applications métier et de les compiler pour les plates-formes sur lesquelles elles sont censées être utilisées, indépendamment de l'agencement du système d'instructions des processeurs correspondants et des autres fonctionnalités de ces plates-formes. Et FireMonkey est exactement ce dont vous avez besoin pour résoudre ce problème.

KP : Si une entreprise crée un nouvel appareil et souhaite le prendre en charge dans FireMonkey, cela sera-t-il possible ?

DI. : Avec des compilateurs de nouvelle génération dotés d'un front-end indépendant de la plate-forme et d'un back-end spécifique à la plate-forme, cela est tout à fait possible. En attendant, pour chaque système d'exploitation, nous créons un compilateur et une bibliothèque d'exécution à partir de zéro.

Tout nouvel appareil moderne possède généralement une interface utilisateur graphique (beaucoup ont un processeur dual-core et un GPU) et des SDK de développement standard. Tout cela facilite la création d'une prise en charge des périphériques dans FireMonkey. Si le nouveau périphérique n'aura que des bibliothèques pour les graphiques bidimensionnels tels que Quartz, nous pourrons fournir un support dans FireMonkey pour un tel périphérique, mais cela prendra environ plusieurs mois. Cependant, beaucoup dépend de la plate-forme : toutes les plates-formes ne prennent pas en charge toutes les fonctionnalités, par exemple, iOS n'a pas de menus et de boîtes de dialogue, et vous ne pouvez pas mettre les composants correspondants sur les formulaires de telles applications.

KP : Quelque chose a-t-il changé dans la politique des partenaires ? Que fait-on pour augmenter la part d'utilisateurs de vos produits ? Que se passe-t-il en Russie ?

DI. : Notre écosystème de partenaires est vaste - il existe des centaines de fabricants d'outils et de composants qui ne font pas partie de nos produits, et nous avons un programme de partenariat technologique. Par conséquent, les développeurs ont accès à un large éventail de composants, de technologies et d'outils. Et les solutions qu'ils créent pour leurs clients s'avèrent meilleures que si seuls nos produits étaient utilisés. Et pour les ventes, nous avons des bureaux dans de nombreux pays, des revendeurs et des distributeurs.

K.R. : Ce n'est pas le nombre de partenaires qui est important pour nous, mais la qualité du travail de chaque partenaire spécifique. Pour l'instant, nous souhaitons nous concentrer sur une collaboration étroite avec les partenaires existants, même si le pool de partenaires reste ouvert. Nous avons de nombreux partenaires, et nous devons les aider en termes de technologie. Nous travaillons avec des développeurs, et ils savent ce qu'ils veulent et savent ce qui est disponible sur le marché, et les capacités des partenaires doivent correspondre à cela.

Nous avons des partenaires commerciaux qui ont sérieusement investi dans Embarcadero en tant que secteur d'activité - ils ont des spécialistes formés, commercialisant nos produits, des employés dévoués qui sont responsables de ce domaine et surveillent ce qui se passe avec nos produits, notre liste de prix, notre marketing. Naturellement, elles réussissent mieux à vendre nos produits que les entreprises qui vendent nos produits au cas par cas.

KP : David, Kirill, merci beaucoup pour l'interview intéressante. Permettez-moi, au nom de notre publication et de nos lecteurs, de souhaiter à votre entreprise un succès continu dans la création de vos outils incroyables dont les développeurs ont tant besoin !

Les questions ont été posées par Natalia Elmanova

FireMonkey est la technologie de base du "nouveau Delphi". Veuillez nous parler des objectifs, des capacités et des aspects techniques de l'appareil de cette bibliothèque fondamentalement nouvelle. Avec le temps, avec le recul, à quel point votre refus de continuer à développer le très populaire VCL a-t-il été difficile et justifié ?

Il a été choisi comme direction principale pour le développement de la technologie Delphi afin d'atteindre un objectif spécifique - le développement multi-plateforme à partir d'un environnement, basé sur une base de code source unique, et sans avoir besoin d'une reconversion cardinale des développeurs. Dans le cadre de la VCL désormais classique et hyper populaire, c'était impossible, sa connexion avec WinAPI était trop étroite, pourrait-on dire, « au niveau génétique ».

Les composants VCL n'avaient pas de couche « abstraite » entre la couche fonctionnelle en termes d'interface et les mécanismes de leur affichage. Niveau fonctionnel- comment il se comporte en tant que contrôle, à quels événements il réagit, quel type d'interaction utilisateur il fournit. Affichage- Appeler des méthodes de visualisation orientées plate-forme comme une sorte d'image formée d'objets raster et de primitives vectorielles. FireMonkey a initialement implémenté le principe de séparation stricte du contrôle en deux composantes : « comportementale » et « visuelle ».


Vsevolod Leonov, Embarcadero Technologies

Le premier ne répétera généralement pas même les bases de la VCL, mais l'essence de la programmation orientée objet. Un composant est une classe, les classes de composants forment une hiérarchie où les familles et les modules peuvent être distingués. La classe d'un composant a peu à voir avec la façon dont il est rendu.

L'« image » visuelle est générée dynamiquement, elle n'est pas codée en dur dans la classe du composant. L'image ou le "style" dans FireMonkey est chargé dans le composant au démarrage de l'application. Nous avons un squelette fonctionnel pour un composant, et la « peau » ou le « revêtement » peuvent être modifiés, mais pourquoi ? Précisément pour que les applications FireMonkey aient l'air authentiques sur n'importe quelle plate-forme - Windows 7, Windows 8, Mac OS, iOS et, dans un futur proche, Android. La structure de classe monolithique traditionnelle de la VCL ne pouvait pas fournir cela.

L'efficacité technologique de l'approche joue ici un rôle particulier. Fondamentalement, vous pouvez utiliser la bibliothèque VCL et remplir WinAPI et tous les autres appels de plate-forme possibles. Cela peut toujours être fait sur un sous-ensemble très limité de composants, mais la VCL contient plusieurs centaines de composants, donc cette approche pourrait simplement tuer la VCL. Il a été décidé de ne pas toucher à la VCL, mais de développer de nouvelles opportunités sur une nouvelle plateforme - FireMonkey. Cette technologie a même une certaine sophistication technique - au moment de la construction d'un projet pour une plate-forme spécifique, l'IDE Delphi connecte le compilateur requis et les composants de l'interface obtiennent le style de la plate-forme.

Pour l'utilisateur, il s'agit d'un clic et du même code source, pour Delphi, c'est un travail de longue haleine de développeurs pour créer une telle bibliothèque multi-plateforme.

Lorsqu'il est devenu clair que FireMonkey serait introduit en tant que nouvelle plate-forme distincte, il a été nécessaire de choisir la bonne stratégie de coexistence : Embarcadero ne voulait en aucun cas avoir un impact négatif sur les utilisateurs de VCL. Par conséquent, nous avons choisi le plan suivant : VCL reste stable idéologiquement et architecturalement pour assurer la compatibilité la plus élevée possible, facilitant la migration des projets vers des versions modernes. Le développement de FireMonkey suivra un chemin naturel et parallèle, sans revenir sur la VCL.

Le point faible de cette solution est la migration plutôt problématique de VCL vers FireMonkey au sein d'un même projet. Mais d'un autre côté, pour un nouveau projet, un développeur peut choisir FireMonkey pour assurer la fonctionnalité multi-plateforme de son application résultante. Après la sortie de XE4 avec support iOS, nous pouvons déjà parler des avantages concurrentiels brillants de Delphi pour démarrer le développement mobile dans un environnement d'entreprise, qui seront augmentés après la mise en œuvre du support Android prévu.

Par conséquent, en tant que tel, il n'y a pas de « rejet » explicite du développement de la VCL. La partie VCL de Delphi évolue également dans des versions plus récentes. Cela inclut la prise en charge 64 bits et l'introduction de styles pour les composants visuels, et la mise en œuvre du mécanisme de liens dynamiques flexibles ou "liaison", et l'inclusion de la bibliothèque FireDAC pour travailler avec des bases de données dans des projets VCL. Juste dans le contexte d'un saut qualitatif de géant dû à FireMonkey, les progrès dans la VCL semblent quelque peu sous-développés. Mais, quoi qu'il en soit, VCL fait partie intégrante de Delphi et le restera pendant de nombreuses années. Alors que l'évolution de la plate-forme et l'état de l'art actuel des systèmes d'exploitation de bureau et mobiles sont tels que l'avenir est clairement avec FireMonkey.

Dans l'interview, nous avons déjà discuté de la prise en charge d'iOS, parlons à nos lecteurs de la prise en charge des autres dernières technologies du dernier RAD Studio XE4, telles que Windows 8 et WinRT, les systèmes 64 bits, macOS, etc. Puis-je énumérer ce que vous pouvez offrir d'autre à un programmeur moderne gâté par les innovations ?

Très probablement, un programmeur moderne n'est pas "gâté" par les innovations. Pour les grands projets, toute « innovation » se transforme souvent en une somme de travail colossale.

Par exemple, tout le monde a attendu longtemps, beaucoup se sont immédiatement précipités pour transférer leurs codes sur la nouvelle plateforme. Mais il s'avère que même les équipes très professionnelles ne sont pas prêtes pour cela. Le code 64 bits compilé ne signifie pas réalisable. Les "péchés de jeunesse" ont commencé à émerger, par exemple, l'utilisation d'instructions en supposant une taille d'adresse de 4 octets. Manque de culture de la conduite des tests, couplé à une indisponibilité technologique pour mettre en œuvre ce procédé dans un délai court.

Et ici - plus le projet est grand, mesuré, par exemple, par le nombre de lignes de code source, plus les programmeurs sont soigneusement et équilibrés au sujet de diverses innovations allant de l'apparition du "bouton" dans l'interface au "sucre syntaxique" dans le compilateur.

L'une de ces réalisations « problématiques » a été la sortie de Windows 8. Personnellement, en tant qu'utilisateur de PC et juste spécialiste informatique moderne, Windows 8 est un délice. Mais pour les développeurs qui ont reçu un lot d'ordinateurs exécutant Windows 8 avec une spécification technique pour le développement d'un nouveau système d'exploitation en charge, cela signifie certaines difficultés.

Nous avons essayé de fournir un support aussi confortable et indolore que possible pour le développement de la nouvelle interface de ce système d'exploitation. Par conséquent, des styles spéciaux ont été introduits à la fois pour VCL et FireMonkey, et le programmeur peut soit reconstruire l'interface de l'application, soit recréer l'application, qui sera indiscernable du Windows 8 "natif" en apparence. Bien sûr, une prise en charge « native » de Windows 8 via WinRT est nécessaire. Mais c'est là que la hiérarchisation des objectifs est affectée dans les conditions modernes. Mac OS, iOS, Android dans un futur proche ne donnent pas encore l'occasion de parler d'une prise en charge complète de WinRT dans un futur proche.

L'objectif stratégique d'Embarcadero est bien sûr d'être multiplateforme. La sortie de RAD Studio XE4 a été déterminante, principalement en raison de la prise en charge d'iOS. Un programmeur actif utilisant la VCL peut commencer à développer pour iOS en quelques heures. Même une simple application mobile peut être instantanément transformée en un projet puissant qui fonctionne au sein de l'infrastructure existante. Ne pensez pas qu'il s'agit simplement d'un nouveau compilateur pour FireMonkey et d'un nouveau style pour correspondre à l'interface iOS.

Il comprend un nouveau concepteur visuel, une prise en charge intégrée de divers facteurs de forme et des bibliothèques d'accès aux données, y compris le nouveau FireDAC et la technologie LiveBindings pour une liaison flexible et dynamique aux données d'entreprise. Toutes ces innovations sont synchronisées - à la fois pour Windows, pour Mac OS et pour iOS. Le système d'exploitation Mac OS ne se développe pas aussi rapidement, il n'y a donc pas de problèmes tels que la transition de Windows 7 à Windows 8. Mais les écrans Retina sont apparus, et cela a nécessité une attention particulière. Désormais, toute application MacOS créée dans Delphi XE4 inclut automatiquement deux styles - "normal" et "haute définition".

Cette. la même application peut avoir la même interface « native » de haute qualité sur n'importe quel ordinateur de bureau Apple.

Embarcadero ne veut pas "surprendre", "surprendre" ou même "divertir" les développeurs avec ses nouvelles versions innovantes. Au contraire, la sphère informatique est déjà pleine de surprises diverses : nouveaux appareils, nouvelles plateformes, nouveaux utilisateurs, leurs nouveaux besoins, nouveaux scénarios d'interaction. Ajoutez de nouvelles technologies de développement logiciel à cela, et les programmeurs n'auront tout simplement pas le temps de créer de nouveaux systèmes sur les systèmes existants - ils ne feront que migrer d'un environnement à un autre, d'une ancienne bibliothèque à une nouvelle, d'un langage à un autre .

Mais nous ne prétendons pas rejeter tout ce qui est nouveau. Nous voulons juste assurer la continuité de tout - code, interface, projet, voire des compétences professionnelles lorsque de nouvelles plateformes et appareils apparaissent. On peut dire que nous combattons un conservatisme malsain vis-à-vis des nouvelles plateformes au détriment d'un conservatisme sain dans les outils de développement. Ne vous attendez pas à des produits exotiques, des langages de programmation non standard et des outils de développement extravagants d'Embarcadero.

Avec nous, vous trouverez toujours - du développement visuel, des langages classiques, du code "natif", et laissez les nouvelles plates-formes cibles être pour vos applications, créées de la même manière classique éprouvée.

06/03/2013 12:46

J'ai beaucoup souffert à cause de l'absence d'un composant de navigateur dans FireMonkey. Le projet bien connu Delphi Chromium Embedded incluait le support FMX dans la dernière version. Mais malgré le fait qu'un certain temps s'est écoulé, l'auteur n'est pas pressé d'ajouter le support pour FMX2. En conséquence, j'ai dû prendre la situation en main.

Le composant TChromiumFMX de l'assemblage officiel fonctionne assez bien dans FireMonkey (dans XE2), mais il ne se compile même pas dans FMX2. Je devais comprendre un peu comment cela fonctionnait et le réparer. Heureusement, aucun changement majeur n'a été nécessaire.

Dans FMX2, deux choses dont le composant a besoin ont changé.

Premièrement, TBitmap n'a plus les propriétés ScanLine et StartLine. L'accès direct au contenu de TBitmap a été repensé (je me demande pourquoi ?) et maintenant il est disponible via la classe TBitmapData, qui renvoie la méthode TBitmap.Map.

Eh bien, le deuxième, plus célèbre - Platform.* N'est plus là, vous devez maintenant obtenir l'interface souhaitée via TPlatformServices.GetPlatformService. Tout est assez simple ici et il n'y a pas de problèmes.

Je ne l'ai pas testé de manière particulièrement inventive, mais pour mes besoins, le composant est tout à fait approprié - vous pouvez afficher des sites à travers lui. Télécharge le. Aussi, j'enverrai probablement mes modifications à l'auteur, il sera peut-être nécessaire de les ajouter à la version officielle.

30/07/2012 02:43

Jason Southwell propose de développer un ensemble de wrappers FireMonkey pour les contrôles natifs Windows / OSX et collecte des fonds pour cela. Il prévoit de collecter 20 000 dollars pour commencer.

L'idée est claire. Les composants FireMonkey existants sont rendus à l'aide de Delphi presque à partir de zéro, ce qui, d'une part, assure en grande partie leur fonctionnalité multiplateforme, mais d'autre part, en conséquence, nous obtenons des composants qui ne semblent pas tout à fait naturels dans les deux systèmes d'exploitation actuellement prise en charge. Et c'est la moitié du problème - en plus de l'apparence, vous devez développer indépendamment la logique de ces composants. Par exemple, RichEdit est plutôt compliqué ; ce n'est pas une tâche triviale de répéter sa logique dans FireMonkey par vous-même. La VCL et la CLX n'ont pas réinventé la roue ; ils en ont utilisé une toute faite.

Maintenant pour les mauvaises nouvelles. Tout fonctionne à l'exécution, mais je n'ai trouvé aucun moyen d'ajouter mon nouveau type d'onglet au concepteur d'éléments. Et il semble que tous les contrôles de liste aient le même problème : TListBox, TGrid, etc. Au début, j'aimais beaucoup l'approche de leur mise en œuvre, mais maintenant j'en doute même d'une manière ou d'une autre. Une recherche sur Internet a montré que je ne suis pas seul avec ce problème.

L'aide est silencieuse, je n'ai rien trouvé non plus dans le code. Vraiment? Ce serait extrêmement désagréable.

Qu'est-ce que FireMonkey ?


FireMonkey (FMX) est un framework de développement multiplateforme à la fois pour les systèmes de bureau (Windows, Mac OS + dans un futur proche, il est prévu de supporter le côté serveur sous Linux) et mobile (iOS et Android) en utilisant le Delphi/C ++ langue.

Particularités :

  • une base de code unique pour toutes les plateformes ;

  • tout contrôle (composant visuel) peut être un conteneur (parent) pour d'autres composants ;

  • la présence d'une position relative très avancée (20 types) des composants sur la forme ;

  • LiveBinding vous permet de connecter n'importe quel type de données ou d'informations à n'importe quelle interface utilisateur ou objet graphique ;

  • la présence des styles de la forme/des composants ;

  • Multi-Device Preview vous permet de personnaliser la présentation visuelle pour chaque plate-forme ;

  • FireUI Live Preview - affichage de la vue de l'application sur des appareils réels en temps réel.

Possibilités :

  • l'utilisation de l'API native de chaque plate-forme, ainsi que la possibilité d'appeler des bibliothèques natives tierces ;

  • interaction avec tous les capteurs (GPS, accéléromètre, boussole, Bluetooth (y compris LE) et autres);

  • prise en charge des notifications push, IoT ;

  • prise en charge des requêtes HTTP asynchrones ;

  • prise en charge de la plupart des bases de données (MsSQL, MySql, Oracle, PostgreSQL, MongoDB, etc.) ;

  • travailler avec Cloud Service (Amazon, Azure) ;

  • prise en charge du service Android.

Inconvénients (actuellement) :

  • manque de prise en charge de la personnalisation des classes natives ;

  • la mise en œuvre de choses spécifiques est soit impossible (widgets, extensions (iOS), etc.) soit une danse avec un tambourin est nécessaire (service de fond, message diffusé, etc.) ;

  • personnalisation de l'écran de démarrage (écran initial), pour le moins, non ;

  • Les contrôles FMX utilisent leur propre rendu (visualisation, dessin), qui est visuellement similaire au rendu natif ;

  • l'utilisation de commandes natives est associée à de grands mouvements du corps ;

  • avec beaucoup d'imbrication de composants, des choses incroyables se produisent : l'application plante à divers endroits, elle perd le focus, se bloque, etc.

  • le contenu informatif du débogage des applications sur les plates-formes mobiles est nul ;

  • les descriptions d'erreurs sur les plates-formes mobiles sont réduites à l'inutile « Error 0x00000X » ;

  • le temps de compilation veut être le meilleur pour les projets de taille moyenne à grande ;

  • la nécessité d'utiliser un fichier pour affiner les applications mobiles pour chaque plate-forme ;

  • pas de prise en charge de l'architecture Intel Atom ;

  • prix insuffisant par rapport aux concurrents.

Avantages:

  • développement très actif du produit et de la communauté ces derniers temps, prise en charge de plus en plus de nouvelles technologies ;

  • la présence d'un grand nombre de composants gratuits et commerciaux ;

  • la vitesse de l'application est très proche de celle native ;

  • un éditeur visuel très avancé et l'environnement en général, la présence de styles ;

  • la possibilité de tester une application sur Win, puis de la déployer ensuite sur des appareils, ce qui accélère considérablement le développement ;

  • changer de mode / plate-forme avec un léger mouvement de la main ;

  • PAServer offre une interaction facile avec MacOs lors du développement pour Apple OS ;

  • prise en charge des graphiques 3D prêts à l'emploi.

En conclusion, je tiens à dire que FireMonkey est devenu au cours des deux dernières années un outil professionnel pour le développement multiplateforme d'applications commerciales et pas seulement. De nombreuses lacunes sont progressivement résolues et à chaque version le produit devient de plus en plus moderne et autosuffisant, le scepticisme existant envers le langage Delphi lui-même, associé à de nombreuses années de stagnation, disparaît également. Écrire de nouveaux projets avec FireMonkey est « sûr » et tourné vers l'avenir.

Assez de temps s'est écoulé depuis que le terme FireMonkey est devenu plus ou moins familier, sinon pour tous les développeurs, du moins pour ceux qui utilisent Delphi. Pendant ce temps, des livres sur FireMonkey sont apparus, des articles sur FireMonkey, des entrées sur FireMonkey dans de nombreux blogs. Tout cela est très intéressant à lire. Mais aucune théorie ne peut remplacer la pratique. Et moi, comme beaucoup auparavant, j'avais envie d'essayer d'écrire quelque chose avec FireMonkey.

Ce faisant, cependant, un problème s'est posé. Pour une raison quelconque, j'ai décidé que j'avais juste besoin de mettre en œuvre un projet de travail pas très complexe.

Pour expliquer pourquoi cela s'est avéré être un problème pour moi, il faudra une digression (je veux vraiment écrire, lyrique). Une excursion dans mon passé de développeur. Expliquez certains de mes points de vue sur la programmation avec Delphi.

Je dois dire que j'ai commencé à utiliser Delphi sous Windows 3.1, c'est-à-dire dès la première version. Et depuis, j'apprends le VCL. Étudié dans l'original, pour ainsi dire. J'ai regardé, adressé, retracé les sources. Encore et encore.

On sait qu'à plusieurs reprises, l'ensemble des composants livrés avec Delphi incluait des composants tiers qui étaient censés combler les lacunes de la VCL, et qui ont probablement subi un contrôle qualité avant d'être inclus. Certains de ces composants continuent d'être expédiés aujourd'hui. Prenez le même Indy. Je ne veux offenser personne, ceci est purement mon avis personnel, qui s'applique également à moi-même, en tant que développeur de composants : aucun ensemble n'a été aussi profondément pensé et aussi bien implémenté qu'une VCL énorme et diversifiée. Non, je ne prétends pas être la vérité ultime, et, bien sûr, dans la VCL elle-même, il y a beaucoup d'erreurs, de solutions qui provoquent des malentendus, des rejets et avec lesquelles vous voulez être en désaccord. Mais j'ai toujours eu l'impression d'un certain style unifié. Il y a, à mon avis, un beau et solide noyau dans la VCL qui prend en charge l'ensemble de la conception Delphi, et autour duquel à la fois l'infrastructure logicielle et la communauté des développeurs elle-même sont construites. C'est en grande partie grâce à la VCL, encore une fois, à mon avis, les rumeurs sur la mort de Delphi sont encore des rumeurs. Et lorsque des composants tiers ont été inclus dans la livraison de la VCL, cela s'est immédiatement rendu compte qu'ils étaient différents.

Mais le moment arrive, et j'entends dire que VCL est une technologie dépassée. Une technologie à laisser dans le passé. Les développeurs devraient implémenter tous leurs nouveaux projets sur FireMonkey, mais à propos des anciens... ce serait bien de les transférer sur de nouveaux rails. FireMonkey est partout et à tout moment. Et je l'entends de diverses sources. Et assez obstinément. Non, personne ne tue la VCL. il reste avec nous. Mais il n'est pas le numéro un maintenant. Il doit devenir un cascadeur. C'est du moins ainsi que je comprends ce qui se dit sur l'avenir du produit.

En principe, je comprends cet alignement. Le cap est fixé pour le multiplateforme et, plus important encore, pour le multiplateforme. Après tout, qu'est-ce que la VCL ? Bibliothèque de composants visuels. Bibliothèque de composants visuels. On peut être en désaccord avec cela. Par exemple, j'ai toujours considéré beaucoup de composants non visuels, et non des composants, mais juste des classes, une partie intégrante de la VCL, et un grand nombre de classes et de composants tiers - une continuation, une extension de la VCL. Eh bien, je ne peux pas considérer les successeurs de TDataset comme faisant partie de la VCL. Bien que, par exemple, le terme DBExpress Library indique qu'il ne s'agit pas, pour ainsi dire, d'une VCL. Apparemment, Embarcadero divise vraiment le monolithique, de mon point de vue, VCL en un certain nombre de bibliothèques distinctes. Non, bien sûr, pas tout à fait séparés, mais, néanmoins. Et si l'on accepte ce point de vue, FireMonkey est destiné à remplacer la partie visuelle de la VCL (comment dois-je appeler la bibliothèque complète de classes et de composants, peut-être Borland Component Library ?).

Sur quoi sont construits les composants visuels de la bibliothèque ? Autour des éléments basiques de bas niveau fournis par le système d'exploitation. Descripteurs de fenêtre, polices, fenêtres elles-mêmes, éléments d'entrée, messages, contextes de périphérique et bien plus encore - ce ne sont pas des concepts d'une bibliothèque fournie avec Delphi, mais des concepts d'un système d'exploitation. Oui, exactement, Windows. Et si vous voulez construire une bibliothèque multiplateforme, alors il est logique d'abandonner l'infrastructure offerte par le système d'exploitation qui exécute un programme écrit à l'aide de la bibliothèque.

C'est exactement ce que FireMonkey essaie de faire. Ils essaient de créer une infrastructure basée sur les mécanismes sous-jacents pris en charge dans divers systèmes d'exploitation, capable de remplacer le service offert par les systèmes d'exploitation eux-mêmes.

Beaucoup de gens se souviennent d'avoir essayé de fairecross-platform non seulement la bibliothèque, mais aussi Delphi lui-même... Parallèlement à Delphi 6, le produit Kylix et la bibliothèque CLX sont sortis. Tout cela a été fait afin de pouvoir développer pour Linux. Cependant, Linux manque de nombreux concepts de base de l'interface graphique de Windows. L'interface fenêtrée pour Linux n'est pas du tout un phénomène natif. Cette demande est facultative. Et j'ai dû écrire une sorte de bibliothèque synthétique. Avec son aide, il était possible d'écrire un programme pour Windows et Linux. Cependant, je me souviens encore de ce sentiment de non déception, non, plutôt de désagrément gênant que j'ai éprouvé lorsque j'ai essayé d'utiliser les analogues des composants visuels de CLX. J'ai commencé à manquer beaucoup. Ce que je faisais sans réfléchir en développant avec la VCL s'est avéré difficile, complètement différent, voire impossible, avec la CLX.

J'ai ressenti à peu près la même chose lors du passage de BDE à DBExpress. Vieux, familier avec le Field Test BDE (Borland l'utilisait alors déjà dans Quattro Pro pour Windows et Paradox pour Windows, et il s'appelait ODAPI, puis IDAPI, et était un cran au-dessus, à mon avis, l'ODBC de Microsoft) a été déclaré obsolète technologie, qui devrait céder la place dans de nouveaux projets à une nouvelle bibliothèque. Tout le temps, il me manquait quelque chose dans DBExpress au début, en particulier des connaissances.

En même temps, je ne veux en aucun cas gronder ou critiquer ni les bibliothèques énumérées ci-dessus, ni les solutions qui ont conduit à leur apparition. Il ne s'agit que de mes impressions, parfois, des premières impressions.

Maintenant, il devient probablement un peu plus clair pourquoi la décision d'écrire un petit projet de travail en utilisant FireMonkey a posé un certain nombre de problèmes. Au cours de nombreuses années, au cours du développement de projections, de projets et de projets, un certain stéréotype s'est formé, un certain modèle de quoi et comment faire. Et dans mon cas, j'ai dû faire face au fait que le modèle devait être modifié. Parce que vous ne pouvez pas transférer tout ce que vous avez l'habitude d'utiliser VCL dans un projet construit sur FireMonkey.

Au début du projet, j'ai ressenti une certaine impression de déjà vu. A savoir, une sensation d'inconfort. Par exemple, les éléments d'entrée habituels n'ont pas beaucoup de propriétés. Les astuces qui se sont solidement implantées dans la pratique, basées sur des astuces associées à la connaissance de certaines particularités du système d'exploitation, ne passent pas dans le nouveau contexte. Sans oublier que certains des composants ont radicalement changé.

Eh bien, et une autre nuance importante. Quel genre de projets avez-vous généralement à faire au travail, s'il (le travail) n'est pas lié à l'écriture de compilateurs, de systèmes de modélisation ou à autre chose de hautement scientifique ? Je pense que pour la plupart d'entre eux, il s'agit de développer quelque chose lié à l'utilisation de bases de données. De plus, quelque chose de hautement scientifique peut également utiliser les services fournis par le SGBD.

Ici, une autre embuscade m'attendait. Pour une raison quelconque, face au fait que FireMonkey ne contient pas d'éléments axés sur le travail avec les données stockées dans la base de données, vous n'êtes pas tout à fait prêt pour cela (c'est un euphémisme). Bien que j'aie déjà lu plusieurs fois à ce sujet et que vous sachiez (théoriquement) quoi utiliser. Il s'agit de Live Bindings.

Je ne veux pas m'impliquer dans une dispute pour savoir si les vrais programmeurs sympas doivent utiliser ou non des composants compatibles avec db. En pratique, en commençant un nouveau projet, j'ai été confronté au fait : je dois m'habituer à la fois aux nouveaux composants visuels et une nouvelle façon d'extraire des données pour les afficher, les éditer et finalement les sauvegarder. Ce qui, encore une fois, n'est ni mauvais ni bon. C'est juste arrivé comme ça pour moi.

Ceci conclut le post sur les premières impressions. Viennent ensuite les histoires sur ce qui a été surmonté et comment pendant le travail sur le projet.

Vous avez aimé l'article ? A partager entre amis :