Thursday, 26 September 2013

I was put onto this treasure trove of old scanned manuals the other day: http://bitsavers.informatik.uni-stuttgart.de/pdf/borland. It contains a huge directory hierarchy of PDF scans of old product manuals from all sorts of vendors. And that’s scans of the whole manuals, not just the front covers.

All this and more are there as PDFs. And not just old Borland manuals. Oh no, browse up the directory tree and you can find oodles of stuff on say, the Apple Lisa (Apple’s manuals start here and the Lisa manuals are here).

What a great resource for those who like to look back from time to time :o)

Take a browse through and see how many product manuals you’ve forgotten all about.

Ahhh, product manuals. Those were the days!

Oh, and while on the subject of manuals, back in the day the Borland documentation team did like to have a bit of fun in their work. The Delphi 1 manuals contained a couple of Easter Eggs.

Friday, 20 September 2013

For those Pascal programmers looking at building Android applications, be it with Delphi XE5 or with Oxygene for Java (I work with both!), here are a few Android-related resources that may come in useful:

Google’s Android Device Manager – if you mislay your Android device this allows you to locate it on a map (if it’s got a data/WiFi connection) and also ring it (presumably if it’s a telephone – I haven’t checked whether this option does anything on a tablet). Clearly this is similar to Apple’s Find My iPhone functionality.[Update: Jim confirms that tablets will happily ring too]

Using remote Android emulators – because Android emulators emulate the device CPU they can be hideously slow, and basically unusable in a VM. If your dev tool runs in a VM then it can be useful to communicate to an Android emulator (technically called an Android Virtual Device or AVD) either on the host machine or another machine on your network. This is a useful technique entirely independent of your chosen development tool as it revolves around how your local adb.exe communicates with the emulator. This post by Jim McKeeth runs through how to set this up using SSH. You can also find a write-up in the Delphi online documentation.

If you are using Oxygene for your Android development you may want to look at setting up your AVD to use an x86 CPU, potentially taking advantage of Intel Virtualization Technology via Intel HAXM (Hardware Accelerated Execution Manager) to provide VM acceleration. Delphi developers cannot take advantage of this because Delphi targets the ARMv7 CPU.

App testing across many devices. The Android emulator has long been held up as pretty much the only way of testing your app across the range of form factors that different devices can offer. Now it’s not the only option though, as Apkudo for Developers offers developers a free online app-testing platform where your app will be tested on over 260 different Android devices. Just upload your app to the queue and a report will be sent back when the tests have been run.

Since Android’s Ice Cream Sandwich release introduced the Roboto font as the default, you may want a copy to install on your machines. You can download it from the link in the blue box here (or this is the direct d/l link).

For anyone who does presenting it can be very useful to have a means of showing on your computer screen what your device is doing. There are various VNC-based solutions for this out there, but Jim McKeeth has built a simple solution using repeated screen-captures called Android Screen View. You can download the source code for it here or pull down a build here.

The Android dashboards show you the percentage of devices sharing various characteristics as obtained from the Google Play store. All the devices in question will be running Android 2.2 (FroYo) and above. This device breakdown can be useful to decide what OS and form factor to ensure you support.On the dashboards you can see the breakdown of:

Android OS versions

Screen sizes and densities

OpenGL version

If you have a nose that needs to be poked inside everything, consider pulling down the Android source code. Information on how is available here.

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:

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:

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:

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.

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: