Embarcadero has released version 7 of its XE programming suite. The main products included are Delphi and C++ Builder, RAD development tools that share the same underlying libraries and visual designers but give developers a choice of language. Delphi uses an object-oriented evolution of Pascal.
Delphi is best known as a Windows Programming Tool – it used to be the main competition for Visual Basic – but over the last few years Embarcadero has added cross-platform Mac and mobile development with native compilers for OSX, iOS and Android. The IDE runs only on Windows but can compile for the Mac or for iOS New versions have come thick and fast – XE6 was released in April 2014 – so if you want to stay up to date, prefer for frequent upgrades or buy with a support and maintenance agreement. You can buy Delphi or C++ Builder separately if you do not require the suite.
The full RAD Studio also includes HTML 5 Builder, which supports mobile app development using Cordova (open source version of PhoneGap). There seems to be little new in HTML 5 Builder. An earlier PHP tool variously called Delphi for PHP and RadPHP was dropped some time back. I get the impression that Embarcadero is now more focused on its core good thing.
So what’s new? Making effective cross-platform development tools is not easy, with trade-offs between productivity (share more code) and writing the best app for each platform (share less code). This edition introduces a new approach to designing the user interface, called the Multi-Device Designer. It is based on a kind of inheritance. You build your base UI in a master form and write most of the event-handling code there. This master form is automatically adapted, to some extent, to other platforms. You can see how your form looks on these other platform by dropping down a list.
When you select the form for a specific platform, you can modify it for that platform. There is still only one form, but the platform-specific views override properties set in the master form. If you then further modify the master, the changes will flow down to the platform-specific forms unless properties have already been overridden.
My impression after a five-minute play is that you will indeed have to made modifications to get each form looking right; the automatically generated versions were not too good. There is still good productivity potential here presuming the designer proves to be robust.
A common criticism of Embarcadero’s approach is that visual controls are custom-drawn on each platform, rather than using true native controls. That does not matter at all, Embarcadero always assured me. It does matter though; and now in XE7 we have the beginning of a solution. There are a couple of optional Platform Native Controls, TEdit and TCalendar for iOS, which do use native controls. I suspect this will be popular and hope that more platform native controls arrive in due course.
App Tethering is a feature/library that lets you easily set up connectivity between Delphi/C++ Builder apps on a local network. The first version only supported Ethernet/Wi-Fi, but now Bluetooth support has come, including Bluetooth LE on Windows 8 and recent Android devices.
On Android, a new tool called Java2OP lets you generate Object Pascal interfaces for Java Android classes, which sounds handy.
Aside: the naming of this tool suggests that the language is now called Object Pascal again, rather than Delphi, which became the official name some years back. Object Pascal makes more sense to me.
The System.Threading library now includes a new parallel programming library, including Parallel For, task scheduling, and futures. Futures are a way of creating code that will run at an indeterminate time. You associate a variable with a function that calculates its value. That function will run when you access the value, or before that if a background thread is available.
The IDE now has limited Git support (local repository only).
Another new piece in XE7 is Enterprise Mobility Services, a REST-based middleware stack that runs as an ISAPI DLL in Microsoft’s IIS web server. This includes database connectivity (using the FireDAC library), user management (though not Active Directory integration as yet, as I understand it) and usage analytics.
If you are using IIS, why would you not use ASP.NET and the Web API? The answer is that with EMS you can do end-to-end Delphi/C++ Builder as well as getting the performance of native code on the server.
Challenges for Embarcadero and RAD Studio
In the nineties it was Delphi versus Visual Basic, and although most developers who gave Delphi serious attention discovered that it was superior in most ways to Microsoft’s tool, the big-company backing and integration with Microsoft’s overall platform meant that VB was not much disrupted (though we may have Delphi to thank for the appearance of native code compilation in VB).
Today Embarcadero is up against Xamarin, which is similar in that it gives Microsoft platform developers a route to cross-platform development for Mac, iOS and Android.
From what I hear, cross-platform support in RAD Studio has been successful in reinvigorating the product within its niche, but it is Xamarin that has grown explosively, thanks to a combination of the C# language, Visual Studio integration, and a degree of official endorsement from Microsoft. Whereas Xamarin fits with Microsoft’s Universal App concept, shared C# code across all platforms, RAD Studio takes its own path, avoiding .NET in favour of native executables.
[I realise that there is endless debate about what native means, and that while RAD Studio has a good claim to native code, it is weak when it comes to native controls as noted above].
Unlike Xamarin, which has its own cross-platform IDE for Windows and Mac, RAD Studio requires Mac developers to use a PC or a Windows VM.
Embarcadero chose not to support Windows 8 “Metro” or Store apps, a decision which now looks wise, though it could yet work against them if Universal Apps are more compelling in Windows vNext. Another omission is Windows Phone; perhaps this does not matter greatly given its small market share, but within the Microsoft platform community it is a bigger lack than simple market share implies.
The advantage of the RAD Studio approach is that it is less dependent on Microsoft’s constant changes of direction, and performance is generally good. I have always been a fan of Delphi. There were some quality concerns when the FireMonkey cross-platform UI library was first adopted, but now in RAD Studio XE7 there is reasonable hope that the library is mature enough.
RAD Studio is the obvious route for long-time Delphi or C++ Developers migrating to mobile; it is a viable niche but I question whether it can ever move beyond it to grab a share of the wider mobile development market.
More information here.
Nice review.
Nothing too exciting in this version – the parallel library sounds very close to the great OmniThreadLibrary, right?
Integration of all platforms within one FMX view does make sense. But what about the R2L bidirectional scripting support?
What about the IDE stability? Is it better than XE6? How many bugs were fixed?
What about the compiler? Is really LLVM available for Win32/Win64? Is there any breaking change?
Xamarin did a great job, and their “Forms” – see http://xamarin.com/forms – framework, even if limited to a common subset of simple components, is very close to what FMX offers. Now they are addressing the performance problems of the Mono runtime.
And HTML5 apps are a very good solution now – especially with the upcoming Tizen Samsung phones. There are even tools to use object pascal (yes, I do like the name, too) and compile it into optimized JavaScript, so that you are able to share a lot of code between Delphi and HTML5 apps.
But FMX has some advantages, e.g. for integration with low level libraries (e.g. for cross-platform video streaming – which is still PITA in HTML5 or Xamarin).
The fact that RAD Studio is “less dependent on Microsoft’s constant changes of direction” is indeed a MAIN feature.
Managers should take this point in account.
Dear A. Bouchez,
Every solution may be have some defects, Xamarin and Embt is not excepts.
Here, you discuss about Embt solution(FireMonkey) and comments something about Xamarin like in the Xamarin land, all things okay and perfect. If you detail about Xamarin.Forms, you will get, there is a lots of limitation. But every where that discuss about FMX, somebody says Xamarin.
If Xamarin`s solution is mature and Satisfying product at all, you could use it in all your projects.
Your Sincerely
Mehdy Karimpour
Embarcadero didn’t actually “choose not to support Metro.” Microsoft set up the system in a way that essentially made it impossible for anyone outside of Microsoft to build a native-code language that would validate, because certain essential features (notably exception handling) are inaccessible to anything except the Visaual C++ Runtime. Embarcadero brought this to Microsoft’s attention when it first came out, but AFAIK Microsoft still hasn’t gotten around to fixing it.
So much for “Developers! Developers! Developers! Developers! Developers!”
Gold star for Mason Wheeler. Embarcadero was shut out by Microsoft.
“Another omission is Windows Phone; perhaps this does not matter greatly given its small market share, but within the Microsoft platform community it is a bigger lack than simple market share implies.”
No. It’s not bigger, and the market reflects it.
Still no CLANG for Win32. I know it’s difficult to port a toolchain from elf to PE, but WE NEED compatible compilers between Win32 and Win64. Also it’s absolutely necessary to have the same boost library in both environments. In the BCC64 side, which clang compiler they are using? The 3.1 again? Clang is at the 3.5 version. I’m wondering why it’s so difficult to stay aligned with the last version. If they stays with 3.1, in few years, the BCC64 will be left behind as BCC32.
The quicker Emba switches away from being MS-centric, the better for Emba’s possible future.
I am using XE6 with FMX – there are some annoying bugs, but I like it better than the VCL even for Windows products. As mentioned above, hopefully Emba focuses (or focused) on fixing various bugs that were in XE6. I’ve noticed the documentation getting significantly better, which is also a big deal.
The term ‘FireUI’ also sounds good, unlike FireMonkey which sounds a bit silly.
Mason and Kyle are incorrect.
>Embarcadero didn’t actually “choose not to support Metro.”
Initially they did. An anonymous Embarcadero employee who goes by the handle “Embarcadero Insider” reported that there was initially no plans to support Metro. EMBT’s chief scientist, Allan Bauer, decided to look into the prospect *60 days* before the release of the first Delphi version after Windows 8 shipped. Even if Microsoft was willing to bend over backwards for Delphi, there simply was no time to add support to the product. Honestly, this suggests the scary idea that they regularly add features right up to the last minute before shipping (which would explain the quality).
After blaming Microsoft for their own lack of effort, EMBT appear to have completely dropped the initiative and have done nothing whatsoever to add real Windows 8 support. Meanwhile, a major FMX competitor they tend not to acknowledge, Digia (Qt) also encountered the same problem. However, they publicly announced they were forming a committee to investigate the issue. The committee produced a public white paper outlining the changes that would need to be made to the product to get it to run on Metro. They proceeded to make those changes in the next release, and the release after that now has support for Windows 8, apparently without any help from Microsoft! That’s the difference between the two – Digia had the will, EMBT (as is often case) just seemed like it couldn’t be bothered.
>(notably exception handling) are inaccessible to anything except the Visaual C++ Runtime.
Then you use the Visual C++ Runtime.
What I see with XE7 is that EMBT is still acting like their only competition is their previous release. That was fine (for a time) for Microsoft. which had a monopoly. Delphi’s a niche product and it needs to grow its user base to try to revive the dying ecosystem. To do that it needs to be better than its competition, which as you pointed out, isn’t VB6 anymore – although to listen to EMBT you wouldn’t know it. In fact, they make no mention of any other languages on their website and I’ve found it impossible to get EMBT folks to pitch me the strengths of their product vs. C#, C++, Java, etc.
Looking at things in this perspective, Mr. Bouchez really hits the nail on the head. (Limited) Git support? Even MICROSOFT, which has consistently limited VS VCS support to their own product, finally relented and began supporting Git. Embarcadero doesn’t even have a VCS product and yet they become the last significant IDE to offer (some) support. How many more years will it be until Mercurial is supported? This “feature” won’t win anyone over who isn’t using the product.
Futures and a basic thread pool for parallel operations are nothing that isn’t already present in the “big” languages in native or library form. Worse, the folks behind Delphi have been talking up significant parallel language support for *eight years*, as far back as when they were still CodeGear. EMBT’s CEO talked about parallel features for Delphi at a keynote in *2008*. Either it took them 8 years to, as Mr. Bouchez points out, give us what OmniThread already has, or they’ve just been stringing us along for most of that time. 🙁 Again, nothing new here. In a world with languages like Go that aim for easy parallelization, Delphi needed to deliver something genuinely new, that we haven’t seen before. This won’t entice anyone either.
They now bundle IBLite for free? That just shows that no one was going to pay $60 for it (plus redistribution fees). SQLite is available on mobile platforms already without the limitations of IBLite and is smaller, faster, more reliable and more supported, as it’s the most widely deployed embeddable DB.
The small changes to arrays are also nothing not present in other languages.
If someone wasn’t swayed before, I don’t know what in XE7 would sway them now. As others pointed out, there are still many things missing, such as the new unified desktop compiler that’s been promised for at least a year and a half now, along with automatic memory management, cleaning up of the string types, 64bit OS X support, Linux support, etc. The product still offers no native Decimal type, no bigint, no (real) complex number type, no native logging library, no native profiling library (it bundles a crippled 3rd party product that only works on 32bit code), no native documentation solution, no native HTML parsing, no modern features like type inference or contracts, poor serialization support, even a cross-platform command to launch a process (Want to launch a PDF with the default viewer in cross-platform code? You need conditional compiler commands and to use the native OS-level process command for each OS!).
On top of this, just as last release AppTethering launched with almost no documentation, this time around the EMBT wiki has no information on the parallel processing features – worse, the forums went down today, after having been down for a few weeks just recently. Users weren’t even told the day the product would be released!
Delphi’s still running behind and the user experience is still poor in terms of documentation, support and communication. It’s 2014 and people can, with a few clicks, download Java and IntelliJ Community Edition/Eclipse or MonoDevelop (C#, F#), or PyCharm and Python or gcc/Clang and almost any IDE along with Qt, which goes toe to toe and then some with FireMonkey while being more mature (on desktop) and LGPL and start coding for free on any and for any platform they choose. For Delphi’s $1000+ starting price, Embarcadero needs to offer truly novel features and exceptional service. They still seem content to compete against VB6 and their previous version.
I see a few misconceptions in some comments, so I guess it is worth clarifying a few points.
Speaking of WinRT support on desktop, there are a couple of points. First, I doubt we can use the VisualC++ Runtime (which gets “special permission” from Microsoft) from a Delphi application. Unless you are willing to rewrite most of your code. Second, trusting and repeating information coming from an anonymous source is quite a nonsense, the company looks into technologies as soon as we learn about them. Third, given the current status of WinRT, Windows store and Windows directions, I doubt RT is making big inroads, particularly for Enterprise customers. It has certainly been far from a big success for Microsoft. Desktop apps still rule Windows, at least for now.
Comparing the Parallel Programming library that ships in XE7 with OmniThread is fine, but the latter is limited to one platform, compared to four. One can argue if having parallel support and the language or RTL level is better, I don’t dislike the RTL approach (with full source code and control by developer), but we might as well in the future offer more language integration.
I agree it will be foolish to built and design Delphi to compete with VB6, in fact we are adding multi-device and native mobile features that compete with different products in the market. Products that are generally not free and are often much more limited. There is no other tool in the industry with a feature like the current multi-device designer in XE7. Is this model after VB6? Or is it above and beyond with Xamarin delivers today? Just asking…
As far as I know, all Tizen Samsung phones have actually been placed on hold and while building HTML-based mobile apps is a viable solution, nothing to argue on that, I think that our native solution offers a superior platform integration, with the ability to call any native library on each platform, and now even take advantage of your multi-core phones better than most other tools out there.
Our tools do have some shortcomings (which doesn’t?), but focusing only on those and not seeing at the degree of innovation RAD Studio is offering (App Tethering, FireUI, Parallel programming… among many others) is quite shortsighted.
Marco, I tried to click my way through many corners of the Parallel Programming Library here at http://docwiki.embarcadero.com/Libraries/XE7/en/System.Threading, but there is NO information at all. Is there anyway to get to this, without installing all of XE7 and then hoping for sample applications?
The is a sample application you can browse online in the RAD Studio Demos repository on source forge. More blogs and demos will appear soon.
It’s joke.The sample application report memory leak on the Parallel Programming Library
Many sample applications are joke – some of them give AVs (for example FireDACSamplesPhys LayerIFDPhysConnectionCreateConnectionCreateConnection.dproj – simple problem – FDConnectionDefs.ini is not in the expected folder), many use deprecated symbols (most Firemonkey ones).
But my worry is that some of the key new features in XE 7 are released with bugs that are so easy to spot:
– Simple ReportMemoryLeaksOnShutDown:= TRUE; in ConwaysLife.dpr would reveal the memory leak in TParallel.For…
– What about the silly mistake in System.Win.Bluetooth.pas – see https://quality.embarcadero.com/browse/RSP-9560
How such key features in the XE7 release could be released FOR SALE? Any Quality Control?
How do I port an XE6 FireMonkey Mobile project to an XE7 Multi_device Application project?
If I simply open my XE6 project it does not seems to be converted to the new format.
Thanks.
The Win32 compiler is not using LLVM/clang yet, but it is coming. It just wasn’t production-ready in time for XE7’s release, but it might appear in a later Update, if not in XE8. The Win64 compiler (and others) do not stay aligned with the latest LLVM/clang because EMBT has to incorporate its compiler extensions into new releases and get them merged into the main codeline. That is a non-trivial and time-consuming task.
I was i.a. quite interested in the new parallel library. But I found nothing compelling to even consider moving back from C++, Qt and Intel Threading Building Blocks. To me, EMBT´s competition seems to be so far ahead of them.