Category Archives: embarcadero

delphi, embarcadero, professional

New Delphi and C++ Builder Roadmap promises Linux server support

7 Comments

Embarcadero has published a new roadmap explaining what to expect in forthcoming editions of its RAD Studio suite, including Delphi and C++ Builder.

The company has been acquired by IDERA though the Embarcadero brand is to continue under the new ownership.

The roadmap covers two “development tracks”, though it is not completely clear what that means. One is described as the “Spring development track” which suggests a release in April, 12 months after RAD Studio XE8. However, the post adds that “The team is working the following features that will be included in 2016 releases,” raising the possibility that some features in this track may come later, perhaps in the scheduled summer update.

The Spring track, to be called “Berlin”, seems to be mainly a tidying-up exercise in any case, with features including Bluetooth LE support for Windows 10, DirectX 12 support, native support for Utf8String on all platforms (you mean it does not have this already?) and enhancements to the FireMonkey cross-platform framework.

“Spring” also offers C++ CLANG 3.3 on all platforms.

The second development track “will deliver a Fall release”, to be known as “Tokyo”, following the pattern of recent years where RAD Studio has two major updates every year. The Fall track is more interesting, and includes support for Delphi and C++ Builder on Linux Server, as well as “Linux platform support for console apps with IoT support.” I guess non-GUI Linux is the common thread here.

The IDE will remain on Windows, with cross-compilation for Linux. Initially supported distributions are Ubuntu Server and RedHat Enterprise, though further distributions will be added “as demand dictates”.

It is good to see Linux support back in Delphi. I remember Borland Kylix (2001-2003) well, but this was back in the days when desktop Linux looked like more of a thing.

The feature-list for Tokyo also includes Windows Centennial support. This is potentially big news. Centennial is a Microsoft project to deliver Windows desktop applications through the Windows Store, using application virtualisation based on the existing App-V technology to remove dependency issues. You can expect to hear more about Centennial at Microsoft’s Build conference at the end of March; it was covered at last year’s Build but we have not heard much more about it since.

image

Embarcadero is also promising a new installer for RAD Studio, based on its GetIt technology, which will reduce installation time and give more flexibility in selecting features. This would be welcome; I never look forward to installing RAD Studio as it tends to be a time-consuming process. It would also be good if it messed less with system environmental variables, though I do not know if this is on the cards. The new installer will comes in two phases, phase 1 in Berlin and phase 2 in Tokyo.

My own view is that two major releases a year is one too many, so I would prefer if Embarcadero scrapped Berlin and went straight to Tokyo.

android, embarcadero, Internet of things, ios, microsoft, software development

Delphi and RAD Studio 2015 roadmap: no Universal Apps?

4 Comments

Embarcadero has posted a roadmap for RAD Studio 2015, its suite of tools for building apps for Windows, Mac, iOS and Android.

Note that the company says the (sketchy) plans outlined are “not a promise, or a contract”.

I will be interested to see if the company intends to support the Windows 10 Universal App Platform (UAP), which Microsoft is pushing as the future of Windows client app development. UAP apps run on the Windows Runtime, a sandboxed environment introduced in Windows 8. In Windows 10, UAP apps are integrated with the Windows desktop, and run on Windows Phone and Xbox as well as on PCs and tablets.

When Window 8 came out, Embarcadero came up with a project type called “Metropolis”, which simulated the Windows 8 Metro environment but with a Win32 executable. It was neither one thing nor the other, and mostly ignored as far as I can tell. That said, lack of support for Windows 8 Store apps proved to be no big deal, because of the low take-up for the platform in general. At this stage, nobody knows whether the UAP may be similarly unsuccessful, though it seems to me that it has a better chance thanks to its broader scope and changes that have been made.

The roadmap promises “Integration with new Windows 10 platform technologies” but does not promise support for the Windows Runtime or UAP, so my assumption for the moment is that Embarcadero is steering clear for the time being. There may also be technical challenges.

Not much new is promised for the venerable VCL (Windows-only apps), and only a little more for the cross-platform FireMonkey: new mobile components including Maps, a WebBrowser component for desktop apps, and more iOS platform (real native) controls.

A new iOS 64-bit compiler is promised, as well as moving the Win32 compiler to an LLVM-based toolchain, as is already the case for 64-bit Windows.

There is an Internet of Things slide which promises “mobile proximity integration” and components for connecting to different devices. Exactly what is new compared to the IoT support described here for XE7 is not clear to me.

Under consideration, Embarcadero says, is Linux server-side support for its middle-tier technologies like DataSnap, support for Intel Android, and a 64-bit toolchain for Mac OS X.

Since it is on SlideShare, I can embed the whole thing here:

This is some help I guess; though I recall much past angst expressed on the Embarcadero forums about these roadmaps, or the lack/lateness of them. The problem, I guess, is that roadmaps are of little benefit to the tools vendors, since they have potential to fuel discontent, set expectations that may later prove unrealistic, and give away plans to competitors.

This may explain why this one has so little content. Embarcadero could work a bit harder on the presentation as well; this really does not have the look of being the exciting next generation of a powerful cross-platform toolkit.

android, apple, delphi, embarcadero, professional, software development

Embarcadero RAD Studio XE7 (Delphi, C++Builder): is seven the magic number?

16 Comments

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.

image

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.

image

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.

image

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.

image

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.

android, apple, embarcadero, professional, software development

Embarcadero AppMethod: another route to cross-platform mobile, now with C++ support

2 Comments

Embarcadero has updated AppMethod, its IDE for cross-platform mobile and desktop applications. The IDE now supports C++, and as a special offer, you can develop Android phone “free forever”, according to the web site.

AppMethod is none other than our old friend Delphi, combined with the FireMonkey cross-platform framework. The difference between AppMethod and the older RAD Studio product line (current version is XE6) is twofold:

1. AppMethod does not include the VCL, the Delphi framework for Windows applications. It does let you develop for Windows or Mac OS X using FireMonkey.

2. You can buy RAD Studio outright with a perpetual license, from £1342.00 plus VAT for a new user (RAD Studio Professional). AppMethod is only available on subscription.

AppMethod pricing is per developer per platform per year. Currently this is £179.83 plus VAT for individuals (very small businesses up to a maximum of 5 employees in the entire organisation) or £600 for larger businesses (a rather large premium).

C++ support is new in AppMethod 1.14 and supports all target platforms except the iOS Simulator (an annoying limitation). It supports ARC (Automatic Reference Counting) on Android as well as iOS. Mac OS X is supported from 10.8 (Mountain Lion) and up.

There are also a few changes in FireMonkey. You can load HTML into the TWebBrowser component using LoadFromStrings. There is a new date picker component.

Another new feature is in the RTL (run time library). Called App Tethering, it lets applications communicate with each other, for example using TCP. These can be apps on the same device or remote apps. Once paired, apps can run remote actions and share standard data types and streams.

There are also updates to push notifications for iOS and Android, Google Glass support, updated OpenGL and DirectX support on Windows, and more: see here for the complete documentation of what is new.

A Quick Hands-on

I installed the latest AppMethod on Windows 8. The install warns that AppMethod cannot co-exist with RAD Studio XE6, presumably because it is essentially the same thing re-wrapped. The product name is relatively new, but there is plenty of old stuff under the covers. AppMethod still has a dependency on JSharp, Microsoft’s Java implementation for .NET. Java code in the IDE dating back to who knows when?

image

There is a 10-field dialog conforming paths for Android tools, which is a reminder of how many moving parts there are here. It is more complex that most Android development environments because it uses the NDK (Native Development Kit) as well as the usual SDK.

image

Once up and running, you can start a new project such as a FireMonkey mobile application:

image

and then you are in an IDE which would not be entirely unfamiliar to a Delphi user in 1995 (or I suppose, a C++ Builder user in 1997) – I am not saying this is a bad thing, though the IDE feels dated in comparison to Microsoft’s Visual Studio.

image

After coming from a spell of development with XAML it feels odd to have a form builder that defaults to xy layout, but layout managers are available:

image

Compile and run, and after the usual slow initialization of the Android emulator, the app appeared.

image

Why AppMethod?

In the crowded world of cross-platform mobile development, why use AppMethod?

Embarcadero makes a big play of its native development, though it is “native” in respect of code execution but not in GUI fidelity since by default visual controls are custom-drawn by the framework. This is in contrast to Xamarin (the obvious alternative for developers from a Windows background) which does no custom drawing but only uses native controls; however for raw performance AppMethod may have the edge (I have not done comparisons).

Delphi developers should also look at RemObjects Oxygene which also uses a Delphi-like language but is hosted in Visual Studio and, like Xamarin, uses native UI components.

The AppMethod approach does make sense if you prioritise maximum code-sharing over getting exactly the right look and feel for each supported platform, and need better performance or more capability than HTML and JavaScript can get you. There is no support for Windows Phone though; if that is in your plans, Xamarin or HTML and JavaScript development is a better fit.

android, apple, delphi, embarcadero, mobile, professional, software development

Embarcadero pre-announces AppMethod cross-platform development tool: Delphi repackaged?

3 Comments

Embarcadero is spilling the beans on a new development tool called AppMethod, which has its own site here and a little more information on TechCrunch. A fuller reveal is promised at SXSW, which kicks off on March 7 in Austin, Texas.

image

But what is AppMethod? The IDE looks very like Delphi, the languages are Object Pascal (like Dephi) or C++ (like C++ Builder), and target platforms include Windows, Mac, iOS and Android. It would be extraordinary if the GUI framework were not some variant of FireMonkey, the cross-platform and mobile framework in Delphi.

Just Delphi (and C++ Builder, which is Delphi for C++) repackaged then? In a comment Embarcadero developer evangelist David Intersimone says that is “way off base” though the only firm fact he offers is that AppMethod is less capable than Delphi for Windows, which presumably means that Delphi’s VCL (Visual Component Library) framework for Windows applications is not included.

Lack of a feature is not a compelling reason to buy AppMethod rather than Delphi so Object Pascal enthusiasts must hope there is more good stuff to be revealed.

I looked out for the Embarcadero stand at Mobile World Congress (MWC), which was a small affair tucked away in the corner of one of the vast halls.

image

The stand was hardly bustling and was overshadowed by a larger stand next to it for another app building tool, AppMachine. While I would not read much into the size of a stand at MWC, that accords with my general sense that while the recently added cross-platform and mobile capabilities in Delphi have won some take-up, it is a small player overall. Embarcadero may feel that a new name and a bit of distance between FireMonkey/Delphi and the original Windows-only tool will help to attract new developers.

delphi, development, embarcadero, mobile

Embarcadero RAD Studio XE5 (Delphi) for Android now available

3 Comments

Today Embarcadero released RAD Studio XE5 which lets you build apps for Windows, Mac, iOS and Android. You can also buy Delphi XE5 separately if you prefer.

Embarcadero’s release cycle is relatively rapid. It was only six months ago that RAD Studio XE4 with iOS support appeared.

The big deal in this release is Android support. If you use the FireMonkey framework, you can build apps for all supported platforms.

There is also a new REST client library and some other enhancements – see here for a list of what’s new.

Embarcadero’s approach to Android development is distinctive. In keeping with Delphi’s tradition of native code compilation, Android apps are compiled using the NDK (Native Development Kit). Embarcadero’s developer evangelist John Thomas told me that this delivers excellent performance. I can believe it, though note what Google says:

Before downloading the NDK, you should understand that the NDK will not benefit most apps. As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++.

Delphi developers are largely shielded from the complexity of the NDK, since you code using the high level abstraction provided by the runtime library (RTL) and the FireMonkey framework. If that is all you need I should think everything will be fine. If you have a Java library you need to call from your Delphi Android application, you need to use JNI (Java Native Interface) which is not so much fun.

Another point to note is that FireMonkey emulates most visual controls like buttons and lists, by drawing them itself. Users might not notice, if they look and behave exactly like the native controls, but this is hard to do perfectly. Embarcadero’s approach is native in respect of the code it generates, but not in respect of the controls it uses.

I installed RAD Studio XE5 on a Windows 8 machine and set about building an Android app. I already had the Android SDK installed so I asked the RAD Studio installer to skip the SDK but to install the NDK. As it turned out, I am not sure whether it did or did not (I could not find it quickly), but it was easier to download the NDK manually.

I have previously tried Delphi for iOS, for which the usual approach is to run Delphi (or RAD Studio) in a Windows emulator on a Mac, since the Delphi IDE is Windows only. This approach is not so good for Android development because its hard to attach Android devices to an emulator for debugging. Therefore, a real Windows PC is a better platform for Android development. If you want to target iOS as well, you can still do so, by using the remote agent running on a Mac.

Setting up for Android development is a little harder than setting up iOS development. The Android device I used for my test is a Sony Xperia T, and I installed the Sony PC Companion to be sure of having the correct USB drivers for debugging. With Java, the SDK, the NDK, RAD Studio itself, and getting the device connected, that is a fair number of moving parts.

It worked though. I created an Android app, connected my Xperia, and it showed up as a target in Delphi (it is also called the LT30p).

image

I threw a label, a listbox and a button onto my app’s main screen.

image

As it turned out, I should have taken a little more trouble. Here is my app running on the phone:

image

Something has gone wrong with the list, but it looks easy to fix.

According to Embarcadero, a recent survey of over 1300 Windows developers showed that 85% get requests for mobile apps. But what mobile platform is most requested? Android is apparently at the top of the list:

  • 83% Android
  • 67% iOS
  • 33% Windows Phone
  • 17% Windows RT
  • 14% Blackberry

Is that really Windows RT (ARM) or could it include WinRT (Windows 8 Store app) I wonder? Neither are supported by Delphi yet; but at least with Android it now supports the most highly requested platform.

Cross-platform mobile development is critical today, and the new capabilities in Delphi and RAD Studio will be welcome. Is it the best approach? The trade-off is this. On the plus side, you get a cross-platform GUI framework that lets you share the maximum amount of code across all the targets you support. On the minus side, that might not be a good idea; see this post for some thoughts on that. You also get a native executable that should perform well, certainly better than an HTML/JavaScript approach, though I’m not convinced that using the NDK on Android is ideal.

How big is your Delphi Android app? Using the Hello World example above, this is what I got in debug configuration:

image

24.52MB storage. I changed to release configuration and got this:

image

That saved nearly 3MB, to 21.62MB.

Here is the RAM usage:

image

I would be interested in hearing from developers using Delphi or C++ Builder for Android development. How is the quality of this first release? Is the fact that you are not developing in Java a problem in practice?

development, embarcadero, professional, software development

RAD Studio XE4 with Delphi for iOS is here. Who will use it?

14 Comments

Embarcadero has released RAD Studio XE4, its suite of development tools for Window, Web and for the first time, Apple iOS. iOS support first appeared in an earlier release, but in preview, and the current effort works using a new LLVM-based ARM compiler so is somewhat unlike the preview. Individual products such as Delphi XE4 are also available separately.

Looking at what’s new in Delphi and C++ Builder in XE4 it is apparent that iOS support is by far the main change since RAD Studio XE3, though there are two other significant changes:

  • Prism, a version of RemObjects Oxygene that compiles a Delphi-like language to .NET (and soon other targets) has been removed. Oxygene lives on at RemObjects.
  • FireDAC, a data access engine acquired from DA-SOFT, is now part of RAD Studio.

I ran up the new RAD Studio on a Parallels VM on a Mac, a VM on a Mac being the best way to try cross-platform development for OS X and iOS. The new IDE immediately presents you with instructions on setting up for iOS development (though I am not a fan of videos, preferring clear text instructions) but I no problems configuring the Mac agent (called PAServer) which makes this work. Start a new mobile app and you can pick a starter template or begin with a blank canvas.

image

I picked the Tabbed Application and was soon trying out my new app on the iOS simulator

image

So far so good, though the ability to run up a quick app is no proof of the quality of the development tool. Still, a few reflections.

As I noted earlier, it seems to me that Delphi developers are either Windows developers using the tried and trusted VCL (in which case there is very little for them in XE4), or developers who are targeting mobile platforms and using the cross-platform FireMonkey framework in order to share code between Windows, Mac and mobile. I guess it is also possible that developers targeting iOS alone will be so taken with Delphi or C++ Builder that they will come in as new users.

VCL developers now have 64-bit compilation and a mature framework, and given that the efforts of Embarcadero are now focused elsewhere, and that even Microsoft is going slow on new features for what it now calls “desktop Windows”, there is little reason for such developers to upgrade.

The key questions then are about the quality of the FireMonkey framework and the iOS support. It is hard for me to be objective, since I know Delphi from of old and it is a familiar environment. Delphi or C++ Builder for iOS has obvious attractions for such developers. I would be intrigued though to know what an Objective C or even a JavaScript developer would make of Delphi, coming to it fresh. I am sceptical whether an Xcode developer would find enough productivity benefit in Delphi and FireMonkey to want to move over, and suspect also that many would not be impressed by the FireMonkey approach to iOS controls, which are generally custom drawn rather than true native, or faked completely like the Segmented Control which you are meant to put together from SpeedButtons with segmented styling, as explained in the Delphi iOS tutorial:

image

Embarcadero is making a big play of being “true native” but native is not just about the executable code (I have written more about this elsewhere) and cross-platform always involves compromise.

There is also some disquiet in the developer community about the cost of keeping up to date with RAD Studio. The full RAD Studio XE4 Architect edition currently costs £2,892.60 ex VAT for a new user, or £1,927.80 to upgrade. If you just want basic Delphi, Delphi XE4 Pro is a more reasonable £642.60 for a new user, or £352.80 to upgrade – but you do not get iOS support for that, that is another £320.40 for the Mobile Add-on, and FireDAC if you need it a further £285.00. When XE3 came out, Embarcadero promised that iOS and Android support would be available later at a “low cost”; of course that is a relative and subjective term, but I can understand if some feel that the price is on the high side. Or you can buy software assurance and get upgrades free; I don’t have prices for that but the cost is significant.

It is unfortunate for Embarcadero that there is intense competition in the iOS tools space, not only from Apple’s excellent and free tools, but also from the likes of Xamarin and Titanium.

None of the above is intended to detract from the achievement of bringing Delphi to iOS, with Android promised, which is considerable.

.net, development, embarcadero, professional, software development

No more Delphi for .NET: Prism removed from RAD Studio XE4

Embarcadero is removing Prism from the next version of RAD Studio, XE4, expected later this month.

Prism is actually a third-party product, based on RemObjects Oxygene. Prism and Oxygene let you code in Delphi and compile to .NET or Mono.

Marc Hoffman from RemObjects explains the change here:

Starting with the upcoming release of XE4, Embarcadero Prism will no longer be part of the RAD Studio SKU, and there will be no “XE4″ branded edition of Prism.

But worry not. As you all know, Prism has been nothing more than a re-branded version of our Oxygene for .NET product — and Oxygene will keep going on, stronger than ever.

In fact, Oxygene has long outgrown its Prism-branded edition, first when we introduced full native support for Java and Android to the language over 18 months ago, and of course with our upcoming support for truly native iOS and Mac apps, shipping next month.

The disappearance of Prism is the final chapter in the story of Delphi for .NET. Borland’s Delphi was first released in 1995, and combined a visual interface builder superficially similar to Visual Basic with a native code compiler, enabling full access to the Windows API  as well as better performance than Microsoft’s VB.

Delphi built up a strong following, but in 2002 when Microsoft brought out the .NET Framework Borland worried that Delphi would be left behind. In 2002 it brought out CSharpBuilder, an IDE for C# targeting the .NET Framework, and in 2003 Delphi 8 which also targeted .NET.

Other .NET versions followed, but whereas native code Delphi was a compelling alternative to runtime-based platforms like VB and .NET, the .NET versions of Delphi were less distinctive. Developers coding for .NET preferred Microsoft’s Visual Studio, while Delphi developers preferred to stick with native code.

When Embarcadero acquired the Delphi tools from Borland in 2008, it dropped .NET support from Delphi itself and replaced it with Prism.

I doubt that the disappearance of Prism will cause much consternation. Prism developers will simply switch to Oxygene instead.

.net, embarcadero, mobile, software development

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

20 Comments

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.

c++, development, embarcadero, professional, software development

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

1 Comment

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.