03/06/2013 12:46

FireMonkey'de bir tarayıcı bileşeni olmaması nedeniyle çok acı çektim. Ünlü Delphi Chromium Embedded projesi, en son derlemede FMX desteğini içeriyordu. Ancak oldukça fazla zaman geçmesine rağmen, yazar FMX2 desteğini eklemek için hiç acele etmiyor. Sonunda, meseleleri kendi ellerime almak zorunda kaldım.

Resmi derlemedeki TChromiumFMX bileşeni, FireMonkey'de (XE2'de) oldukça iyi çalışıyor, ancak FMX2'de derlenmiyor bile. Nasıl çalıştığını biraz çözmem ve düzeltmem gerekiyordu. Neyse ki, büyük bir değişiklik gerekmedi.

FMX2'de bileşenin ihtiyaç duyduğu iki şey değişti.

Birincisi, TBitmap artık ScanLine ve StartLine özelliklerine sahip değil. TBitmap içeriğine doğrudan erişim yeniden tasarlandı (neden acaba?) ve artık TBitmap.Map yöntemini döndüren TBitmapData sınıfı aracılığıyla kullanılabilir.

Eh, ikinci, daha iyi bilinen - Platform .* artık yok, şimdi TPlatformServices.GetPlatformService aracılığıyla istediğiniz arayüzü almanız gerekiyor. Burada her şey oldukça basit ve hiçbir sorun yok.

Özel bir ustalıkla test etmedim, ancak bileşen benim amaçlarıma oldukça uygun - siteleri onun aracılığıyla görüntüleyebilirsiniz. İndir. Yine de belki düzenlemelerimi yazara gönderirim, belki o bunları resmi sürüme eklemeyi gerekli görür.

30.07.2012 02:43

Jason Southwell, yerel Windows/OSX denetimleri için bir dizi FireMonkey sarmalayıcı geliştirmeyi önerir ve bunun için para toplar. Başlamak için 20.000 $ toplamayı planlıyor.

Fikir açık. Mevcut FireMonkey bileşenleri, Delphi araçları kullanılarak neredeyse sıfırdan çizilir; bu, bir yandan büyük ölçüde çapraz platformlarını sağlar, ancak diğer yandan sonuç olarak, her ikisinde de pek doğal görünmeyen bileşenler elde ederiz. sistemler. Ve bu o kadar da kötü değil - görünüme ek olarak, bu bileşenlerin mantığını bağımsız olarak geliştirmeniz gerekiyor. Örneğin, RichEdit oldukça karmaşıktır ve onun mantığını FireMonkey içinde tekrarlamak önemsiz bir iş değildir. Hem VCL hem de CLX bisikleti icat etmedi, hazır olanları kullandı.

Ve şimdi kötü haber. Her şey çalışma zamanında çalışıyor, ancak yeni sekme tipimi Öğe Tasarımcısına eklemenin bir yolunu bulamadım. Görünüşe göre tüm liste kontrollerinde aynı sorun var: TListBox, TGrid, vb. İlk başta, bunların uygulanmasına yönelik yaklaşımı gerçekten beğendim, ancak şimdi bir şekilde bundan bile şüphe duyuyorum. Bir internet araması, bu sorunla yalnız olmadığımı ortaya çıkardı.

Yardım sessiz, ayrıca kodda hiçbir şey bulamadım. Gerçekten mümkün değil mi? Bu son derece can sıkıcı olurdu.

Delphi, C++Builder ve JBuilder gibi dünyaca ünlü araçların yanı sıra Interbase DBMS'yi oluşturmaktan sorumlu CodeGear bölümünün, veritabanı tasarımı ve yönetimi ile tanınan bir şirket olan Embarcadero Technologies'in bir parçası olmasının üzerinden üç yıldan fazla zaman geçti. araçlar ve iki yıl önce dergimizin sayfalarında Rus geliştiriciler arasında çok popüler olan araçların geliştirilmesinde neler beklenebileceğini tartıştık. Geliştirici İlişkilerinden Sorumlu Başkan Yardımcısı ve Embarcadero Technologies'in Baş Müjdecisi David Intersimone'ye ve Embarcadero Technologies'in Rusya Temsilciliği Başkanı Kirill Rannev'e sorduk. En genç okuyucularımız için, bunun David ve Kirill'in ComputerPress'e verdiği ilk röportajdan çok uzak olduğunu size bildireceğiz - işbirliğimiz ikinci on yıldır devam ediyor. Ve yaklaşık aynı sayıda yıl boyunca, Embarcadero ürünlerine büyük önem verilen veri tabanı yönetim araçlarının incelemelerini periyodik olarak yayınlıyoruz.

Bilgisayar Basın: David, senin bölümün üç yıldır Embarcadero'nun bir parçası. İki yıl önce, amacı ve ruhu size yakın olan bir şirketin parçası haline geldiği için çok heyecanlıydınız. Bu süre zarfında bir şey değişti mi? Siz ve meslektaşlarınız aynı coşkuyu hissediyor musunuz?

Evet, hala heyecanlıyım. Embarcadero şirketinin bir parçası olmamızdan bu yana gerçekleşen ana değişiklik, Delphi'nin geliştirilmesine çok fazla yatırım yapılmış olmasıdır. Geliştirme araçları üzerinde çalışan çalışan sayısı arttı, geliştirebileceğimiz veya gerekirse edinebileceğimiz teknolojilerin sayısı arttı.

Moskova'da göstermeyi planladığımız RAD Studio XE 2'nin piyasaya sürülmesi, Delphi'nin 16-bit Windows ve eski yenilikçi için oluşturulan ilk sürümünden bu yana, büyük yeteneklere ve çok sayıda desteklenen platforma sahip bu ürünün en büyük sürümüdür. bileşen yaklaşımını ve derlemeyi makine koduna bağlayan ürün. Artık sadece Windows için değil, Macintosh için de geliştirmeyi destekliyoruz; mobil cihazlar ve farklı platformlar için bu uygulamalar aynı koda sahip olabilir.

Yeni geliştirme platformu FireMonkey, Embarcadero ile yakın zamanda satın alınan Ulan-Ude merkezli, vektör grafik bileşenleri, DirectX ve OpenGL, grafik efekt teknolojileri ve Delphi bileşenleri üreticisi olan Rus firması KSDev arasındaki bir işbirliğidir. GPU PixelShader 2.0 ile. KSDev'i (bkz. ksdev.ru) bir yıl önce satın aldık ve başladık ortak çalışma uygulama kullanıcı arabirimi oluşturma, veritabanı entegrasyonu, GPU kullanarak grafik işleme ve işletim sistemiyle entegrasyon için Delphi ve C++Buider bileşenlerine sahip FireMonkey uygulama geliştirme platformunu içeren bir çoklu platform geliştirme aracı oluşturmak.

FireMonkey'i kullanarak CPU ve GPU'yu birlikte çalıştıran bir uygulama oluşturabilir ve ardından farklı derleyiciler ve çalışma zamanı kitaplıkları (Çalışma Zamanı Kitaplıkları, RTL) kullanarak bunu Windows, Mac OS veya iOS için derleyebilirsiniz. Delphi ve C++Builder kullanan geliştiriciler, farklı grafik kitaplıkları kullanarak programlama öğrenmek, farklı koordinat sistemleri ve farklı yeteneklere sahip farklı platformlardan API'ler öğrenmek yerine, aynı bileşen yaklaşımını kullanabilir, formları görsel olarak düzenleyebilir ve bileşeni hareket ettirerek veritabanlarına bağlanabilir. fare. Bu, farklı platformlarda çalışan uygulamalar yaratmanın temelde yeni bir yoludur ve geleceğidir. Uygulamanıza diğer işletim sistemleri ve platformlar için destek eklemek istiyorsanız, yeniden tasarlamanız ve geliştirmeniz gerekmez - sadece yeniden derlemeniz yeterli olacaktır.

Yerel kod üreten yeni derleyiciler yaratıyoruz. Bugün 32 bit ve 64 bit için Delphi derleyicileri var. Windows sürümleri 32-bit Mac sürümleri OS 10. Hem bunlar hem de Android veya Linux gibi diğer platformlar için yüksek performanslı yerel kod oluşturmanıza ve aynı tasarımı, aynı bileşenler, farklı derleyiciler ve çalışma zamanı kitaplıkları kullanarak aynı kod.

Gördüğünüz gibi, coşku için yeterince nedenim var. Ve dünya çapında tanıştığım geliştiriciler, Embarcadero'nun PHP geliştirme araçlarının yanı sıra Delphi ve C++Builder'a çok yatırım yaptığını biliyor.

KP: Son iki yılda iki şirketin araçlarını entegre etme konusunda ne gibi ilerlemeler kaydettiniz? Embarcadero'nun bu alandaki gelecek planları nelerdir?

DI.: CodeGear bölümü Embarcadero'nun bir parçası olduğunda, bu şirketin Toronto, Monterrey ve Romanya'da geliştirme ekipleri vardı, biz Scotts Valley'de ve Rusya'da St. Petersburg'daydık ve hala öyleyiz. Embarcadero'nun geliştirici araçları ve veritabanı yöneticileri vardı, CodeGear'ın uygulama geliştirme araçları vardı, ancak ikincisi de veritabanlarını kullanıyor. Şirketlerin birleşmesi, uzmanlık, veritabanları alanındaki bilgi, sunucu kodu dahil olmak üzere kod optimizasyonunun bir kombinasyonudur. Birleşme ayrıca, sıradan bir Windows uygulamasını kullanımı çok kolay bir şeye (iPhone veya diğer cihazlar için uygulamalar gibi) dönüştürmek için özel bir teknoloji olan yeni bir ürün olan AppWave'in yaratılmasıyla sonuçlandı. AppWave, bir uygulamayı yüklemenize izin vermez, ancak onu seçip hazırlanan uygulama depolama (uygulama) sunucusundan çalıştırırken, kullanıcının bilgisayarında kayıt defterinde ve dosya sistemi sistemi alanında değişiklik yapmadan yürütülür. Bu arada, AppWave uygulama tarayıcısı Delphi'de yazılmıştır. Embarcadero, Dephi'yi kendi geliştirmesi ve uygulama geliştirme uzmanlığımız için kullanıyor.

tarafından oluşturulan iPhone uygulaması (iOS)
FireMonkey platformunu kullanma

Uygulamaları oluştururken SQL sorgularını optimize etmek için geliştirme araçlarımızın ve DB Optimizer'ın entegrasyonunu da kullanabilirsiniz. SQL kodunu doğrudan DB Optimizer'a ileterek, onun profilini çıkarabilir, test edebilir ve optimize edilmiş bir sürümünü geliştirme ortamına geri gönderebilirsiniz. Embarcadero'nun veritabanı uzmanlığı DataSnap teknolojisini de geliştirdi. Toronto'daki geliştiriciler sayesinde, çok katmanlı sistemlerin ve veritabanlarının mimarisi hakkında birçok bilgi edindik. Artık her iki şirkette de sunucu kodu ve saklı yordamlar konusunda ortak uzmanlığa sahibiz. RapidSQL ve DB Change Manager gibi araçlara ve SQL içgörüsü ve SQL Tamamlama teknolojileri oluşturmayı mümkün kılan Code Insight ve Code Completion teknolojileri gibi sunucu tarafı kod oluşturmayı kolaylaştıran geliştirme ortamlarına sahibiz. İstemci ve sunucu kodu oluşturmaya yönelik ortak yaklaşımımız, ortak felsefemiz, veritabanı yönetim araçları ile uygulama geliştirme araçları arasında ortak özellikleri paylaşmamıza olanak tanır.

Kirill Rannev:Önemli bir şey eklemek istiyorum. Ticari bir bakış açısıyla, takımlarımızı nasıl teslim ettiğimiz çok önemlidir. Örneğin, RAD Studio XE 2 Ultimate'ın yeni sürümü, DB Power Studio araçlarının tümünü içerir. RapidSQL sorgu yazma ortamı, DB Change Manager değişiklik yönetimi aracı ve DB Optimizer sorgu optimizasyon aracı dahil olmak üzere, geliştirme ve devreye alma sürecinin önemli bir bölümünü gerçekleştirmenize, değişiklikleri yönetmenize olanak tanıyan çok güçlü bir araç setidir. veri modeli, veritabanı, kod vb. Bu, teknolojilerin çok iyi ve doğru bir kombinasyonudur.

DI.: Ancak gerekirse, geliştiriciler kaynak kodu sürümlerini yönetmek için Subversion'ı ve meta veri sürümlerini yönetmek için DB Change Manager'ı kullanabilir. Sunucu kodunu optimize etmek için kod profili oluşturmayı ve DB Optimizer'ı, sunucu kodunu oluşturmak ve hata ayıklamak için RapidSQL'i ve uygulama oluşturmak ve hata ayıklamak için geliştirme ortamlarımızı kullanabilirsiniz. RAD Studio XE'deki bu teknoloji kombinasyonu Nihai Sürüm Veritabanı ve uygulama geliştirme modelleri arasındaki paralellikleri gösterir. Delphi ve C++Builder ile iş uygulamaları oluşturan çoğu geliştirici, veritabanlarıyla çalışır ve bu araçlara ihtiyaç duyar ve RAD Studio XE Ultimate Edition, bu geliştiriciler için harika bir kombinasyondur.

KP: Modern kullanıcı artık yalnızca Windows platformunun bir kullanıcısı değildir. Mobil cihazlar, iPhone, iPad, Android platformuna dayalı cihazlar kullanıyoruz. Bu, geliştiricilerin eğitim yatırımlarında önemli bir artış olmadan farklı platformları hedeflemeye başlamaları gerektiği anlamına gelir - yani evrensel araçlara ihtiyaç vardır. Açıkçası, evrensel araçların ortaya çıkmasını platform üreticilerinden beklemek gerçekçi değildir ve bu konuda yalnızca bağımsız araç üreticilerine güvenebiliriz. Embarcadero'ya nerede güvenebiliriz?

DI.: Platform desteği alanında daha yapacak çok işimiz var. Bugün iPhone ve iPad için iOS platformu desteğini ve ardından Android, Windows 7 ve Blackberry akıllı telefonları için desteği kullanıma sunuyoruz. RAD Studio XE 2'de, iOS için FireMonkey platformunu oluşturarak başladık ve daha sonra FireMonkey'i diğer platformlara taşıyacağız.

Aynı zamanda, destekleyen çok sayıda işletim sistemi vardır. dokunmatik ekranlar(dokunmatik ekran), telefonlar için, tablet bilgisayarlar ve cihazlar, masaüstleri ve onlar için destek eklemeye devam edeceğiz. Ayrıca ses kontrolü, hareket, biyometrik sistemler, ivmeölçerler, bu nedenle tüm geliştiricilerin yeni platformlardan yararlanabilmesi için FireMonkey'i genişletmeye devam etmeliyiz. Örneğin, Microsoft Kinect cihazı Xbox 360 için tasarlanmıştır ve şimdi Windows için karşılık gelen bir SDK (Yazılım Geliştirme Kiti) bulunmaktadır. Ve zaten bir uygulamayı kontrol etmek için hareketi, normalde fare veya klavye kullandığımız şekilde kullandığımız örneklerimiz var.

Çok sayıda karmaşık grafik içeren uygulamalar oluşturduğunuzda, yeni kullanıcı arayüzlerinden oluşan bir dünya yaratırsınız. Windows işletim sistemiyle uğraşıyorsak, Windows API'sini VCL kitaplığında (Visual Component Library - Delphi ve C ++ Builder geliştirme araçlarının ayrılmaz bir parçası olan görsel bir bileşen kitaplığı) içine alırız. Not. ed.), bu arada, daha fazla uygulanabilir. Ve FireMonkey'de, işletim sistemi API'sini özetliyoruz. Ancak bugün formları ve grafikleri çok daha geniş çapta manipüle ediyoruz. Animasyon ve özel efektler için fiziksel alan özellikleri de ekleyebilirsiniz. Ayrıca, başka birçok Ek özelliklerönümüzdeki birkaç yıl içinde farklı platformlar, mobil ve tablet cihazlar için hayata geçireceğimiz kullanıcı arayüzleri oluşturmak.

Microsoft kısa bir süre önce, bir yıl içinde çıkması beklenen Windows 8 ile ilgili ayrıntıları yayınladı. Bu yenilikleri VCL kitaplığında ve FireMonkey platformunda destekleyeceğiz. Ancak Delphi, yalnızca Windows için değil, Macintosh, iPhone ve iPad için de tasarlanmış bir geliştirme aracıdır. Ayrıca PHP ürünlerimizi geliştiriyor, jQuery Mobile'ı destekliyoruz, mobil istemci uygulamaları geliştirmek için iOS API'sini kullanıyoruz ve istemci tarafı JavaScript, HTML ve Basamaklı Stil Sayfaları oluşturmak için sihirbazlar ve araçlar kullanarak PHP sunucu uygulamaları oluşturuyoruz. Şuradan paketler oluşturabiliriz: PHP uygulamaları ve yerel kodlu istemci uygulamaları iPhone iOS, böyle bir istemci ise PHP sunucusuyla iletişim kuracaktır. Ve bu da, veritabanı sunucusuyla ve web hizmetleriyle - iş için gereken her şeyle - iletişim kuracaktır.

RadPHP XE2 geliştirme ortamı. Bir mobil web uygulaması oluşturun
iPhone 3G için jQuery Mobile bileşenlerini kullanma

Başka bir deyişle, mobil platform desteği de dahil olmak üzere FireMonkey ve VCL'nin yeteneklerini genişletmeyi planlıyoruz.

KP: FireMonkey platformu hakkında daha ayrıntılı bilgi verebilir misiniz?

DI.: Daha önce de belirttiğim gibi, Windows için oluşturulan VCL kitaplığı gelişmeye ve gelişmeye devam edecek. Ancak bugün, gerçekten iş uygulamaları geliştirmek istiyorsanız, bunları farklı platformlar için oluşturmalısınız. FireMonkey platformu bunun için tasarlanmıştır. Yüksek çözünürlüklü kullanıcı arayüzlerinin, yüksek performanslı 3D grafiklerin, yüksek kare hızlarının oluşturulmasını destekler ve daha da önemlisi, bunu yapmak için bir GPU kullanır.

Bilimsel, mühendislik ve iş uygulamaları oluştururken bu özellikleri kullanabilirsiniz. Bu tür uygulamalar dbExpress teknolojisini kullanarak veritabanlarına bağlanabilir, yine de ClientDataSet veya DataSource gibi geliştiricilerin aşina olduğu görsel olmayan bileşenleri kullanır, DataSnap teknolojisini kullanır, herhangi bir veri tabanına, SOAP ve REST sunucularına bağlanabilir. Çekici kontroller, kutulu düğmeler, sıra dışı tablolar ve diğer arayüz öğelerini iki ve üç boyutlu olarak oluşturabilirsiniz. Hazır bir 3D modeli uygulamaya yükleyebilir ve onu döndürülerek farklı açılardan görülebilen 2D bir şekil ile birleştirebilirsiniz. Bir veri küpü veya 3B iş grafiği oluşturup farenizi, klavyenizi ve hatta bir Kinect cihazını kullanarak döndürebilir veya küpün içine girip farklı yüzeylerine içeriden bakabilirsiniz. Ve tüm bunlar yüksek hızlı bir GPU ile yapılabilir. Aynı uygulama daha sonra Mac OS gibi başka bir platform için derlenebilir.

Veri içeren dönen bir küp içeren uygulama,
kenarlarına yerleştirilmiş

Veya sıfırdan bir 3B şekil oluşturabilir ve kullanıcı arayüzünün bazı kısımlarını aydınlatmak ve döndürmek için kameralar ve ışıklar kullanabilirsiniz. Form tasarımcısı, 3B kullanıcı arabirimini doğrudan tasarım zamanında desteklemek için zaten yerleşik bir ortama sahiptir.

Windows'ta, yüksek çözünürlüklü 2B grafikler için Direct2D kitaplıklarını ve 3B grafikler için Direct3D'yi kullanabilirsiniz. Mac OS, Quartz ve OpenGL kitaplıklarını aynı amaç için kullanır. iOS için, Quartz ve OpenGL ES kitaplıkları kullanılır. Ancak tüm bunlar geliştiriciden gizlenir - bu kitaplıkları düşünmeden FireMonkey platformunu, onun koordinat sistemini ve uygulama programlama arayüzünü kullanır ve aynı uygulamayı farklı platformlar için derleyebilir.

VCL'nin ne olduğunu hatırlayalım. VCL, Windows API çevresinde bir bileşen "sarmalayıcı"dır. Kaynaklar, menüler, diyaloglar, renkler, stiller, Windows mesajları. VCL'den farklı olarak çok platformlu bir sarmalayıcı olan FireMonkey, aynı olay ve bileşen modellerini koruyarak olaylar açısından düşünmenize olanak tanır (örneğin, OnClick, OnHasFocus, onMouseDown ve onKeyDown olayları), ancak Macintosh veya iPhone olaylarını yönetir.

FireMonkey platformu ayrıca komple sistem kullanıcı arabirimi öğelerinin animasyonu. Kesinlikle kapsamlı bir Pixar tarzı animasyon sistemi değildir, ancak bitmap'leri canlandırma, bir kullanıcı arayüzü öğesinin odağını vurgulama ve vektör grafikleriyle çalışma gibi efektleri uygulamanıza izin verir. Geliştiricinin 50'den fazla uygulamaya erişimi var görsel efektler: bulanıklık, siyah beyaz, çözünme, geçişler, yansıma, gölgeleme - modern grafik işlemcilerde bulunan ve artık hemen hemen her bilgisayarda bulunan tüm efekt türleri. FireMonkey platformu kullanılarak oluşturulan bir uygulama, grafikleri görüntüleme ve kullanıcı arabirimini oluşturma işini yapan GPU'ya komutlar gönderir. Aynı zamanda, merkezi işlemci hesaplamalar ve işletim sistemine erişim için ücretsizdir. Geliştiricinin yalnızca bileşenleri doğru şekilde yerleştirmesi gerekir.

FireMonkey platformuyla ilgili en temel şey, kullanıcı arayüzünü oluşturma şeklidir. Menüler, düğmeler ve kaydırma çubukları gibi arabirim öğelerine bitmap grafikleri yerleştirmek için olanaklar vardır. FireMonkey'de bu amaçla GPU vektör grafikleri kullanıyoruz. Programlama açısından, bunların hepsi aynı kontrollerdir, ancak grafik işlemcisi bunları görüntüleme işini yapar. Kontrollere stiller uygulayabilir, bir uygulamayı Mac OS veya Windows için bir uygulama gibi gösterebilir, kendi stilimizi oluşturabilir, stillerimizi arayüz öğelerine uygulayabiliriz (örneğin, form düzenleyicide stilini değiştirerek bir düğmeyi dikdörtgen veya yuvarlak hale getirebiliriz) - bunun için geliştirme ortamının bir stil düzenleyicisi vardır. Kendi stilinizi oluşturabileceğiniz gibi bitmiş bir uygulamanın stilini de değiştirebilirsiniz.

FireMonkey Platformu - Geliştirme Araçları
ve desteklenen platformlar

Hatırlarsanız, VCL kitaplığında sınırlı sayıda denetim vardı - kaplar (yani, içlerine başka öğeler yerleştirmenize izin verir) ve FireMonkey'de her denetim bir kaptır. Bu, her kontrolün başka herhangi bir kontrolü içerebileceği anlamına gelir. Örneğin, açılır liste öğeleri resimler, düğmeler, düzenleme kutuları ve diğer kontrolleri içerebilir. Ayrıca bileşenleri katmanlara da yerleştirebilirsiniz.

FireMonkey işleme sistemi oldukça esnektir - GPU'ya komutlar göndererek Direct2D, Direct3D ve OpenGL kitaplıklarını kullanabilir. Aynısını VCL'de elde etmek için, ayrı bir ekran dışı arabellek oluşturmak, bunun içinde uygun grafik kitaplığı işlevlerini çağırarak bir görüntü oluşturmak ve ardından onu formda görüntülemek gerekiyordu.

FireMonkey tarafından desteklenen grafik efekt örnekleri

GPU'nuz yoksa, yine de 2B veya 3B şekiller uygulayabilir ve FireMonkey kontrollerini kullanabilirsiniz. Bu durumda FireMonkey platformu, GDI+ kitaplıklarını veya diğer benzer kitaplıkları kullanacak ve 3B nesnelerin aynı efektlerini ve animasyonunu veya manipülasyonunu gerçekleştirecektir.

FireMonkey'in diğer bir özelliği de arayüz öğelerini verilere bağlamak için açık ve esnek yeni bir sistemdir. VCL'de iki tür arayüz öğesi vardır: veriye bağlı ve veriye bağlı olmayan (örneğin, TDBEdit ve TEdit). FireMonkey'de her kontrol, her türden veriyle ilişkilendirilebilir. Bu yalnızca bir ifade, bir veri kümesinden bir alan, geliştirici tarafından oluşturulan nesnelerden gelen veriler veya yöntem çağrılarının sonuçları olabilir.

Ek olarak, bir uygulama oluştururken, içine hazır bir 3B model yükleyebilir ve kullanabilirsiniz - bu tür yetenekler genellikle hem iş hem de mühendislik uygulamalarında gereklidir. Lojistik için uygulamalar oluşturan bir müşterimiz var. Delphi ile oluşturulmuş bir bilgi sistemlerine ve bunun içinde bir plan çizen ve veri kaynaklarından bilgileri görüntüleyen bir uygulamaya sahiplerdi. Yakın zamanda ilginç bir şey yaptılar - AutoCAD'de tam otomatik bir 3B depo çizdiler ve uygulamaları, otomatik bir yükleyicinin depoda nasıl hareket ettiğini ve ürünleri raflara nasıl yerleştirdiğini görmenizi sağlıyor. Ve ilgili görüntüdeki kaynaklardan gelen verileri düzenlerler.

Değişen Uygulama Tarzlarına Örnekler

KP:Şu anda hangi 3B model biçimleri destekleniyor?

DI.: Bu sürümde, AutoCAD, Collada'dan (açık kaynaklı bir 3D modelleme aracı) model yüklemeyi destekliyoruz. - Not. ed.), Maya, birçok 3D grafik satıcısı tarafından desteklenen bir OBJ formatı.

KP: Başka hangi formatların eklenmesi planlanıyor?

DI.: 3DS (3D Studio MAX), SVG (genellikle bu format 2D vektör grafikleri için kullanılır, ancak bazen 3D için kullanılır), Google SketchUp'ı eklemeyi planlıyoruz. Diğer formatları da destekleyebiliriz.

KP: 3B modellerin FireMonkey ile oluşturulan uygulamalarda kullanılması, uygun 3B modelleme aracı için bir lisans gerektirir mi?

DI.: Hayır, değil. Tek yaptığımız model dosyasını okumak. Modeli içe aktarıyoruz ama dışa aktarmıyoruz (tabii ki modeli kendi formatınızda kaydeden bir uygulama yazabilmenize rağmen). 3D modelleme araçları üreticisi olduğumuzu iddia etmiyoruz - bunun için AutoCAD, 3D Studio Max, Maya veya başka bir 3D modelleme aracı kullanabilir ve oluşturulan modelleri uygulamalarımıza aktarabilirsiniz.

KP: Modern donanım platformlarında FireMonkey ile oluşturulan uygulamalar ne kadar başarılı?

DI.: Performans oldukça yüksektir. Örneğin, üç küre ve üç ışıktan oluşan bir 3B şekil, bir MacBook Pro'da saniyede 100 kare hızında oluşturulabilir. Ve 600'e ulaşabilir - tam olarak ne yaptığımıza bağlı. Yine, hepsi GPU'nun gücüne bağlıdır.

KP: Bu, FireMonkey'in yardımıyla modern gereksinimleri karşılayan oyunlar oluşturabileceğiniz anlamına mı geliyor?

DI.: Geliştirme araçlarımızı oyunlar için bir araç olarak konumlandırmıyoruz. Bununla birlikte, modern GPU'ların yüksek performansını kullanarak FireMonkey ile oyunlar da oluşturabilirsiniz - sonuçta bunlar Direct3D veya OpenGL kullanılarak oluşturulur.

KP: Jest tanıma ve diğer yeni çıkmış şeyler için destek alanında şu anda ne gibi işler yapıyorsunuz? Böyle bir destek mevcut mu?

DI.: Bu sürümde henüz hareket desteğimiz yok. Hareket kontrolü, FireMonkey'in gelecekteki bir sürümünde eklenecektir, ancak şimdilik, işletim sisteminde yerleşik olarak bulunan hareket desteğini kullanabilirsiniz.

Fast Reports, Inc.'in direktörü Mihail Filippenko

KR: FireMonkey teknolojisinin Rus kökleri olduğunu zaten söylemiştik - temelleri ülkemizde atıldı ve ardından teknolojinin kendisi ve geliştiricileri Embarcadero'da birleşti. Genel olarak, RAD Studio ve Delphi'de Rus bileşeninin büyümesini görmek memnuniyet verici. Bu, St. Petersburg'daki geliştirme merkezimizin etkinliği ve bağımsız Rus geliştiricilerin katkısıdır. Örneğin, Rad Studio XE2, tüm dünyada bilinen ve ülkemizde çok popüler olan FastReport rapor oluşturucuyu içerir. O Rostov-on-Don'lu.

KP: Derleyicilerden bahsetmek istiyorum. iOS uygulamaları oluşturmak için hangi derleyici kullanılır?

DI.: iPhone veya iPad için kendi Delphi derleyicimiz yok - bu cihazlarda kullanılan ARM işlemciler için henüz derleyiciler geliştirmedik. iOS için geçici olarak Free Pascal derleyicisini ve çalışma zamanı kitaplığını kullanıyoruz. Ancak ARM işlemciler de dahil olmak üzere yeni nesil derleyiciler üzerinde çalışıyoruz. Ancak, her iki donanım platformu da Intel işlemcilere dayalı olduğundan, Windows ve Mac OS için derleyiciler vardır.

KP: Ve son iki yılda derleyici geliştirme alanında neler yapıldı?

DI.: Windows ve Mac OS için 32 ve 64 bit Delphi derleyicilerimiz var. Ve yeni nesil Delphi ve C++ derleyicileri üzerinde çalışıyoruz. Bunlarla ilgili çalışmalar devam ediyor, ancak tamamlandığında ARM işlemciler, Android platformları, Linux vb. için Delphi derleyicilerimiz olacak. Windows ve diğer platformlar için uyumlu 64-bit C++ derleyicilerimiz olacak. en son standart C++ dili ISO tarafından yeni kabul edildi.

KP: Günümüzde Embarcadero geliştirme araçlarındaki bulut bilgi işlem desteğinde neler oluyor?

DI.: RAD Studio XE 2 ile, Platform Assistant'ı kullanarak uygulamaların Microsoft Azure veya Amazon EC2 bulutuna taşınmasını destekliyoruz. Tabloları, ikili verileri ve mesaj kuyruklarını depolamak için Azure ve Amazon S3 için Bulut Depolama için sunucu bileşenlerimiz var. İÇİNDE önceki versiyon RAD Studio XE'de, uygulamaların Amazon EC2'ye dağıtılmasını da destekledik, ancak depolama desteği yoktu.

RAD Studio XE 2'de bulut bilgi işlem desteği

KP:İki yıl önce yeni Tam Erişim çözümünden bahsetmiştiniz. Ne kadar talep gördü? Sistem entegratörleri ve geliştiriciler için faydaları nelerdir?

DI.: Tam Erişim çözümü ve AppWave bulut aracı dünya çapında yaygın olarak kullanılmaktadır. Hem şirketimizin hem de üçüncü taraf uygulamalarının kullanımını kolaylaştırmak için tasarlanmıştır. Aslında bu, lisansları ve uygulamaları yönetmek için bir çözümdür ve büyük şirketler için uygundur. Özel bir uygulama yönetim ekibine sahip olmayan daha küçük firmalar, uygulamayı bir havuza koyabilir, bir veritabanından kullanıcı adlarını seçebilir ve lisans anahtarının nerede olduğunu ve kaç lisans olduğunu hatırlamak zorunda kalmadan bu uygulamaları kullanılabilir hale getirebilir. Tam Erişim ve AppWave tarayıcı, hem sürüm oluşturmayı hem de erişim kontrolünü yönetmek için tasarlanmıştır.

KR: Pazar o kadar çeşitli ve kullanıcılar o kadar farklı ki, tüm ihtiyaçları tek bir çözümle karşılamak imkansız. Bu nedenle, çeşitli "paketleme" çözümleri için çalışıyoruz. Lisanslamayı, lisans yönetimini ve ürün kurulumunu birleştirmek için birçok çalışma yaptık. Bu çözümler, yalnızca Embarcadero ürünleri için değil, aynı zamanda şirketlerin dahili geliştirmeleri de dahil olmak üzere diğer tüm ürünler için lisans ve erişim yönetimi araçlarını içerir.

Geliştirme araçlarını etkin kullanıcı kitleri halinde bir araya getirme çalışmaları halen devam etmektedir. Tüm Embarcadero ürünlerini birleştiren bir süper set olan All-Access'e sahibiz. Müşteri, Tam Erişim Platin sürümünü satın alırsa, Embarcadero'daki tüm araçları alır. Ancak bazen bu setin gereksiz olduğu ortaya çıkıyor, örneğin, veritabanı uzmanları için iki set daha yaptık - DB Power Studio Developer Edition ve DB Power Studio DBA Edition. Aralarındaki fark, geliştirici için bir sunucu kodu geliştirme aracı olan RapidSQL'i sunmamız ve yönetici için RapidSQL'den daha geniş bir ürün olan bir veritabanı yönetim aracı olan DBArtizan'ın yerleşik olmasıdır. Profesyoneller için şu Tam Erişim paketlerine sahibiz: tüm ürünleri içeren paket, geliştiriciler için DB Power Studio, yöneticiler için DB Power Studio, mimarlar ve modellemeye dahil olan herkes için ER Studio Enterprise Edition. Uygulama geliştirme ve yöneticiler için kombinasyonlar vardır. Delphi bir geliştirici aracıdır ve ona SQL geliştirme araçları ve optimizasyon araçları eklemek çok mantıklıdır. Son olarak, DB Change Manager, yaşam döngüleri boyunca veritabanlarında meydana gelen değişikliklerin karmaşıklığını yönetmek için çok mantıklı bir araçtır.

Bu nedenle, Tam Erişim, farklı ürün setlerinden oluşan geniş bir ailenin başıdır.

KP: Bu bir sır değilse, Rusya'da kim Tam Erişim kullanıyor?

KR: Delphi tabanlı All-Access satın alan müşterilerimiz var. Birçoğu, SQL Server ve Oracle ile karmaşık istemci-sunucu sistemleri kuruyor ve platformlar arası veritabanı araç setimizi hemen beğendiler. İlk sürümden beri Delphi ile çalışan ve bir yıl önce Delphi'den Tam Erişim'e geçen bir müşteri şirketimiz var. Bu şirketteki tüm geliştiriciler tarafından kullanılması garanti edilen iki araç Delphi ve DBArtisan'dır. Bir de veri tabanı tarafından Tam Erişim'e gelen müşteriler var. Birincil işleri veritabanlarını yönetmektir, ancak bazen uygulamalar da geliştirirler. Tam Erişim kullanan müşteriler arasında medya şirketleri, makine üreticileri ve diğer sektörler yer alır.

Ayrı olarak, küçük şirketler üzerinde durmak istiyorum. Çoğu zaman küçük ekiplerde geliştirici her şeyi yapar ve böyle bir şirket bazen bir veya iki geliştirici için büyük Tam Erişim yiyecek paketleri satın alır. Büyük ekiplerde, geliştiricinin aynı zamanda bir veritabanı yöneticisi rolünü de üstlenmesi teşvik edilmez, bu nedenle küçük gıda paketleri genellikle orada popülerdir ve küçük şirketlerde bu görev kombinasyonu oldukça kabul edilebilir.

Delphi Architect, modelleme ve programlama araçlarını içeren, yoğun bir şekilde pazarlanan bir üründür. Ancak satılan kopya sayısı Delphi Enterprise sürümlerine göre daha azdır, ancak aynı zamanda büyüktür. 2010 yılında, tüm ülkeler krizden çıkmış olmasına rağmen, satış açısından en iyi ülke olduğumuzu not ediyorum. Bu büyüme, ekonomik faktörlerden çok, 2009'un sonunda piyasaya sürülen RAD Studio XE versiyonunun büyük talep görmesinden kaynaklandı. Ve satışlarda daha fazla büyüme beklerken.

Rusya'da çok talep gören makul bir adım daha attık. Ürünlerimizin farklı sürümlerinin yasallaştırma derecesi farklıdır: sürüm ne kadar yüksekse, o kadar yasaldır, çünkü daha önce yazılımçok aktif olarak satın alınmadı. RAD Studio XE ile başlayan lisans, 2010, 2009, 2007 sürümlerini ve hatta yaygın olarak kullanılan bir ürün olan Delphi 7'yi kapsar.

Günümüzde geliştiriciler, hem yeni projelerine hem de destekli durumdaki projelere sahip oldukları gerçeğiyle karşı karşıyadır. Çok sayıda proje Delphi'nin ilk sürümlerinden sürüm 7'ye taşınmıştır ve bu sürümde kalarak nispeten küçük kaynaklar üzerinde çalışmaya devam etmektedir. Hiç kimse onları daha yeni sürümlere taşımıyor, ancak bunlar geçerliliğini koruyor. Ve şimdi hem RAD Studio XE'yi hem de Delphi 7'yi almak için çok az paraya (Delphi 7 lisansının fiyatından daha az) izin veriyoruz - yani, geliştiriciyi hem yeni projelerin uygulanması hem de destek projeleri için yasallaştırıyoruz.

KP: Embarcadero topluluğunun mevcut durumunu nasıl değerlendiriyorsunuz?

DI.: Bu topluluk büyük ve çok talepkar. Her şeye ihtiyaçları var ve hemen - geliştiriciler. Ama bazen bir şeyi doğru yapmak uzun zaman alır.

Birkaç yıl önce Windows bileşen mimarisini alıp Linux masaüstlerine yerleştirdik. Şimdi bunun doğru bir karar olmadığını görüyoruz. Doğru karar, uygulamalar için bir platform oluşturmaktır. Farklı platformlar için bile uygulamaların menüleri, pencereleri, grafikleri, ağ erişimi ve cihazlara erişimi vardır. Farklı platformların farklı akış kontrolü veya istisna işleme modelleri olabilir, ancak uygulama kodunda aynı try bloklarını görüyoruz. İşimiz, ilgili işlemcilerin komut sistemi nasıl düzenlenirse düzenlensin ve bu platformların diğer özellikleri ne olursa olsun, geliştiricilerin iş uygulamaları oluşturmasını ve bunları kullanılması gereken platformlar için derlemesini kolaylaştırmaktır. Ve FireMonkey, bu sorunu çözmek için tam da ihtiyacınız olan şey.

KP: Bir şirket yeni bir cihaz oluşturursa ve bunun için FireMonkey desteği almak isterse bu mümkün olur mu?

DI.: Platformdan bağımsız front-end ve platform-bağımlı back-end'e sahip olacak yeni nesil derleyiciler ile bu oldukça mümkün olacaktır. Bu arada her işletim sistemi için sıfırdan bir derleyici ve çalışma zamanı kitaplığı oluşturuyoruz.

Herhangi bir modern yeni cihazda genellikle bir grafik kullanıcı arabirimi (çoğunda çift çekirdekli işlemci ve GPU bulunur) ve geliştiriciler için standart SDK'lar bulunur. Tüm bunlar, FireMonkey'de cihaz desteği oluşturulmasını basitleştirir. Yeni cihazda Quartz gibi yalnızca 2B grafikler için kitaplıklar varsa, FireMonkey'de böyle bir cihazı destekleyebileceğiz, ancak bu yaklaşık olarak birkaç ay sürecektir. Bununla birlikte, pek çok şey platforma bağlıdır: tüm platformlar tüm özellikleri desteklemez, örneğin, iOS'ta menüler ve iletişim kutuları yoktur ve ilgili bileşenleri bu tür uygulamaların formlarına yerleştiremezsiniz.

KP: Ortaklarla çalışma politikasında herhangi bir değişiklik oldu mu? Ürünlerinizin kullanıcı payını artırmak için neler yapılıyor? Rusya'da ne yapılıyor?

DI.:İş ortağı ekosistemimiz geniştir - ürünlerimizde bulunmayan yüzlerce araç ve bileşen üreticisi vardır ve bir teknoloji ortaklık programımız vardır. Bu nedenle, geliştiriciler için çok çeşitli bileşenler, teknolojiler ve araçlar mevcuttur. Ve müşterileri için ürettikleri çözümler, sadece bizim ürünlerimizin kullanılmasından daha iyidir. Ve satış için birçok ülkede ofislerimiz, bayilerimiz ve distribütörlerimiz var.

KR: Bizim için önemli olan ortak sayısı değil, her bir ortağın iş kalitesidir. Şimdilik, ortak havuzu açık olsa da, mevcut ortaklarla yakın çalışmaya odaklanmak istiyoruz. Birçok ortağımız var ve onlara teknoloji açısından yardımcı olmalıyız. Geliştiricilerle çalışıyoruz ve onlar ne istediklerini ve piyasada neyin mevcut olduğunu biliyorlar ve ortakların yetenekleri buna uygun olmalıdır.

Bir iş kolu olarak Embarcadero'ya büyük yatırımlar yapmış iş ortaklarımız var - eğitimli uzmanlara, ürünlerimizin pazarlanmasına, bu alandan sorumlu olan ve ürünlerimize, fiyat listemize, pazarlamaya ne olduğunu izleyen özel çalışanlara sahibiz. Doğal olarak ürünlerimizin satışında, ürünlerimizi tek tek satan firmalara göre daha başarılılar.

KP: David, Kirill, ilginç röportaj için çok teşekkür ederim. Yayınımız ve okuyucularımız adına, şirketinize, geliştiricilerin çok ihtiyaç duyduğu harika araçlarınızı yaratmada başarılarının devamını diliyorum!

Sorular Natalia Elmanova tarafından soruldu

FireMonkey, "yeni Delphi"nin temel teknolojisidir. Lütfen bize temelde yeni olan bu kitaplığın amaçlarından, yeteneklerinden ve teknik yönlerinden bahsedin. Bir süre sonra geriye dönüp baktığınızda, süper popüler VCL'yi daha fazla geliştirmeyi reddetmeniz ne kadar zor ve haklıydı?

Belirli bir hedefe ulaşmak için Delphi teknolojisinin geliştirilmesinde ana yön olarak seçildi - tek bir kaynak kod tabanına dayanan ve geliştiricilerin radikal bir şekilde yeniden eğitilmesine gerek kalmadan tek bir ortamdan çok platformlu geliştirme. Artık klasik ve son derece popüler olan VCL çerçevesinde bu imkansızdı, WinAPI ile bağlantısı çok yakındı, "genetik düzeyde" denebilir.

VCL bileşenleri, arayüz ve eşleme mekanizmaları açısından işlevsel düzey arasında "soyut" bir katmana sahip değildi. fonksiyonel seviye- bir kontrol olarak nasıl davrandığı, hangi olaylara tepki verdiği, ne tür bir kullanıcı etkileşimi sağladığı. Görüntülemek- raster nesneler ve vektör ilkellerinden oluşan bir tür görüntü olarak platform yönelimli oluşturma yöntemlerini çağırmak. FireMonkey, başlangıçta denetimi kesin olarak iki bileşene ayırma ilkesini uyguladı: "davranışsal" ve "görsel".

Vsevolod Leonov, Embarcadero Teknolojileri

İlki bir bütün olarak VCL'nin temellerini bile değil, nesne yönelimli programlamanın özünü tekrarlayacaktır. Bileşen bir sınıftır, bileşen sınıfları, ailelerin ve modüllerin ayırt edilebildiği bir hiyerarşi oluşturur. Bir bileşenin sınıfının, nasıl işlendiğiyle çok az ilgisi vardır.

Görsel "resim" dinamik olarak oluşturulur, bileşen sınıfında sabit kodlanmaz. FireMonkey'deki bir görüntü veya "stil", uygulama başladığında bir bileşene yüklenir. Bileşen için bir tür işlevsel çerçevemiz var ve "dış görünüm" veya "kaplama" değiştirilebilir, ama neden? Bu nedenle FireMonkey uygulamaları tüm platformlarda - Windows 7, Windows 8, Mac OS, iOS ve yakın gelecekte Android - orijinal görünür. Geleneksel yekpare VCL sınıf yapısı bunu sağlayamıyordu.

Burada teknolojik yaklaşım özel bir rol oynar. Prensip olarak, VCL kitaplığını alabilir ve WinAPI'yi diğer tüm olası platform çağrılarıyla "doldurabilirsiniz". Çok sınırlı bir bileşen alt kümesinde, bu yine de yapılabilir, ancak VCL birkaç yüz bileşen içerir, bu nedenle bu yaklaşım VCL'yi basitçe "öldürebilir". VCL'ye dokunmamaya ve yeni platform olan FireMonkey'de yeni özellikler geliştirmeye karar verildi. Bu teknolojinin belirli bir teknik zarafeti bile vardır - belirli bir platform için bir projenin montajı sırasında, Delphi IDE gerekli derleyiciyi bağlar ve arayüz bileşenleri bir platform stili alır.

Kullanıcı için bu, tek bir fare tıklaması ve aynı kaynak kodudur, Delphi için geliştiricilerin böyle bir çok platformlu kitaplık oluşturmak için yıllarca süren sıkı çalışmasıdır.

FireMonkey'in ayrı bir yeni platform olarak tanıtılacağı netleştiğinde, doğru bir arada yaşama stratejisinin seçilmesi gerekiyordu: Embarcadero, VCL kullanıcılarını hiçbir şekilde olumsuz etkilemek istemiyordu. Bu nedenle, aşağıdaki planı seçtik: VCL, projelerin modern sürümlere geçişini kolaylaştırırken mümkün olan en yüksek uyumluluğu sağlamak için ideolojik ve mimari olarak kararlı kalır. FireMonkey'in gelişimi, VCL'ye bakmadan doğal ve paralel bir yol izleyecektir.

Bu çözümün zayıf noktası, tek bir proje içinde VCL'den FireMonkey'e oldukça sorunlu geçiştir. Ancak öte yandan, yeni bir proje için bir geliştirici, ortaya çıkan uygulamasının çok platformlu doğasını sağlamak için FireMonkey'i seçebilir. iOS destekli XE4'ün piyasaya sürülmesiyle, Delphi'nin kurumsal ortamda mobil geliştirme için güçlü rekabet avantajından bahsedebiliriz ve bu avantaj, Android için planlanan desteğin uygulanmasından sonra artacaktır.

Bu nedenle, bu haliyle, VCL'nin geliştirilmesinden açık bir "reddetme" yoktur. Yeni sürümlerde Delphi'nin VCL kısmı da geliştirilmektedir. Buna 64-bit desteği ve görsel bileşenler için stilin tanıtılması ve esnek dinamik bağlantılar veya "bağlama" için bir mekanizmanın uygulanması ve VCL projelerinde veritabanlarıyla çalışmak için FireDAC kitaplığının dahil edilmesi dahildir. Sadece, FireMonkey'den kaynaklanan dev bir niteliksel sıçramanın zemininde, VCL'deki ilerleme bir şekilde tezahür etmemiş görünüyor. Ancak ne olursa olsun, VCL Delphi'nin ayrılmaz bir parçasıdır ve uzun yıllar boyunca öyle kalacaktır. Platformların evrimi ve masaüstü sistemler ve mobil cihazlar için işletim sistemi alanındaki mevcut durum öyle olsa da, gelecek açıkça FireMonkey'de.

Röportajda daha önce iOS desteğinden bahsetmiştik, okuyucularımıza başkalarının desteğinden bahsedelim en son teknolojiler Windows 8 ve WinRT, 64-bit sistemler, MacOS ve benzeri gibi en son RAD Studio XE4'ten. Yeniliklerle şımartılmış modern bir programcıya başka neler sunabileceğinizi listeler misiniz?

Büyük olasılıkla, modern programcı yeniliklerle "şımarık" değildir. Büyük projeler için, herhangi bir "yenilik" genellikle devasa miktarda işe dönüşür.

Örneğin, herkes uzun süre bekledi, birçoğu kodlarını yeni bir platforma aktarmak için hemen koştu. Ancak çok profesyonel ekiplerin bile buna hazır olmadığı ortaya çıktı. Derlenebilir 64 bit kod, çalışılabilir anlamına gelmez. 4 baytlık bir adres boyutunu varsayarak komut kullanma gibi "gençliğin günahları" ortaya çıkmaya başladı. Test yapma kültürünün olmaması, bu süreci kısa sürede uygulamaya yönelik teknolojik isteksizlikle birleştiğinde.

Ve burada - örneğin kaynak kodunun satır sayısıyla ölçülen proje ne kadar büyükse, programcılar arayüzdeki bir "düğmenin" görünümünden "sözdizimsel şekere" kadar çeşitli yenilikleri daha dikkatli ve dengeli bir şekilde ele alır. derleyicide.

Bu "sorunlu" başarılardan biri, Windows 8'in piyasaya sürülmesiydi. Kişisel olarak, bir PC kullanıcısı ve sadece modern bir BT uzmanı olarak, Windows 8'den memnunum. Ancak, yeni işletim sistemi altında geliştirme için teknik özelliklere sahip bir grup Windows 8 bilgisayarı yük olarak gönderilen geliştiriciler için bu, belirli zorluklar anlamına gelir.

Bu işletim sisteminin yeni arayüzü altında geliştirme için mümkün olduğunca rahat ve zahmetsiz bir şekilde destek vermeye çalıştık. Bu nedenle, hem VCL hem de FireMonkey için özel stiller sunulmuştur ve programcı, uygulama arayüzünü yeniden oluşturabilir veya görünüşte Windows 8 için "yerel" olandan ayırt edilemeyecek yeni bir uygulama oluşturabilir. Tabii ki, WinRT aracılığıyla Windows 8 için "yerel" bir desteğe ihtiyaç var. Ancak burada, modern koşullarda hedeflerin önceliklendirilmesi etkiler. Yakın gelecekte Mac OS, iOS, Android henüz WinRT'nin yakın gelecekte tam desteği hakkında konuşma fırsatı vermiyor.

Embarcadero'nun stratejik hedefi elbette çoklu platformdur. RAD Studio XE4'ün piyasaya sürülmesi, öncelikle iOS desteği nedeniyle önemli bir sürümdü. VCL kullanan aktif bir programcı, birkaç saat içinde iOS için geliştirmeye başlayabilir. Basit bir mobil uygulama bile anında mevcut altyapı içinde çalışan güçlü bir projeye dönüştürülebilir. Bunun sadece FireMonkey için yeni bir derleyici ve iOS arayüzüne uyan yeni bir stil olduğunu düşünmeyin.

Buna yeni bir görsel tasarımcı, çeşitli form faktörleri için yerleşik destek, yeni FireDAC dahil olmak üzere veri erişim kitaplıkları ve kurumsal verilere esnek ve dinamik bağlama için LiveBindings teknolojisi dahildir. Tüm bu yenilikler aynı anda geliyor - Windows, Mac OS ve iOS için. ameliyathane Mac sistemiİşletim sistemi çok hızlı gelişmiyor, bu nedenle Windows 7'den Windows 8'e geçiş gibi sorunlar yok. Ancak Retina ekranlar ortaya çıktı ve bu özel dikkat gerektiriyordu. Artık Delphi XE4'te oluşturulan herhangi bir MacOS uygulaması otomatik olarak iki stil içerir - "normal" ve "yüksek tanımlı".

O. aynı uygulama, Apple'ın herhangi bir masaüstü bilgisayarında aynı kalitede "yerel" arayüze sahip olabilir.

Embarcadero, yeni yenilikçi sürümleriyle geliştiricileri "şaşırtmak", "şaşırtmak" ve hatta "eğlendirmek" istemiyor. Aksine, BT alanı zaten çeşitli sürprizlerle dolu: yeni cihazlar, yeni platformlar, yeni kullanıcılar, yeni ihtiyaçları, yeni etkileşim senaryoları. Buna yeni yazılım geliştirme teknolojilerini ekleyin ve programcıların yeni sistemler ve mevcut olanlar üzerinde oluşturmak için zamanları olmayacak - yalnızca bir ortamdan diğerine, eski bir kitaplıktan yenisine, bir dilden diğerine geçmek için ne yapacaklar. bir diğer.

Ancak yeni olan her şeyin reddini kabul etmiyoruz. Biz sadece her şeyin sürekliliğini sağlamak istiyoruz - kod, arayüz, proje, hatta yeni platformlar ve cihazlar ortaya çıktıkça profesyonel beceriler bile. Geliştirme araçlarında sağlıklı bir muhafazakarlık pahasına, yeni platformlarla ilgili sağlıksız bir muhafazakarlıkla mücadele ettiğimizi söyleyebiliriz. Embarcadero'dan egzotik ürünler, standart dışı programlama dilleri ve tuhaf geliştirme araçları beklemeyin.

Bizimle her zaman görsel geliştirme, klasik diller, "yerel" kod bulacaksınız ve uygulamalarınız için aynı kanıtlanmış klasik yolla oluşturulan hedef platformların yeni olmasına izin vereceksiniz.

Ateş Maymunu nedir?

FireMonkey (FMX), Delphi/C++ dilini kullanarak hem masaüstü sistemleri (Windows, Mac OS + yakın gelecekte Linux'ta sunucu tarafı desteği) hem de mobil (iOS ve Android) için platformlar arası geliştirmeye yönelik bir çerçevedir.

özellikler:

• tüm platformlar için tek kod tabanı;

• herhangi bir kontrol (görsel bileşen), diğer bileşenler için bir kapsayıcı (ana) olabilir;

• form üzerinde bileşenlerin çok gelişmiş bir göreli düzenlemesinin (20 tip) varlığı;

• LiveBinding, her türlü veriyi veya bilgiyi herhangi bir kullanıcı arayüzüne veya grafik nesneye bağlamanıza olanak tanır;

• form/bileşen stillerinin varlığı;

• Çoklu Cihaz Önizlemesi, görsel sunumu platformların her biri için özelleştirmenize olanak tanır;

• FireUI Live Preview - Uygulama görünümünü gerçek cihazlarda gerçek zamanlı olarak görüntüler.

olasılıklar:

• platformların her birinin yerel API'sinin yanı sıra üçüncü taraf yerel kitaplıkları çağırma yeteneğinin kullanımı;

• tüm sensörlerle etkileşim (GPS, İvmeölçer, Pusula, Bluetooth (LE dahil) ve diğerleri);

• push bildirimleri için destek, IoT;

• eşzamansız HTTP istekleri için destek;

• çoğu veritabanı için destek (MsSQL, MySql, Oracle, PostgreSQL, MongoDB, vb.);

• Bulut Hizmeti (Amazon, Azure) ile çalışın;

• android servis desteği.

Eksileri (şu anda):

• yerel sınıfların özelleştirilmesi için destek eksikliği;

• belirli şeylerin uygulanması imkansızdır (widget'lar, uzantılar (iOS), vb.) veya tef ile dans etmek gereklidir (arka plan hizmeti, yayın mesajı vb.);

• özelleştirme Başlangıç ​​ekranı (ilk ekran) en hafif tabirle hayır;

• FMX kontrolleri, tamamen görsel olarak yerele benzeyen kendi işlemelerini (görselleştirme, çizim) kullanır;

• yerel kontrollerin kullanımı büyük vücut hareketleriyle ilişkilendirilir;

• bileşenlerin geniş bir şekilde iç içe yerleştirilmesiyle inanılmaz şeyler olur: uygulama çeşitli yerlerde çöker, odak kaybolur, donar vb.;

• mobil platformlarda bir uygulamada hata ayıklamanın bilgi içeriği sıfırdır;

• mobil platformlardaki hataların açıklamaları işe yaramaz "Hata 0x00000X" e indirgenmiştir;

• derleme süresi orta ve büyük projeler için en iyisi olmak ister;

• her platform için mobil uygulamaları geliştirmek üzere bir dosya kullanma ihtiyacı;

• Intel Atom mimarisi için destek yok;

• rakiplerine göre yetersiz fiyat.

Artıları:

• hem üründe hem de toplulukta çok aktif son gelişmeler, giderek daha fazla yeni teknoloji için destek;

• çok sayıda ücretsiz ve ticari bileşenin varlığı;

• uygulamanın hızı yerele çok yakın;

• genel olarak çok gelişmiş bir görsel editör ve ortam, stillerin varlığı;

• uygulamayı Win'de test etme ve ancak o zaman geliştirmeyi büyük ölçüde hızlandıran cihazlara dağıtma yeteneği;

• bir bilek hareketiyle modu/platformu değiştirin;

• PAServer, Apple OS için geliştirme yaparken MacO'larla kolay etkileşim sağlar;

• kutudan çıkar çıkmaz 3D grafikler için destek.

Sonuç olarak, son birkaç yılda FireMonkey'in yalnızca iş uygulamalarının platformlar arası geliştirilmesi için profesyonel bir araç haline geldiğini söylemek istiyorum. Pek çok eksiklik yavaş yavaş çözülüyor ve her sürümde ürün daha modern ve kendi kendine yeterli hale geliyor, Delphi diline yönelik uzun yıllar süren durgunlukla ilişkili mevcut şüphecilik de ortadan kalkıyor. FireMonkey'de yeni projeler yazmak "güvenli" ve umut vericidir.

FireMonkey teriminin, tüm geliştiriciler için olmasa da en azından Delphi kullananlar için aşağı yukarı tanıdık hale gelmesinden bu yana yeterince zaman geçti. Bu süre zarfında FireMonkey ile ilgili kitaplar, FireMonkey ile ilgili makaleler, sayısız blogda FireMonkey ile ilgili yazılar vardı. Bütün bunları okumak çok ilginç. Ancak hiçbir teori pratiğin yerini alamaz. Ve daha önceki birçok kişi gibi benim de FireMonkey kullanarak bir şeyler yazmayı deneme isteğim vardı.

Ancak bunu yaparken bir sorun çıktı. Nedense, çok karmaşık olmayan bir çalışma projesini uygulamam gerektiğine karar verdim.

Bunun benim için neden bir sorun haline geldiğini açıklamak için biraz (yazmak istiyor, lirik) konu dışına çıkmak gerekecek. Bir geliştirici olarak geçmişime bir gezi. Delphi kullanarak programlama konusundaki görüşlerimden bazılarını açıklayın.

Delphi'yi Windows 3.1'de, yani ilk sürümden itibaren kullanmaya başladığımı söylemeliyim. Ve o zamandan beri VCL çalışıyorum. Orijinalinde okudu, tabiri caizse. İzlenen, adreslenen, izlenen kaynak kodları. Tekrar ve tekrar.

Çeşitli zamanlarda Delphi ile birlikte gönderilen bileşen setinin, VCL'deki boşlukları doldurması gereken ve dahil edilmeden önce muhtemelen bir tür kalite kontrolünden geçen üçüncü taraf bileşenleri içerdiği bilinmektedir. Bu bileşenlerden bazıları bugüne kadar tedarik edilmeye devam ediyor. Aynı Indy'yi al. Kimseyi gücendirmek istemiyorum, bu tamamen benim kişisel görüşüm ve bu aynı zamanda bir bileşen geliştiricisi olarak benim için de geçerli: tek bir set bile bu kadar derinlemesine düşünülmemiş ve uygulanmamış, devasa ve çeşitli bir VCL. Hayır, nihai gerçekmiş gibi davranmıyorum ve elbette VCL'nin kendisinde birçok hata var, yanlış anlaşılmaya, reddedilmeye neden olan ve katılmamak isteyeceğiniz kararlar. Ama her zaman belirli bir tek tarz izlenimi edindim. Bence VCL'de, tüm Delphi tasarımını destekleyen ve hem yazılım altyapısının hem de geliştirici topluluğunun kendisinin etrafında inşa edildiği güzel ve güçlü bir çekirdek var. Büyük ölçüde VCL'ye teşekkürler, yine bence Delphi'nin ölümüyle ilgili söylentiler hala söylenti. Ve VCL'nin teslimatına üçüncü taraf bileşenleri dahil edildiğinde, farklı oldukları hemen fark edildi.

Ama sonra o an geliyor ve VCL'nin modası geçmiş bir teknoloji olduğunu duyuyorum. Geçmişte bırakılması gereken bir teknoloji. Geliştiriciler tüm yeni projelerini FireMonkey'de uygulamalıdır, ancak eskileri hakkında ... onları yeni raylara aktarmak güzel olurdu. FireMonkey her yerde ve her zaman. Ve farklı kaynaklardan duyuyorum. Ve oldukça ısrarla. Hayır, kimse VCL'yi öldürmez. bizimle kalıyor. Ama artık bir numara değil. O bir vekil olmalı. En azından ben ürünün geleceği hakkında söylenenleri böyle anlıyorum.

Prensip olarak, bu uyumu anlıyorum. Multi-platform ve daha da önemlisi cross-platform için kurs alındı. Sonuçta, VCL nedir? Görsel Bileşen Kitaplığı. Görsel bileşenler kitaplığı. Buna katılmayabilirsiniz. Örneğin, her zaman birçok görsel olmayan bileşeni ve bileşenleri değil, yalnızca sınıfları, VCL'nin ayrılmaz bir parçasını ve çok sayıda üçüncü taraf sınıfı ve bileşeni - VCL'nin bir devamı, bir uzantısı olarak düşündüm. . TDataset'in varislerinin VCL'nin bir parçası olmadığını düşünemem. Örneğin, DBExpress Kitaplığı terimi bunun bir VCL olmadığını söylese de. Görünüşe göre Embarcadero, monolitik olanı benim bakış açıma göre VCL'yi gerçekten bir dizi ayrı kitaplığa ayırıyor. Hayır, elbette, tamamen ayrı değil, ama yine de. Ve bu bakış açısına göre, FireMonkey'in VCL'nin görsel kısmını değiştirmesi amaçlanmıştır (yine de tam sınıf ve bileşen kitaplığını, belki Borland Bileşen Kitaplığını nasıl çağırmalıyım?).

Kütüphanenin görsel bileşenleri nelerdir? İşletim sistemi tarafından sağlanan alt düzey, temel öğeler. Pencere tutamaçları, yazı tipleri, pencerelerin kendisi, giriş öğeleri, mesajlar, aygıt bağlamları ve çok daha fazlası - bunlar Delphi ile birlikte gelen kitaplığın kavramları değil, işletim sisteminin kavramlarıdır. Evet, doğru, Windows. Ve bir çapraz platform kitaplığı oluşturmak istiyorsanız, kitaplık kullanılarak yazılan programı yürüten işletim sisteminin sunduğu altyapıyı reddetmek mantıklıdır.

Bu tam olarak FireMonkey'in yapmaya çalıştığı şeydir. İşletim sistemlerinin sunduğu hizmetin yerini alabilecek, çeşitli işletim sistemleri tarafından desteklenen temel mekanizmalara dayalı bir altyapı oluşturmaya çalışıyorlar.

Birçok kişi yapmaya çalıştığını hatırlıyoryalnızca kitaplığı değil, Delphi'nin kendisini de platformlar arası. Delphi 6'ya paralel olarak Kylix ürünü ve CLX kütüphanesi çıktı. Bütün bunlar Linux için geliştirebilmek için yapıldı. Ancak Linux, Windows'un sahip olduğu temel GUI pencereleme kavramlarının çoğuna sahip değildir. Linux için pencere arabirimi genellikle yerel bir olgu değildir. Bu isteğe bağlı bir uygulamadır. Ve bir tür sentetik kitaplık yazmak zorunda kaldım. Yardımı ile hem Windows hem de Linux için bir program yazmak mümkün oldu. Bununla birlikte, CLX'in görsel bileşenlerinin analoglarını kullanmaya çalıştığımda yaşadığım hayal kırıklığı değil, sinir bozucu rahatsızlık hissini hala hatırlıyorum. Çok özlemeye başladım. VCL ile geliştirirken düşünmeden yaptığım şeyi CLX kullanarak yapmak zor, çok farklı veya basitçe imkansız hale geldi.

BDE'den DBExpress'e geçerken de aynı şeyi hissettim. Eski, Field Test-a BDE'den tanıdık (Borland daha sonra bunu Windows için Quattro Pro'da ve Windows için Paradox'ta zaten kullandı ve buna ODAPI ve ardından IDAPI adı verildi ve bence Microsoft'un ODBC'sinin üzerinde bir kesimdi) yeni projelerde yerini yeni bir kütüphaneye bırakması gereken eski teknolojiyi ilan etti. Başta bilgi olmak üzere DBExpress'te hep bir şeyleri kaçırıyordum.

Aynı zamanda, yukarıda listelenen kütüphaneleri veya bunların ortaya çıkmasına neden olan kararları hiçbir şekilde azarlamak veya eleştirmek istemiyorum. Bu sadece izlenimlerimle ilgili, bazen ilk izlenimler.

Şimdi, belki de, FireMonkey kullanarak küçük bir çalışma projesi yazma kararının neden bir dizi sorunu beraberinde getirdiği biraz daha açık hale geliyor. Uzun yıllardır proje, proje ve projelerin geliştirilmesinde belirli bir klişe, neyin ve nasıl yapılacağına dair belirli bir şablon oluşturulmuştur. Ve benim durumumda, şablonun değiştirilmesi gerektiği gerçeğiyle yüzleşmek zorunda kaldım. Çünkü VCL kullanmaya alıştığınız her şeyi FireMonkey üzerine kurulu bir projeye aktaramazsınız.

Projenin başlangıcında, belli bir deja vu duygusu yaşadım. Yani, bir rahatsızlık hissi. Örneğin, normal giriş öğelerinin pek çok özelliği yoktur. İşletim sisteminin bazı özelliklerinin bilinmesiyle ilgili hilelere dayanan, pratikte sağlam bir şekilde yerleşmiş olan hileler, yeni bir bağlamda çalışmaz. Bazı bileşenlerin kökten değiştiğinden bahsetmiyorum bile.

Peki, başka bir önemli nüans. Bu (iş) derleyiciler yazmak, modelleme sistemleri veya son derece bilimsel başka herhangi bir şeyle ilgili değilse, genellikle işte ne tür projeler yapılmalıdır? Çoğu için veritabanlarını kullanmayı içeren bir şey geliştirmekle ilgili olduğunu düşünüyorum. Ayrıca, son derece bilimsel bir şey de DBMS tarafından sağlanan hizmetleri kullanabilir.

Burada beni başka bir pusu bekliyordu. Herhangi bir nedenle, pratikte FireMonkey'in veritabanında depolanan verilerle çalışmaya odaklanmış öğeler içermediğini gördüğünüzde, buna tam olarak hazır değilsiniz (en hafif tabirle). Bunu zaten birçok kez okumuş olmama ve (teorik olarak) ne kullanmanız gerektiğini bilmenize rağmen. Canlı Bağlamalar hakkında.

Gerçek harika programcıların db-aware bileşenlerini kullanıp kullanmamaları gerektiği konusunda bir tartışmaya girmek istemiyorum: görüntüleme, düzenleme ve nihayetinde kaydetme. Hangisi, yine, ne kötü ne de iyi. Sadece benim için böyle oldu.

Bu, ilk izlenimler yazımı sonlandırıyor. Sırada, proje üzerinde çalışırken neyin ve nasıl üstesinden geldiklerine dair hikayeler var.