Tuesday, August 30, 2011

Embarcadero Delphi XE2 New Features of Interest

Embarcadero Delphi XE2 Review of New Features — VERY Interesting Features!

I have been anxiously awaiting the official Embarcadero Delphi XE2 release now that this RAD (Rapid Application Development) IDE and Component-Set are poised to bring about some of the most exciting changes in Windows (and cross-platform!) application development seen in a long time. Yes, Embarcadero (formerly Borland, Inprise, and Codegear branded) Delphi is finally stepping up the application-development game and introducing some exciting technology to address shortcomings in modern MS Windows business-software-applications development.

Although many will cite the most interesting new features as those being support for cross-platform development, Windows 64-bit, Amazon Cloud API, Native iOS support, for me the obvious "killer feature" is the new vector-based UI-development component suite and technology called "FireMonkey". The reason I choose this as the "killer feature" is because 1) I have felt that Windows-UI development has been rather "stale" for years when building *native* (compiled executable applications), and 2) this technology is what certainly makes large portions of other features (like cross-platform development) even possible, and finally 3) I consider this technology capable of building real mission-critical business applications

Delphi XE2 FireMonkey : Vector-based User-Interface Development

Delphi XE2 FireMonkey: Could it be a Disruptive Technology?

FireMonkey is the moniker Embarcadero has applied to their new scalable vector graphics based Graphical User Interface (GUI) framework that is leveraging the capabilities of modern GPUs (Graphics Processing Units) for hardware accelerated cross platform GUI’s. If that sentence did not make it obvious: this is BIG, people!

FireMonkey really could be the disruptive technology we have been waiting for with regards to developing compelling UI's for business applications. It is about time scalable vector-graphics melded with mainstream business applications (and yes, I am aware that Flash and Silverlight are vector-based technologies; I just still do not consider them to be something I want to build any large-scale enterprise applications with).

If Embarcadero is successful at marketing this vision of how modern UI's should be developed, we could be on the cusp of a huge shift in *native* application UI technology (note: I consider HTML5/JS advancements also disruptive, but in a different way and for a somewhat different target-market).

So, vector-based User Interfaces (UIs) are soon to be a reality for Delphi developers and the software applications they create (and therefore Microsoft Windows environments), but FireMonkey holds even more promise than simply modernizing our UIs — this technology is what will allow resulting UIs to now be cross-platform capable. FireMonkey provides UI elements that will ultimately look the same across the various deployment targets: 32-bit Windows applications for Windows 7, Windows Vista and XP and Server OS's... 64-bit Windows applications for Windows 7, Windows Vista and XP; Server 2003 and 2008... and even Apple OS X 10.6 and 10.7 applications and iOS 4.2+ applications. What? Apple? Since that cross-platform development tool news is going to be of substantial interest to many people, I will discuss that later in this blog;likewise you have taken note of the 64-bit reference which will also be discussed in more detail.

Delphi XE2 FireMonkey: Where did it Come From?

FireMonkey is based on VGScene/DXScene, which was created by KSDev (Eugene A. Kryukov), and then purchased by Embarcadero quite recently (late 2010 - early 2011). KSDev sold VG/DXScene as a VCL component package prior to the acquisition, and KSDev's final release on 1/13/2011was considered "feature complete".

KSDev marketed their components as: "a Delphi VCL library for WPF-like framework with advanced controls, styles, graphics and effects", with the core functionality being built around a powerful vector-engine (similar in concept to how Adobe Flash works) with modern features like real-time anti-aliased vector graphics, resolution independence, alpha blending, gradients and special visual filling,etc.

I actually looked into using DXScene / VGScene back over a year ago when I found myself, once again, thinking how outdated my Delphi GUI applications looked and how utterly annoying I found it that native executable Windows applications (in general), and the UI elements that made up these GUIs, did not SCALE easily when switching between various screen-sizes and pixel-densities, and that there was no easy way to give my applications the refinements to look more "modern" without purchasing a bunch of third-party controls. And, purchasing third-party controls to address the issue of modern "look" still did not resolve the issues with easy scaling of the UI-elements.

After looking at the KSDev stuff, I actually opted not to embrace their components for a few reasons. First and foremost (at the time) I considered them to be a high-risk "niche" component-set that I was unwilling to risk building mainstream applications for my customers with. I have seen all too many Delphi VCL component sets wither (think Rave Reports) and/or completely die-off over the years, and even if source-code is available, many component sets are just so specialized that it would take far too great of an investment to continue to use them in the event the developer "gave up" on them or failed to produce necessary bug-fixes and so on. KSDev had a neat thing going with their components, and thankfully Embarcadero has picked up that work and provided the credibility and reassurance I need to actually implement business-applications using that technology now in Delphi XE2!

Delphi XE2 FireMonkey: Is it Like X, Y, or Z?

This cross-platform application framework uses GPU-accelerated vector graphics to render UI elements, D2D/D3D (Direct-2D / Direct-3D) on Windows, and OpenGL on OSX. You can think of it as similar to Silverlight OOB or Jupiter (the new “application model” for Windows 8), or even Adobe Flash. When I consider the goals of Microsoft's "Jupiter", I have to wonder if perhaps FireMonkey is essentially the same thing... here is what a ZDNet article from early 2011 described Jupiter as:

Jupiter is going to be a new user interface (UI) library for Windows, built alongside Windows 8. It will be a thin XAML/UI layer on top of Windows application programming interfaces and frameworks for subsystems like graphics, text and input. The idea is Jupiter will bring support for smoother and more fluid animation, rich typography, and new media capabilities to Windows 8 devices.

Hmmmmm... sure sounds quite similar with regards to the end-result (the UI people see), though thankfully the FireMonkey implementation is not a pile of XAML and over-complexity that Microsoft always seems to come up with.

Instead, FireMonkey uses the familiar Delphi (object pascal) language and VCL (Visual Component Library) paradigm for its implementation, and compiles to native code. To me, being able to work with FireMonkey is just like working with any other VCL components, and honestly anything that keeps my from having to learn yet another Microsoft UI-technology-of-the-day is a plus (I just can not deal with XAML).

FireMonkey: Will Microsoft FUD Bury it Before it Takes Hold?

At least part of me is concerned that Microsoft will somehow work its usual FUD (Fear, Uncertainty, and Doubt) campaign against Embarcadero (with regards to FireMonkey) as they work feverishly to bring their own "Jupiter" vision and Windows-8 to market.

For all you LONG-TIME Delphi developers, do you remember how the Visual Basic vs. Delphi thing played out over a decade or more? Clearly Borland was (what should have been) light-years ahead in the RAD IDE and component-based Windows development tools/language space (especially in OOP that people could understand; unlike C++ which dominated mainstream "real" Windows apps prior to Delphi), but Microsoft worked very hard to convince developers (and corporate management) that investing in Delphi was a bad move... that Delphi was too risky,.. all the while working to "catch up" with Visual Basic and push that as the "solution" to corporate UI-development needs. I have used Delphi since version 2, and the fact is, Microsoft was not even remotely close to having anything as capable until perhaps the days of Delphi 2006.

As we all know in retrospect, Microsoft's strategy worked in a BIG way and only after burying Delphi and relegating it to the niche-market they fabricated through FUD did MS create a semi-decent (though wildly bloated) component set of DotNet and the reasonably nice C# language (which is clearly based on Delphi to some extent). I am concerned that somehow Microsoft will wage such a war again if they decide Embarcadero is a "threat"; or, do they even need to?

The fact is, Microsoft's decade+ campaign of marginalizing otherwise promising, and even superior, development languages and technologies has been so successful that Embarcadero has a monumental task ahead of it: convincing mainstream corporate developers to actually embrace this technology. Good luck with that!

There are so many "competing" priorities pulling at corporate IT-folks and budgets that I see this as a battle that is going the be VERY difficult to win without some serious willingness to put some flesh on the line and suck up some losses while doing "a Microsoft" and dumping the product out there en masse, and even at a potential loss, to foster widespread adoption so as to gain the all-important "critical mass" necessary to propel the product forward and create a self-sustaining win vs. a self-fulfilling-prophetic-loss situation (for lack of developer density, etc).

FireMonkey is also up against HTML5/JS hype, up against Silverlight/Flash and the forthcoming "Jupiter", and so many other competing technologies... how is it going to gain traction? When we (developers) search sites like Dice.com and see essentially ZERO postings for Delphi developer jobs (compared to oodles of C# or Silverlight or HTML5/JS jobs), what are we to do?

Embarcadero best be thinking long-term and be willing to take a bit of "a hit" (financially) to gain a foothold, or the simple fact is: the niftiest technology in years for UI development may make little difference to market penetration and adoption. Get your marketing/sales team (especially the latter; since "marketing" is sales without responsibility for producing revenue) ramped up NOW Embarcadero, and have them start working some serious deals with software developers to get them to use this product! OK, enough said... on to more about this tech...

FireMonkey: Embrace it, and Embrace Changes to Your Existing Applications

FireMonkey is an entirely new framework for UI-development, and as such, it is incompatible with your current/traditional VCL-based UIs and you are not going to be having co-existence in the same application (i.e., if you want to port an existing application UI to the new FireMonkey technology, you will have to rewrite your GUI code).

This sure sounds a bit overwhelming, but I really think this gutsy move by Embarcadero is what will actually give FireMonkey a fighting chance — the technology is not encumbered by the burden of legacy support! This makes the implementation MUCH cleaner — we all can attest to how much we welcome the opportunity to write an application or component "from scratch" as compared to modifying a many-revision-old, widely used (and thus many possibilities to "break" something), piece of code. I expect this new code to be architecturally solid and much more ideal thanks to separating it from the older UI-VCL components.

FireMonkey Components are Containers

You will also have to get used to a bit of a paradigm shift with regard to how components are assembled, and I think it is another shift that is for the better and about time: FireMonkey components are all containers, meaning you can embed any component inside any other component. When you think about it, this makes total sense.

Something as simple as a button-component is composed by assembling 9 components that, when put together, produce what looks and behaves as a Button should. A FireMonkey Button consists of: a TLayout component to organize all control layout, (3) TRectangles for border, background and foreground color, a Label represents for the Button text, and then a group of four additional components (two each, for animation and effects).

The animations are going to give us the visual mouse over/out on the button (like we are used to seeing on websites for years), and the effects can occur on events like button-press, onfocus, etc and make even niftier things like "glow" effects happen and so on. This type of animation/effects ability is present throughout all of FireMonkey components thanks to the way these containers and component-buildups can be implemented. I look forward to using this to "modernize" the look and feel of my applications, though we all need to keep in mind that this could be over-used quite easily.

You may also want to think about how to standardize the look/feel of your application elements, and thankfully FireMonkey implements what is a parallel to CSS Styles through their own FireMonkey "Styles". I am not yet sure how far these Styles can be pushed, but I am hopeful this first version is good enough for most things. I think about how CSS has gone through a lot of change as we push into CSS3 now, and I wonder if future iterations of Delphi XE3, XE4, etc will be extending the power of their own Styles just like how CSS keeps growing its abilities.

In some regards, these Delphi FireMonkey styles are quite a bit more advanced: you can implement things like blurs, animations, and so forth, via styles. Again I have some concern about pushing UI-glitz TOO far, but, no matter what, Styles should make standardizing and quickly updating the look-and-feel of applications a LOT easier!

Perhaps FireMonkey applications will be the advertising-force Embarcadero needs to gain further recognition: when users and developers start seeing native applications that are simply stunning, they may start to ask "what is that written in?" This could be a positive thing, but I also can imagine some applications getting so ridiculous with animating every last aspect of the UI that, when that previous question is asked, it will be with a bit of disdain or ridicule.

Hopefully we all use this power wisely :)

What about Non-Visual Components?

You may already be thinking: what about all my VCL components I use like TList, TStringList, etc.

Have no fear: these non-visual components will remain the same as what you are used to and will also be usable from your FireMonkey-based-UI applications. The fact is, if you have already done a decent job of separating your UI-implementations from the underlying event-code, database-interaction, and such, you may not have TOO difficult of a time updating your applications.

You are not going to have "data-aware" components like TDBMemo anymore under FireMonkey, but of course there is an alternative way of going about this. The new "LiveBindings" within the FireMonkey framework allow you to connect any type of data to any UI or graphical element in VCL / FireMonkey; consider this a mechanism for creating "live" relationships between objects and also between individual properties of objects. It has some serious potential!

I am excited by this feature, and look forward to seeing how far I can push these live-interrelationships. LiveBindings are going to allow you to do thing you can not do with existing data-aware controls too. And, LiveBindings are *not* just limited to FireMonkey controls (i.e., there is support for this technology in the "old" style VCL too as part of Delphi XE2 updates). You will be able to do things like bind the "Caption" property of a TLabel to the Field-values in a dataset (or the column-name, etc), and much more.

Since the "bindings" are accomplished using an expression-engine (vs. just simple hard-coded bindings) you can bind on evaluated-values. E.g., bind your label control's caption to an expression like TDBColumn.DisplayName + " column value is:" + dataset.field.valueAsString (pseudo-code used for example). You get the idea. It really is powerful.

But, that is not all... If you choose, you can implement bi-directional property-to-property bindings (which, sure sound like data-aware-like functionality). This bi-directionality implies something somewhat profound: it should be possible to consolidate UI-element-frameworks to no longer require those TDB...versions of each control (i.e., remove the need for "data-aware" versions of each control), since something like a Label can be bi-directionally "bound" and suddenly be that data-aware-control.

This is going to take some hands-on experience to get used to, but it is a significant step forward (and, should bring writing "data-aware" custom controls into the realm and reach of many more developers; I say this because I have always found writing TDBxyz data-aware custom components WAY too difficult!).

Note: I have read that the expression engine used by LiveBindings is available to us in our programs to evaluate any ObjectPascal expression dynamically at runtime; this should make for some interesting neat applications too!

Cross-Platform Native Applications using Delphi

OK, this topic certainly deserves some attention, especially from all of us that can still remember the days of Kylix, which was a nifty idea but one that failed miserably for all sorts of reasons (one being the simple fact it was not maintained at all after early releases). Well, with that memory pushed aside, let's think about the prospects of true cross-platform NATIVE-code deployment again.

As mentioned earlier, FireMonkey provides UI elements that will ultimately look the same across the various deployment targets: 32-bit Windows applications for Windows 7, Windows Vista and XP and Server OS's... 64-bit Windows applications for Windows 7, Windows Vista and XP; Server 2003 and 2008... and even Apple OS X 10.6 and 10.7 applications and iOS 4.2+ applications. In addition, there is some speculation that Android support and Linux will be forthcoming soon after the release of Delphi XE2 (hopefully as a free update!!)

The IDE Runs Only On Windows : but, you can deploy to other targets

It is not surprising that the Delphi XE2 RAD IDE runs only on Windows, though part of me wonders if Embarcadero will get around to converting the IDE to be FireMonkey-based (if even remotely possible?) and make the IDE run on any target-platform. Regardless, for now it is Windows only (as it always has been; aside from Kylix), and we developers will have to go through a few extra steps to compile and deploy applications to the Apple targets.

Delphi for Apple OSX/iOS

From what I have gathered via online discussions (I have not tested the Apple deployment stuff at all, nor do I have much initial concern for it even though long-term I expect to support Apple targets), Embarcadero / Delphi is apparently relying on the FreePascal Compiler (FPC) to compile code for deployment to other (non-Windows) target operating-systems.

The FPC compiler will use the same source-code you have written for your Windows-based applications (that Delphi's compiler used to generate Windows binaries) and the FPC will generate binaries (i.e., native apps) that can be run an Apple / Mac computer and/or iOS device (i.e., single collection of source code yields multiple-platform-specific binaries, thanks to some FPC help).

There are also significant limitations with what all can be simply recompiled and deployed to the Mac. I am under the impression that outside of FireMonkey, substantial portions of the VCL will not be available on the Mac yet (I may be wrong). And, I really can not imagine some things EVER being supported on the iOS/OSX platform (especially some of the "native" database-access stuff).

You will certainly need to use FireMonkey for any UI you plan to have run on the Apple side of things, but in addition, I suspect there will be all sorts of other caveats regarding what will and will not "port" directly simply via a recompilation. Again, I see the Apple thing as a longer-term possibility for me. I'd be more intrigued with Linux deployment immediately (since I have Linux running in a Virtual Machine or two). Time will tell. I look forward to seeing what people are able to achieve on the Apple platform with Delphi XE2.

Delphi Applications for Cloud / Hosted Scenarios

I came across a sentence online somewhere stating that "Delphi and C++ applications can be deployed to Amazon EC2 and Windows Azure, with support for Amazon Simple Storage Service API, Queue Service, and SimpleDB." This is interesting, but I really do not know exactly what was needed to support this, and so far, I have not had the need for this.

Delphi XE2 64-Bit Support

Native 64-bit Windows applications are something that quite a few Delphi developers have clamored for over the past couple years, and apparently they are getting their wishes fulfilled. Delphi XE2 is to include support for Windows 64-bit machines, including a debugger and deployment manager. And, it looks rather easy to deploy an application as a 64-bit applicaition.

In the Delphi XE2 Project Explorer you will see a new node under each project where you can choose your "Target Platforms". By default, your existing projects are going to have a "target platform" entry that is ideal for deploying to 32-bit Windows. Next, you can add your new 64-bit Windows platform target node to the tree, select it, recompile, and voila!, you have a 64-bit executable.

I do not know how many developers really "need" 64-bit capabilities (like is necessary for addressing very large blocks of memory or working with 64-bit integers, etc), but now the capability is there and Delphi need not be considered lacking in this regard. You will have to do some (most likely) minor "code review" to make sure you to not have any code that is for some reason only 32-bit-safe; e.g., you are doing some bit-level manipulation shifting bits around in INTs, doing crazy things with pointers, etc. I do not expect most people will have significant work to do in this regard prior to 64-bit compiler and deployment use.

Delphi Reporting Components Update : Finally!
Goodbye Rave Reports (Junk!)

OK, I could not obtain 100% confirmation of this quite yet, but rumor has it that Delphi XE2 will include FastReport VCL 4 RAD Edition reporting tool — whether true or not, the fact is I refuse to invest ANY more time using Rave Reports (what a buggy pile of @#!@ that is an embarrassment that needed addressed; Nevrona's pathetic "support" and glacial pace of resolving any issues and bugs caused me and many others to become utterly fed up with the product and move elsewhere).

FastReports surely has to be a better option by a long-shot, as it is actively maintained and developed. Compare that to how Nevrona can not even update their *website* for years on end. I can not believe how long it took Embarcadero to move past Rave Reports... perhaps they made the stupid move (or Borland did) of signing some longer-term contract with Nevrona without any sort of "out" for them not meeting certain quality criteria, support criteria, etc. Who knows. But, I am excited by the prospect of having a good reporting tool (by default) included with Delphi!

Other New Features in Delphi XE2 Worth Noting

More details will emerge quite soon. In fact, I am supposed to listen to a Webinar about the product-launch tomorrow hopefully a near-term Delphi XE2 release-date is to be announced. And, I also hope the RTM (i.e., final, release-ready) version of Delphi XE2 is truly "ready" and not full of a bunch of annoying bugs.

My guess is that like most recent releases, there will be an update-pack available for it nearly as soon as it is officially "released"; hopefully it is solid enough to be truly prime-time ready. I have quite a few Delphi applications I want to update to take advantage of these new features ASAP.

I am not a big "DataSnap" user, but this release is supposed to have a fair amount of updates to that functionality. There are components and functionality related to that new "Cloud" stuff like TAzureQueueManagement, Amazon Simple Storage Service API, Amazon Queue Service API, Amazon SimpleDB API, and so on. I think the Documentation Insight is new (Delphi XML documentation tool) too.

Either way, there is a LOT of new stuff packed into this XE2 release, as already discussed. To me, the FireMonkey stuff alone is a HUGE chunk of functionality and makes me quite eager to start building some fantastic XE2-based applications leveraging these features.

Delphi XE2 — CONCLUSION: Enterprise Applications are Poised for a Major Update

As reported in this brief SD Times article and interview, Michael Swindell, senior vice president of product management for Embarcadero, seems to be clearly positioning Delphi XE2 and FireMonkey where I see it making the most sense: business applications:

“We know where we should be going with the experience of non-entertainment applications,” he said. [in reference to the fact that FireMonkey ships with about 200 user-interface controls that include GPU-powered scalable vector and 3D effects]

[...]

Swindell emphasized that FireMonkey is focused on heavy-duty business applications—not entertainment or advertising sectors, where rich Internet applications already are strong. To that end, FireMonkey introduces a feature called Live Binding, which lets developers bind any UI control or graphical element to any data source, he said. Native CPU application execution and data access allow FireMonkey applications to perform at a very high level, he added.