RAD STUDIO XE2: Launch Event Report

[Estimated Reading Time: 12 minutes]

Today I was fortunate to be present in Auckland at the World Premier of the launch event for RAD Studio XE2.  There is so much good to report that I really don’t know where to begin, so apologies if this post is a bit of a disorganised ramble.  But here goes.

Executive Summary

• FireMonkey – a scalable vector graphics based GUI framework exploiting GPU capabilities for hardware accelerated cross platform GUI’s.
• Cross-Platform support – Target Win32 and Win64 with single-source VCL applications or Win32, Win64 and MORE using FireMonkey.
• iOS support for native code FireMonkey apps !! – Yes folks – use Delphi to build iPhone and iPad apps that even Steve Jobs will be happy to have in his Store!
• LiveBindings – a way to create ‘live” relationships not just between objects but between individual properties of objects.
• Native Android apps – using PhoneGap in RadPHP
• Native Android apps – to come in the future for Delphi (as well as Linux)
• DataSnap client proxy generation – for Android, .NET, Objective-C, Blackberry, iOS etc etc
• Starter Edition will be available right from the start along with Pro, Enterprise and Architect.
• ALL platforms supported by the cross-platform capabilities will be in ALL editions, including Starter!

That’s a lot to cover, even in one whole day.  FireMonkey alone is such a huge advance for Delphi that I could spend this entire post talking about it (even as I sit here wearing the FireMonkey T-Shirt that I got for attending the event).

Yes folks – FireMonkey is big enough to warrant a t-shirt of it’s own!  Get used to hearing that name because I think we are going to hear a LOT more about FireMonkey not just from Embarcadero but from the industry in general.  It is a potentially game-changing technology imho.

Apologies

Before I get stuck into the meat of the event however, first a couple of apologies.

1) No pictures or video.

I tried, but sitting at the back and with the lighting in the room the way it was, I couldn’t get a decent picture or video and frankly I was too busy concentrating on the content to fiddle too much to try to capture pictures of the content.  As a result this blog post is heavy on words and light on pictures.  But I heartily recommend that you get along to a launch event in your area to see this stuff for yourself.  It will be well worth the effort, I assure you.

2) Heavy on the Delphi, light on C++, Prism, PHP and indeed DataSnap

I am a Delphi developer.  I don’t use RadPHP, C++ Builder or Prism, and I don’t use DataSnap.  Consequently I was not paying as much attention to those areas when they came up, nor does it particularly excite me to talk about those things.  Accordingly the focus in this post will be on Delphi.  And to be fair, most of the event content was focussed on Delphi.  C+ Builder was mentioned primarily in the context of “this stuff in Delphi is also in C++ Builder (and this stuff isn’t, yet)”.  There was quite a lengthy session on RadPHP and deploying a native code Android app derived from a RadPHP project.  Similarly there was a quite detailed session on generating proxies for DataSnap servers for various platforms, including RIM/BlackBerry etc, as well as .NET and Objective-C.

Again, if those areas interest you, you will get even more from the event than I did.  🙂

So with those apologies out of the way let’s get stuck in…

Hang On!  Did you say iOS ?!

Absolutely!  This was the big surprise of the event.  Not only do we get Win32, Win64 and OSX in this release but also iOS!!

The iOS support isn’t yet in as finished state as the OSX support, but it is more than good enough to be usable imho, and improvements to this are high on the list, being expected in the first update pack or not long there-after.

To be clear, the shortcomings are not in the compiler technology but in the integration with the debugger – at the moment you can compile, run and test/debug your iOS app as a Win32 app in the IDE, but if you want to test and debug on the iPhone/iPad simulator itself (or deploy to an actual device) then you have to compile the project in xcode on an actual Mac.  I am not entirely clear on how this works, but suffice to say there is no translation to Objective-C going on – the xcode compiler takes the ObjectPascal from Delphi, compiles it and then allows you to run and debug that ObjectPascal source in the xcode environment itself.

Also, just as with OSX, the iOS support builds on the FireMonkey framework.  This means that – with a little care – you can write an iPhone app today (100% native and thus entirely welcome in the Apple Store – no if’s or but’s) and when the Android compiler support is delivered simply recompile for Android!!

64-bit Windows?

So, right out the gate I think the first question will be whether or not we finally have the long promised 64-bit Windows support in Delphi.  The answer to that is a resounding YES.  Rather anti-climactically though, the demonstrations of 64-bit’ness are spectacular non-events.  It.  Just.  Works.

In the  Project Explorer there is now a new node under each project, entitled “Target Platforms“.  Here you will find an entry initially for 32-bit Windows for existing projects.  Whether you can specify multiple targets when a project is created I am not sure, but even if not, adding a new target is as simple as adding the relevant node to the Target Platforms.  Just add the 64-bit Windows platform, make that the current selection (if not already), recompile and your work is done!

Well, you may have a bit more work ahead of you if you have 32-bit assumptions built into your code, and those will need to be addressed, but other than that, switching a Delphi application from 32-bit to 64-bit really is that simple.

There are some technical considerations that mean you may have to make some adjustments in your code, and I am sure these will be covered in more detail by numerous people over the coming weeks so shall not go into them here (if you know even a little about pointers and integer types then you can guess, or already know, what most of those potential problems are).

Mac OSX ?

Of course, one reason we have had to wait so long for the 64-bit Windows support was the decision to also address Mac support.  Was it worth the wait?

I should Cocoa!!  [sic]

Add Mac OSX to the Target Platform‘s, recompile and off you go.  Right?

Well, no.  Actually in this case things are a little more complicated since the VCL has not been ported to the Mac platform.  Yes, you heard that right.  The VCL is and remains specifically and firmly targeted at Windows.  This means that you will not be able to take an existing VCL application and simply recompile for OSX.

FireMonkey is the new cross-platform GUI framework for building apps that support OSX.  FireMonkey also supports Win32 and Win64, as well as iOS and other platforms to come in the future.  So if you have an existing application that you wish to deploy to OSX you will first have to convert that application’s GUI to FireMonkey.

I will say at this point that I think was the smartest decision Embarcadero have made but will talk about FireMonkey in more detail later.

For now, once you have an application that can target Mac OSX, you compile it in Delphi and can then run it on a Mac to test/debug.  Delphi itself remains a Win32 application, so debugging your Mac OSX app involves deploying the binaries to a Mac host and using the remote debugger (now called: Platform Assistant).  However, with a “Remote Profile” – a configuration entry attached to your OSX Target Platform – identifying a valid Mac host running the Platform Assistant server, this is all entirely seamless from within the Delphi IDE.

“F9 to run and debug” was the goal and it has been achieved.

Describing all this in words makes it sound very mundane and work-a-day ordinary.

Actually seeing it in action is of course very much more exciting.  🙂

So just what is FireMonkey ?

As already mentioned, FireMonkey is an entirely new GUI framework.  I mentioned previously that it replaces the VCL for cross platform applications.  This is not strictly accurate.  The VCL is of course far more than just a GUI framework – all of those classes so familiar to use, such as TStringList, TList etc are strictly speaking part of the non-visual aspect of the VCL, and of course those elements are just as accessible from a FireMonkey application as they are today.

Similarly things like DBExpress are all accessible from FireMonkey.

Indeed, the root class in the FireMonkey framework extends TComponent, not TObject. But a TButton in FireMonkey is a very, very different animal from a TButton in the VCL. (for one thing it resides in the unit FMX.Buttons, as opposed to VCL.Buttons – new namespaces keep the two frameworks apart).

Also, whilst certain components in FireMonkey are provided in the form of specific root classes, the framework also makes extensive use of interfaces to establish contracts, not inheritance.  For example, an interactive control in FireMonkey does not have to extend any specific control base class, but it must implement the IControl interface, which provides methods necessary for focus and input in the FireMonkey framework.

Similarly any component that implements IRoot may act as a top level container, IScene for providing a 2D surface and IViewport3D for implementing a 3D container.

Yes, FireMonkey has 3D support built right in, and this includes being able to apply 3D transforms to 2D surfaces, even if those surfaces contain interactive controls – these aren’t just cosmetic 3D tricks.  You can take a FireMonkey form, rotate it in about the Y-axis (rotating the form surface “into”/”out of” the screen) and it remains fully interactive and fully animated.

Also built in are styles and filters.  You want to make your main form appear visually out of focus when presenting a modal dialog for the user to respond to?  Just go ahead and apply the Gaussian Blur filter on your form at a strength you deem appropriate.  It’s like having PhotoShop built in to your app, except that it doesn’t just work with images but with any element of your GUI, including the GUI itself!

FireMonkey also supports things call “Animations” (and on this point I agree with Malcolm Groves : this name is not very good – at best it isn’t quite accurate).  A FireMonkey isn’t an “animation”, although what they can used to achieve will – more often than not – be graphical animation.

An animation is simply an object attached to some other component which – when activated – will change one of the components properties in some specified way and doing so over a period of time (independent on speed of the underlying hardware) in response to some event (or continuously, if you prefer).  The sorts of transformations that can be applied to the property being “animated” will vary according to the type of animation you configure.

So, for example, you might attach an animation to a button control to change it’s Color property in response to a MouseEnter event, and a second animator to change it back again on MouseExit.  Or you might gradually increase the Width of a panel to cover a larger area.

You can quickly see I think (or rather envision, given the absence of actual pictures in this report! :)) how very slick and sophisticated GUI’s can be readily assembled using FireMonkey.

You can also hopefully see how over-doing animations, filters and the other tricks at your disposal in FireMonkey could quickly result in the worst sort of garish and flamboyant interfaces.

All good things in moderation!  🙂

And what is FireMonkey not ?

FireMonkey is for building rich and dynamic business applications.  If you want a desktop app that has all the flair and panache of apps on the latest glossy touch based devices, the FireMonkey is the way to go.

But it is not managed code.  It is 100% ObjectPascal and is therefore fully compiled to whatever target platform the Delphi compiler supports.  Under-the-hood it exploits GPU power to deliver it’s capabilities, but it accesses the GPU in a platform specific but portable fashion.  On Windows this means that it utilises Direct2D and Direct3D.  On OSX and iOS it uses OpenGL.  You, as an application developer, do not need to concern yourself with this level of detail however (there is a caveat to that statement which I shall come to in a moment).

It is also not trying to be a platform for RIA (Rich Internet Applications).  FireMonkey does not try to compete with  Air or Silverlight.  It is not a framework for entire applications, nor does it spit out HTML 5 or CSS.   FireMonkey is for desktop – and mobile – native code applications.

Similarly it is not trying to be a platform for building games, although depending on the type of game you had in mind, it could be used for that of course.  But this is no different from simply stating the fact that ObjectPascal itself is not designed to build games – there are no language primitives or design tools in the language for creating sprites or isometrics worlds, but this doesn’t stop someone from using ObjectPascal to do those things if they wish.

Similarly there are no such things in FireMonkey.  And no mention was made of any physics engine support in the framework, for example.

FireMonkey is for building applications.

Sounds great!  Why not put all this in the VCL ?

Those familiar with the recent history of Delphi will perhaps be aware that when the cross-platform project was started, the original intention was to build a cross platform derivative of the VCL, very similar to the approach in the ill-fated CLX of Kylix.  Indeed, it was realised only quite late in the day that if they were to continue down that path then the result would be a Curates Egg.  It would involve compromise both by those who had no interest in cross platform development, but also by those who did.  At the same time it was recognised that some existing technologies could be acquired and built upon to deliver something that would be a compelling replacement for the VCL.

If people were going to have to change, give them very good reasons to do so.

When you see what FireMonkey can do and the way is is put together, you will understand completely why the VCL had to be “left behind”.  But when I say that, I do not mean that the VCL is now a dead technology, far from it.  It shall continue to evolve and be supported for a long time to come I am sure.  But I am equally sure that once you see FireMonkey you will never want to write a VCL application again, even if you never intend writing for anything other than the Windows platform.

GPU Acceleration ?  But I/my users don’t have a GPU !

A valid concern, and even worse, you may have a GPU but sometimes it can’t be accessed.  Some VM and/or RDP platforms for example render the GPU inaccessible.  In those circumstances FireMonkey reportedly (these scenarios were not actually demonstrated) degrades.  I use that word advisedly.  There is no graceful “downgrade” built into FireMonkey.  If you use some element of FireMonkey in your application that relies on a GPU then those elements of your GUI will run, but they will not render.  They will be invisible to your users.

So if those scenarios are important to you, you will have to avoid those aspects of FireMonkey.  Again, I am sure more specific details and guidance on this issue will emerge over the next few weeks and months.

So I can gradually move to FireMonkey in my VCL app ?

Sadly not.  Well, not officially.

Being platform independent, the FireMonkey framework does not rely on – nor indeed even directly use – the Windows message loop.  Or rather the way that is uses that message loop is completely and very technically different from the way that the VCL already does.  Also, the VCL contains several architectural aspects which are built very heavily and specifically on that messaging infrastructure in Windows.

Consequently the two do not co-exist very happily.  Apparently it is technically possible to contrive to incorporate FireMonkey in an otherwise VCL application, but it is potentially unstable and – more important – not officially supported.  So if you do try it, good luck and well done if you can make it work, but you won’t get any help from Embarcadero if you can’t and it all blows up in your face.

But whilst FireMonkey cannot site happily alongside the VCL in an application, a lot of the patterns that you are familiar with from the VCL have been respected in FireMonkey where-ever it has made sense to do so, to try to ease the transition from one to the other as much as anything I imagine.

So FireMonkey Means Lots of Change in our GUI ?

Yes.  Being an entirely new framework and being incompatible with the VCL (in terms of co-existence in the same app) means that if you have an existing app and wish to move it to FireMonkey then you will have to rewrite it’s GUI.

I for one think this was the right move.  It means that FireMonkey is architecturally “clean” and not weighed down by any of the baggage that clinging to the VCL would have brought, and this should only continue to deliver huge rewards and benefits in the future.

But what About DataAware Controls ?  Does FireMonkey at least have those ?

No.

Instead we now have LiveBindings.  These are not exclusive to FireMonkey – LiveBindings work in all Delphi code, be that old VCL or shiny new FireMonkey.

Simply put, LiveBindings provide a connection between two properties on separate objects.  So you can for example bind the “Caption” property of a TLabel to the “DisplayName” of a TDBColumn.

But these aren’t just simply property-to-property mappings.  LiveBindings employs an expression engine to evaluate the bound property values, so you could bind that label Caption property to the expression “‘Column Name is :’ + Uppercase( DisplayName )“, for example.  Obviously such a binding is unidirectional – you could use it to set the label caption to the column name, but you could not use it to update the column name from the label as there is no way to easily “unwind” the expression.

But where a simple property-to-property binding is created, these are – or can be (you decide) – bi-directional.

Clearly, with such a framework a specialised “data aware” control hierarchy is unnecessary.  Not only can LiveBindings be used in place of such a specialised data aware framework (removing the need for separate, data aware versions of controls) but you can use these bindings for all sorts of purposes, not just data awareness.

You want to display the value of a selected item in a listbox in the dialog caption ?  Go ahead, make a binding.

And as a bonus, the expression engine that LiveBindings employs can be used stand-alone to evaluate any ObjectPascal expression, dynamically at runtime.

In Other News

RADPHP and PhoneGap

Using jQuery in RADPHP and a technology called PhoneGap, you can now package up a PHP application and deploy it as a native Android application.  I am not entirely clear as to how this works, but it may be of some interest to those using PHP and wishing to target Android.

DataSnap Client Proxies

As briefly mentioned, DataSnap now provides a facility for automatically generating proxies for you to deploy to developers of client applications wishing to access your DataSnap server applications from a variety of other languages:  Objective-C, C#, Delphi Prism, RIM BlackBerry and others.

Probably quite cool if you use DataSnap.

Colour me Excited!

Whew!  That was a mammoth post, and I am sure I have forgotten to mention something even in all that.

Suffice to say that I was not alone among the 60-70 people attending today’s event to be heard saying “this is exciting”.  Everyone there was giving up and entire working day to hear the news of this release, and every single person I think stayed for the entire day and left very, very happy indeed.

These could at last be the exciting times for Delphi that we have long been hoping for.