Blimey, that took me by surprise (again)! I figured it was coming fairly soon, but I didn’t realise quite that soon.
Anyway, Delphi XE5 is here (as is RAD Studio XE5 and siblings), as Tim Del Chiaro on his Delphi Insider blog.
The Trial Edition is up and available for download and those with Software Assurance should have access to the full version.
You can get a run down of what’s new in the XE5 doc wiki – specifically the What’s New page, but there’s also a general What’s New page. However the thrust of this release is all about adding Android to the portfolio of supported target platforms, with the suggestion that you can get applications compiling for both iOS and Android from a single source base.
But before getting bogged down in Android it’s worth mentioning these new features:
- the REST client library, a new cross-platform framework for easy access of REST-based web services
- REST debugger
- the full integration of FireDAC
- IDE support for MacinCloud
- Extendible IDE mobile design devices
- the awesome IDE Insight functionality (
Ctrl+. or F6) is no longer a modal dialog but is now a search box - style support for the freshly released iOS 7
- swipe to delete feature on mobile platforms
TListView search filtering support - the removal of the long defunct WebSnap and InternetExpress (with the suggestion to use IntraWeb and WebBroker instead for similar functionality)
Also there have been a bunch of iOS fixes along the way, as you’d expect.
The full Delphi range of platform targets now covers:
- 32-bit Windows
- 64-bit Windows
- 32-bit OS X
- iOS Simulator (Intel)
- iOS (ARM)
- Android (ARM)
This is achieved with this half dozen compilers:
- dcc32 – Embarcadero Delphi for Win32 compiler version 26.0 – your regular Win32 Delphi, the latest version updated over many versions since Delphi 2
- dcc64 – Embarcadero Delphi for Win64 compiler version 26.0 – the 64-bit Windows targeting compiler
- dccosx – Embarcadero Delphi for Mac OS X compiler version 26.0 – the Delphi compiler that generates 32-bit OS X apps
- dccios32 – Embarcadero Delphi Next Generation for iPhone Simulator compiler version 26.0 – the NextGen Delphi compiler that builds Intel executables that run in the iOS simulator
- dcciosarm - Embarcadero Delphi Next Generation for iPhone compiler version 26.0 – the NextGen Delphi compiler that builds ARM executables that run on iOS devices
- dccaarm – Embarcadero Delphi for Android compiler version 26.0 – the NextGen Delphi compiler that builds ARM executables that run on Android emulators and devices
Android requirements
Because the Delphi compiler generates native machine instructions, its output is processor-specific. In other words it doesn’t target the Dalvik Virtual Machine, where regular Android applications reside, which are basically Java p-code applications that are executed by a variant of the Java VM. Instead it generates raw machine code, as all the current wave of Delphi compilers do (the long gone Delphi for .NET was the exception to this general rule). So because it’ a compiler compiling native machine instructions Delphi’s Android support has the following requirements:
- there must be a GPU
- the CPU must be ARMv7 with NEON instruction support
- the OS on the target device must be one of:
- GingerBread: Android 2.3.3+ (MR1 or later), which is API level 10
- Ice Cream Sandwich: Android 4.0.3+ (MR1 or later), which is API level 15
- Jelly Bean: Android 4.1+ (release, MR1, MR2 or later), which are API levels 16, 17 and 18
- you can run the app on an Android emulator if:
- the emulator is set to use the host GPU
- the emulator is running Ice Cream Sandwich (MR1 or later) or Jelly Bean (release or later)
- the emulator is not running in a Virtual Machine
These requirements appear here and there in the documentation, mostly concurring with itself: 1, 2, 3. [Update: the 3rd link is new and also lists various devices that FireMonkey apps have been tested on]
[Edit: It should be noted that the Android emulator is an *emulator* – it emulates ARM instructions when set up as an ARM emulated device. This is in contrast to the iOS simulator, which simulates an iOS device by running an Intel code version of the app, where the real iOS app again will be built with ARM instructions for the iOS device ARM chip. The implication of this is that the performance is atrocious and extremely disappointing for most. As Warren Postma details in XE5 Trial Download and Install Experience, you would really be advised to get a cheap Android tablet to test on, and use the emulator as a last resort.]
[Edit: I should add that if you are going to get a cheap Android device to test your apps then you should most definitely take steps to ensure it meets the minimum specifications required by a Delphi application – it must have an ARMv7 chip that supports NEON instructions and be running an appropriate OS version. Thanks for the reminder on that, Jolyon]
How do you find out if your device is supported? Well, the OS version you can find out in the Settings. The path and menu items may vary but goes roughly like this: Settings, About phone (or tablet), Software information, Android version.
To check the CPU details you’ll need to run one of the tools from the Android SDK against your connected device. Delphi installs the Android SDK and NDK if you don’t tell it you have it pre-installed. The Android SDK gets installed into a directory something like: C:\Users\Public\Documents\RAD Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk. In the platform-tools subdirectory from there is the Android Debug Bridge, adb.exe.
To run a command against your device it needs to be connected, typically by USB. This requires you to install an appropriate USB driver for your device as the ones located by Windows typically don’t do the job. Refer to the helpful The Delphi Geek blog post on the matter, XE5 and USB Drivers, for more information and links to drivers for the more common Android phone manufacturers.
When your phone is connected you’ll need to launch a command prompt and run an adb command. This may be easiest if you change directory to the platform-tools subdirectory (or Shift+right-click on the platform-tools folder in Windows Explorer and choose Open command window here). Firstly run the command:
adb devices
just to prove that your device can be seen by the Android tool chain. Assuming it can, run:
adb -d shell cat /proc/cpuinfo
This will show you CPU information something like this:
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 13.52
processor : 1
BogoMIPS : 13.52
processor : 2
BogoMIPS : 13.52
processor : 3
BogoMIPS : 13.52
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x1
CPU part : 0x06f
CPU revision : 0
Hardware : UNKNOWN
Revision : 0003
Serial : 0000000000000000
Check the Processor line to ensure you are running ARMv7. In the Features line check that neon is included in the CPU feature list
Product Launch
There have been various events worldwide over recent fays and more coming in the days ahead, spreading the word about the new Android support in Delphi XE5. Today I attended the London event, which was held in a theatre in the Natural History Museum.
Embarcadero’s JT was over to help with the launch, and also on stage were Jason Vokes and Steve Ball.
I was a long way back in the audience with the zoom on my telephone’s camera on maximum. But this was the theme for the day.
Addenda
If you are keen to try out Delphi’s Android support, go right ahead and start downloading and installing. However I would urge you to read up on how Android development works whilst the download/install process takes place. There are many docwiki pages that help you get a handle on how it all fits together with the main entry point here: Android Mobile Application Development. A whole bunch of subtopics are listed here.
Recent posts about Delphi’s Android support, which pre-dated today’s launch, include the following:
In a previous blog post I discussed the Objective-C Bridge, available when building iOS apps. This is part of the RTL that allows Delphi code to interact with Objective-C API code. Objective-C code is compiled native code and Delphi code is compiled native code, so the bridge allows the two sets of code to get along. You can define Delphi versions of iOS classes (rather akin to how you can declare Delphi versions of Win32 API functions in classic Delphi), create instances of Objective-C classes, inherit from Objective-C classes and generally do what is necessary to access parts of the CocoaTouch API that are not consumed and surfaced by FireMonkey or parts of the API that do not have similar behaviour exposed by FireMonkey.
Oh, I should mention it’s not so much called FireMonkey now. It seems to be getting referred to more and more as the FM Application Platform. I suspect the latter sounds a little more “business”-y.
Anyway, the Android support offers a similar API bridge called the Java Bridge. Now the Android SDK classes are Java classes living in the world of the Dalvik VM. Delphi code is machine code running on the CPU. This is different to the iOS case. So the Java Bridge uses JNI to communicate across the native/managed boundary but basically offers broadly similar behaviour. You can declare Delphi versions of Android classes, create instances of them and communicate with them. So aspects of the Android API that do not get employed by regular Delphi apps can be accessed for the most part.
One shortcoming of the Java Bridge is that you cannot inherit from a Java class, which makes certain things rather tricky. However I’m going to write up my understanding of the Java Bridge and Objective-C Bridge in additional fuller articles with various examples over coming months, and try and offer ways around the Java Bridge shortcomings. Watch this space. Well, ok, you’d do better to read up on all the Android backgrounders in docwiki while downloading and installing XE5 :o)
Here are some more Embo pages for you to chew over and apply due consideration to:
