Tag Archives: delphi

Xamarin vs Titanium vs FireMonkey: should cross-platform tools abstract the GUI?

Cross-platform development is a big deal, and will continue to be so until a day comes when everyone uses the same platform. Android? HTML? WebKit? iOS? Windows? Maybe one day, but for now the world is multi-platform, and unless you can afford to ignore all platforms but one, or to develop independent projects for each platform, some kind of cross-platform approach makes sense, especially in mobile.

Sometimes I hear it said that there are essentially two approaches to cross-platform mobile apps. You can either use an embedded browser control and write a web app wrapped as a native app, as in Adobe PhoneGap/Cordova or the similar approach taken by Sencha, or you can use a cross-platform tool that creates native apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero FireMonkey.

Within the second category though, there is diversity. In particular, they vary concerning the extent to which they abstract the user interface.

Here is the trade-off. If you design your cross-platform framework to include user interface widgets, like labels, buttons, grids and menus, then you can have your application work almost the same way on every platform. You can also have tools that build the user interface once for all the platforms. This is a big win in terms of coding effort. If the framework is well implemented, it will still adopt some of the characteristics native to each platform so that it looks more or less native.

Some tools do this by drawing their own controls. Embarcadero FireMonkey is in this category. Another approach is to use native controls where possible (in other words, to call the API that shows a button, rather than drawing the button with the graphics API), but to use custom drawing where necessary, even sometimes implementing a control from one platform on another. The downside is that because those controls are not in fact native, there will be some differences, perhaps obvious, perhaps subtle. Martin Fowler at ThoughtWorks refers to this as the uncanny valley and argues against emulated controls.

Further, if you are sharing the UI design across all platforms, it is hard to make your design feel equally right in all cases. It might be better to take the approach adopted by most games, using a design that is distinctive to your app and make a virtue of its consistency across platforms, even though it does not have the native look and feel on any platform.

Xamarin Studio on the other hand makes no attempt to provide a shared GUI framework:

We don’t try to provide a user interface abstraction layer that works across all the platforms. We think that’s a bad approach that leads to lowest common denominator user interfaces.*

CEO Nat Friedman told me. He is right; but the downside is the effort involved in maintaining two or more user interface designs for your app.

This is an old debate. One of the reasons IBM created Eclipse was a disagreement with Sun over the best way to design a cross-platform user interface framework. Sun’s Swing framework, derived from Netscape’s Internet Foundation Classes first released in 1996, takes the custom-drawn approach, which is why Swing apps always look like Swing apps (even if you apply the “Windows” look and feel). A team from IBM, some originally from Object Technology International which was a company acquired by IBM, believed it was better to wrap native controls with a Java abstraction layer, created SWT (Standard Widget Toolkit) to do that, and used it to build Eclipse.

Personally I am wary of toolkits which rely heavily on custom-drawn controls rather than native controls, though I see their value. On the other hand, Xamarin Studio is so far in the other direction that it removes some of the benefit of a cross-platform framework.

My prediction is that Xamarin will come up with its own GUI abstraction framework in future, along the lines of SWT. It is a compromise; but one which delivers a lot of value to developers who want to create cross-platform apps with the maximum amount of shared code.

*I have never understood this use of the term “lowest common demominator”. The LCD in maths is the lowest number into which a specific group of numbers divide exactly, so it is an elegant thing. In cross-platform what you should strive for is the highest common intersection: to make available all the features common to each platform.

Update: in April 2014 Xamarin announced Xamarin Forms, a GUI framework which wraps native controls in a XAML implementation (XAML is the presentation language also used by Microsoft, for WPF, Silverlight, Windows Phone and Windows Runtime (Windows 8) apps. There is a quick hands-on here.

Embarcadero acquires AnyDAC data access libraries for Delphi, C++ Builder

Embarcadero has acquired the AnyDAC data access libraries from DA-SOFT, including its main author Dmitry Arefiev. These libraries support Delphi and C++ Builder and support connections to a wide range of database servers, including SQL Server, DB2, Oracle, PostgreSQL, SQLite, Interbase, Firebird, Microsoft Access, and any ODBC connection.

AnyDAC is well liked by Delphi devlopers for its performance, features and support. Its architecture includes a local data storage layer similar to the dataset in Microsoft’s ADO.NET.

While it is good to see this set of libraries added to the mainstream product, developers are asking the obvious questions. What will happen to the cost and to the support for AnyDAC?

I am both scared and relieved at the same time. We took the AnyDAC route a few years ago, getting out of the BDE, and we have not regretted it for a second. My fright comes from the fact that DA-SOFT could not be beat in terms of customer support…many of us have come to DA-SOFT with a problem, only to have it fixed the next day. It is only realistic to think that with Embarcadero, this will no longer be the case.

says Dan Hacker on product manager Marco Cantu’s blog.

Hands on Cross-Platform Windows and Mac development with C++ Builder XE3

I have been writing about Embarcadero’s RAD Studio XE3, which includes Delphi and C++ Builder, and as part of the research I set this up for cross-platform development on a Mac.

My setup uses a Parallels Virtual Machine to run Windows 7, on which RAD Studio XE3 is installed. This is convenient for Mac development, since the IDE itself is Windows only. That said, if I were doing this in earnest I would use multiple displays or perhaps separate physical machines, since it is no fun debugging in a VM with the application running in another operating system behind it.

Is it straightforward to configure? Not too bad. You have to install Xcode on the Mac, and in addition, you have to install the Xcode command line tools, which you can do from Xcode itself, in Preferences – Downloads – Components, or as a separate download.

image

Then you need to find the Platform Assistant (paserver), an agent which runs on the Mac to support remote debugging. I was annoyed to find that this has a dependency on Java SE6, which to be fair it downloaded and installed automatically. Actually I find this amusing, after hearing from an Embarcadero VP how native code is all the rage and nobody uses managed code any more. Except Embarcadero for the paserver.

Once that is all up and running you are done on the Mac side. On Windows, you then need to sort out a remote profile, after having installed RAD Studio of course. The way to do this is first to start a new cross-platform project, which means using the FireMonkey framework. Then right-click TargetPlatforms in the project manager and add a platform. If you add OSX but no remote profile exists, you will be prompted to create one.

image

This is where something went slightly wrong. I created a profile and could connect OK. However, when I tried to build the project, I got an error: Unable to open include file ‘CoreFoundation/CoreFoundation.h’. You get this if for some reason the required library files have not been pulled over from the Mac. The fix is to edit the profile and click Update Local File Cache.

image

After that I was away. Set breakpoints if needed, build and debug.

image

Cross-platform is not new in RAD Studio; it was in XE2, and in some ways better, since you could target iOS as well as OSX. C++ Builder XE3 is actually a new generation though. In the 64-bit update 1, it is the first release to use Clang and LLVM, and from what I understand this represents the future for Embarcadero’s tools.

Updates are promised in 2013 for both Delphi and C++Builder – this roadmap is most of what we have to go on – which will add first iOS and later Android support, at what the company calls a “low cost”. Unlike the iOS support in XE2, the coming update will not use the Free Pascal compiler, but the new architecture based on LLVM. This also suggests that the add-on will replace some of the guts of Delphi when it arrives, so it will be significant and somewhat risky.

The cross-platform capabilities look good, though I am somewhat wary of FireMonkey which is less complete and mature than the Windows-only VCL. For example no Webbrowser component is supplied, which is a significant limitation, though I am sure there are ways of hacking this, perhaps through ChromiumEmbedded for which a Delphi FireMonkey exists.

It is worth a bit of effort, since Delphi and C++Builder are productive tools, and the output is true native code which still had advantages.

More information on RAD Studio XE3 is here.

Embarcadero launches C++ Builder XE3: first built on Clang

Embarcadero has released C++ Builder XE3, the first version built on the open source clang front end for the LLVM compiler. This has enabled the product to support many new features, including extensive C++ 11 support and a 64-bit compiler.

image

While it is a shame that the old Borland C/C++ Compiler is no more, it makes sense for Embarcadero to bring its VCL (Visual Component Library) and FireMonkey framework to Clang rather than continuing to work on its own compiler.

The other big change is cross-platform support. Through FireMonkey, C++ Builder XE3 supports Windows (including Windows 8) and Mac OS X, with iOS and Android promised for 2013.

Although Windows 8 is supported on the desktop, there is no official support for the Windows Runtime (Windows Store apps). Instead, Embarcadero has a curious application framework called Metropolis which fakes the Windows 8 style but with desktop applications, as if the Windows 8 world were not already sufficiently confusing.

The big question is how compatible VCL applications created for earlier versions of C++ Builder are with the XE3 release. With a new compiler and major changes to the VCL in order to support the new compiler, you might expect some issues.

“That’s what we’ve been spending all of our time on,” Embarcadero VP Michael Swindell told me. “This is fully compatible with all our previous C++ dialects. We’ve completely re-engineered the C++ front end but it’s engineered to be compatible with C++ Builder applications and Borland C++ applications.”

I would rather hear that from developers though, rather than from Embarcadero.

Although C++ Builder is a cross-platform compiler, it only runs on Windows. A common scenario is to run in Windows emulation on a Mac, using VMware Fusion or Parallels.

Similar changes are on the way for Delphi, which uses the same VCL and FireMonkey frameworks but with the Delphi language based on Object Pascal.

Note that the new Clang-based compiler is 64-bit only. You are meant to continue using the old Borland compiler for 32-bit, making it hard to maintain a single code base for both.

Embarcadero releases RAD Studio XE3

Embarcadero has released RAD Studio XE3, a major upgrade to its suite of tools for Windows, cross-platform and web development.

New in this version:

  • Windows 8 compatibility
  • Metropolis framework for desktop apps that have the look and feel of Windows 8 “Modern UI” (formerly Metro) apps. Live Tile support is included via a proxy Windows Runtime app.
  • Prism XE3 for .NET development, including support for the Windows Runtime in Windows 8, using a Delphi-like language.
  • Version 2 of the FireMonkey cross-platform framework, with improved touch support, a new grid control
  • Easier data binding in both FireMonkey and the Windows-only VCL (Visual Component Library) framework
  • New HTML5 Builder tool which replaces RadPHP. The new tool supports cross-platform mobile development by integrating PhoneGap, which lets you wrap HTML apps as native mobile apps.

Mac OSX support is included but iOS support has been removed, pending release of a forthcoming Mobile Studio product.

64-bit C++Builder is not in this release. 64-bit Delphi was introduced in the previous XE2 release.

Embarcadero has backed down from a proposed change to the license for the Professional edition which prohibited connection to remote databases. This restriction now only applies to the dbExpress database framework.

More when I have installed the actual release. The most eye-catching feature is Metropolis, though whether there is really a demand for a fake Modern UI framework is an open question. There are also concerns about deployment, which will not work on Windows RT (the ARM version) and may involve some hacks on x86, since it cannot go through the Windows Store.

image

Last year’s RAD Studio XE2 was an amazing release in terms of announced features, but plagued by quality issues which left some developers disappointed.

Delphi XE3 Professional downgraded to local databases only

There is a bit of a stir in the Embarcadero community following the leaking of a document which appears to be an email to partners concerning a major change in the EULA (End User Licence Agreement) for the Professional edition of Delphi, the RAD development tool for Windows (with lately some cross-platform capability).

This email is to let Embarcadero Technology partners know about some changes being made to the EULA changes in our XE3 release.

In particular, the use of data access technologies for client/server connectivity will no longer be allowed in the Professional edition.
This includes both Embarcadero and 3rd party solutions. Professional users may only, legally, access local databases with their applications.

Users who want to use client/server database access can purchase a Client/Server Add-On Pack for their Professional edition or purchase
an Enterprise, Ultimate or Architect edition product.

This restriction if for new licenses only.  Users upgrading to XE3 will be "grandfathered" in that they will be able to continue to use 3rd party data access technologies for client/server database access in version XE3. Additionally, Starter Edition has been restricted to use of MyBase (.CDS or .XML file formats) only for "database access."

While this has not been officially confirmed I believe the email, at least,is authentic. Embarcadero’s David Intersimone implicitly confirms it with comments in the lengthy discussion on the Embarcadero forums.

It sounds complex and, like many software licences, based essentially on trust rather than technical limitation.

In the past, Professional has been the edition of Delphi to get if you want to do real work but do not need fancy stuff like modeling tools, advanced database frameworks and so on.

A “Professional” edition with local database access only does not deserve the name. This kind of restriction is usually reserved for tools aimed at hobbyists or intended mainly for trial purposes.

The news has not gone down well. Some of the most vocal on the Embarcadero forums are partners whose add-ons will no longer be legal to use with the Professional edition.

As a loyal Delphi developer since 1995… and as an Embarcadero Technology Partner… I cannot simply sit by and say nothing. This EULA change is WRONG. There’s no moral ambiguity here! It doesn’t tow a line, fall into a "grey area" or wobble on the tightrope… it is simply wrong. It crosses every line: ethically, morally, and progressively. Not only that, but as an idea it is patently stupid! The condition is financially and logistically unenforcable, and the only thing it does is serve to deter new customers.

says Simon Stuart, creator of the Lua4Delphi library.

The core problem here? It is hard to make money on development tools, given the competition that is either free or provided by platform vendors (meaning Microsoft or Apple) who have every advantage in terms of finance and inside knowledge.

Delphi is a fantastic tool; but Embarcadero still struggles with quality issues. The answer is greater investment, but where does that come from? Upping the price is one strategy, though it is no sure-fire solution as the above debate demonstrates.

Update: It appears that Embarcadero has backed down. The “finalized” EULA states that the local database restriction only applies to dbExpress, a specific Embarcadero database framework:

Licensee may not use that portion of the Product identified as “dbExpress” in association with a database located on a different machine other than the machine on which the Works are installed.

Third-party compilers locked out of Windows Runtime development

Embarcadero’s chief scientist Allen Bauer has posted about the problems facing tool vendors who want want to support Microsoft’s Windows Runtime (WinRT) platform with their own compilers, which he calls “Windows 8’s ‘dirty little secret.’”

The issue is that in order to enforce security and isolation in WinRT apps, Microsoft prohibits certain API calls. Even if you find a way to use them, applications that use these calls will not be accepted into the Windows Store, which in effect means no public distribution.

We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you’re the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management… Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store.

Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user’s app. We’re currently rattling some cages at MS to find out how or if they’re going to allow third-party tools to target WinRT. Until we can get past that, targeting WinRT isn’t actually possible from a deliverable product sense. We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs.

Bauer adds that there are other restrictions that make it hard to create an alternative toolchain:

For instance, you cannot merely open any file, access the registry, and even use the loopback (127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary DLL; you must call LoadPackageLibrary and only on a DLL that is present in the digitally signed appx package. WinRT is a seriously locked down sandbox or "walled-garden" with some extremely high walls.

Embarcadero’s answer has been to create a framework that makes desktop apps look and behave somewhat like WinRT apps. I posted about these fake metro apps here. Even Live Tiles are supported. However, these apps cannot be distributed via the Store either, but only through a desktop setup. In addition, they lack the security of true WinRT, and access to the Contracts system for safe exchange of data.

The company does have a .NET tool in the works, called Prism, that will build WinRT apps.

Who is the villain here? Embarcadero’s concern is understandable, since it is locked out of creating a native code compiler for WinRT. On the other hand, to what extent can Microsoft relax the restrictions without blowing a hole in the WinRT security story. There are parallels with the complaints from Google and Mozilla that they cannot compete equally with IE10 in the Modern UI environment.

Thanks to .NET support, Microsoft does have a measure support for alternative languages; it is the Common Language Runtime after all. What would be better though would be to support LLVM, as Apple does on iOS, though this is not likely to be on Microsoft’s roadmap.

Thanks to Eric Grange for pointing me to this post.

DevExpress offering Metro-inspired Tile control for Delphi VCL, plans to drop support for Delphi 7

DevExpress has released an update to its VCL component suite, version 12.1, which includes a Metro-inspired tile control. That is, it looks like a Windows 8  Metro-style application, but in reality it runs as a desktop application. The VCL components support Embarcardero’s Delphi and C++ Builder, but not the FireMonkey library that runs cross-platform.

image

The new release also adds a “Server Mode” for  the ExpressQuantumGrid grid control, which retrieves only those rows needed to populate the current view.

DevExpress CTO Julian Bucknall has posted about the update. He says it is time to drop support for Delphi 7 (though this is supported in 12.1):

12.1 will be the last version to support Delphi and C++Builder 2010. I will sound a further note of caution: it’s likely that in 2013 we shall drop support for Delphi 7 and Delphi 2007 (what you might call the “ASCII IDEs”), so that we can concentrate on the latest run-times and environments.

Delphi 7 is significant because it was the last version to use its own dedicated IDE built with Delphi itself, and by today’s standards is delightfully small and fast.

Bucknall has reservations about Embarcadero’s move to Clang and LVVM for 64-bit C++ Builder and eventually for the other languages too:

I’m going to say we shall treat it with kid gloves. Re-engineering a compiler so fundamentally says “breaking changes” to me, especially given the necessary extensions that are present in the current C++Builder to interface with Delphi. So, fair warning: if the changes are too severe, we shall not support 64-bit C++Builder in 12.2. It took us long enough to support 64-bit Delphi across our entire product line, and this year we don’t have the resources. That doesn’t mean we won’t ever do this (after all, Embarcadero are saying that they’ll switch completely to Clang/LVVM at some point), just that we won’t this year.

Returning to the Tile Control: it will be fascinating to see if this sort of approach, mimicking Metro with a desktop app, becomes popular. Microsoft is promising some of the same with Office 15, though we have not seen much of this officially yet. The advantage is that you can make desktop apps just as touch-friendly as Metro apps. The disadvantage is that you do not get Windows Store support, Contracts, app isolation, or other benefits of the Windows Runtime which underlies the Metro side. Users may be confused.

I doubt Microsoft will mind though. It all helps to promote the Metro style which is the distinctive feature of Windows 8.

Embarcadero adopts open source Clang for future C++ versions

A couple of months ago Embarcadero’s John Ray Thomas published a roadmap for the company’s C++ tools. Coming soon: not only a long-awaited 64-bit compiler for Windows, but also native iOS and Android support. On top of that, there are plans for “the very best in C++11 and C99 language and library compliance in the industry.”

Sounds good; but this forthcoming upgrade is not quite what it seems. I spoke to technical evangelist David Intersimone about the changes. The company is adopting Clang, an open source project which creates a C/C++/Objective C front-end for the LLVM compiler. “We’re integrating all that into our IDE,” said Intersimone. “We’re also going to be using that same toolchain world with our Delphi compiler as well.”

“We have analysed what to do about C++. Our compilers both for Delphi and C++ have been around for a lot of years, and over time it just got harder and harder to add new capabilities to make programming simpler and also to add power and richness to the languages. In C++ in particular the language continues to be updated, with now C++ 11. So we made the decision to use Clang and LLVM on the C++ side, for the 64-bit compiler. We’re going to keep our existing compiler for 32-bit Windows for now, and then eventually replace that.

“For Delphi we’re still using our existing compiler to do some of the work, but we’ve been working on a next-generation compiler for Delphi and that is still in the works. For a while we’ll have two compilers, the existing architecture compilers, and then new compilers.”

Embarcadero has its own C++ extensions to support component development, and is working on adding them to Clang. “We’re leveraging and extending the Clang compiler with the property-method-event extensions that we added to our own C++ compiler.”

It is a sad moment in some ways, bearing in mind the long history of what was once the Borland C++ compiler. Equally, it is a sensible move. Intersimone said that the work of keeping up with the evolving C++ specification was disproportionate to the benefits. “It’s a monster language, with a lot of power and a lot of complexity. It made perfect sense to fit our extensions [to Clang] versus building a compiler from scratch and having to continue to track the language into the future.”

Embarcadero can focus instead on its IDE and tools, and on the frameworks for Windows and for cross-platform.

Look out for a more detailed interview with David Intersimone in a future article for Hardcopy.

Embarcadero updates Delphi XE2, full reinstall required

Embarcadero has released Delphi XE2 Update 4. The depressing news is that you have to uninstall RAD Studio completely before installing the update. The reward is a large number of bug fixes, listed here, as well as new features:

  • Printing support in FireMonkey OS X
  • Support for Free Pascal 2.6 in FireMonkey iOS
  • New FireMonkey types and methods
  • New VCL styles
  • 64-bit type library import, for using COM libraries in Delphi

Delphi XE2 was somewhat rough on first release, so upgrading is advisable. Maybe it is now sufficiently robust to attract those more cautious developers who do not like to use new products in their first incarnation.