Tuesday, 31 December 2013

Catching up on happenings in the Delphi world

When I’m head-down in a ‘long hours’ contract I tend to miss quite a bit of Delphi-oriented news. Once in a while I look up and I find a whole host of interesting posts around the blog-world and this has been the case over this seasonal break.

I’ve been browsing around seeing what’s new and have collated the following list of stuff I found interesting. Anyone else who hasn’t been keeping up-to-date on news of late might possibly also find some stuff of interest in the list.

Happy New Year!

Monday, 25 November 2013

Delphi and Android services (part 2)

It’s been a while now since I posted up the link to my Delphi service example on Google Play.

I mentioned at the time that it was not a trivial exercise and was somewhat imperfect in implementation (although I’d done my best to disguise this fact). Indeed you only really see an issue if you are looking at the logcat output from the app (either using the command-line adb logcat command, or using the deprecated DDMS tool or the replacement Monitor tool). Alas the app dies while endeavouring to tidy up for exit…

I also mentioned at the time that I was hoping to work out some scheme to remedy the situation before releasing the example source, something to do with pride or perfectionism or some such… Anyway, with the day job, the evening job, the prep work for last week’s Be-Delphi 3.0 event in Belgium my plans haven’t been accomplished and I have still to work out if it’s feasible to clean up the shutdown part of the sample. All my current efforts have come to little in resolving it.

So, given that there have been a number of requests for the source I have now made it available at this download link. This is the same as the sample online other than it has no splash screen. This example is free of a splash screen to simplify the example and leave it clearer. There are a couple of examples that incorporate a splash screen and have similar custom build steps available in my CodeRage 8 session files.

Please note that the archive has a Readme file in it, and you should take the time to read through this file carefully as it explains the non-standard build steps required to get the sample successfully built for deployment. If you don’t follow the Readme file, then you’re unlikely to get any joy with the sample at all.

For your convenience I include the text of the ReadMe file below.

As you will see, since Delphi has no catering for building Delphi services or broadcast receivers, I’ve had to go “round the houses” to do it, using Java stubs, and pertinent thread-switching between the Java and Delphi threads.

As you will also perhaps appreciate, I don’t recommend this as a productive way of building an Android service. However if you need to add a service to a Delphi Android application, then this approach allows you to do so.

But… as of the time of posting there is a still the small matter of a (slightly brushed under the carpet) death-by-tombstoning bug on shutdown. If any keen reader can work out a clean way of closing I’d be most obliged to hear of it!

[Update]

When the small Java source files get compiled, the Android dx tool expects them to be compiled by the JDK 1.6.x compiler as opposed to the JDK 1.7.x compiler. If you have JDK 1.7.x installed, you hit a problem with dx reporting:

bad class file magic (cafebabe) or version (0033.0000)

However, to avoid forcing a reinstall of JDK 1.6 you might like to modify my build.bat batch files and add in extra command line switches to the javac.exe command-lines. You need to insert this after the javac.exe command to force Java 1.6 byte code output, which is digestible by the Android dx command:

-source 1.6 -target 1.6


Service example
===============
This project implements an Android service along with a couple
of broadcast receivers to catch and respond to intent messages
flung around the system. The service and receiver classes are
implemented as extremely shallow Java classes, which need to be
compiled and converted to an appropriate executable format
(dex), and then merged into the other dex code deployed with an
Android app.
The Java code calls into native Delphi code to implement
the "business end" of the service and receivers.
Build the Java support files:
----------------------------
In the project's java directory are some source files:
 - java\src\com\blong\test\ActivityReceiver.java
- java\src\com\blong\test\SampleService.java
- java\src\com\blong\test\ServiceReceiver.java
These need to be compiled to .class files, archived into a .jar
file, converted from Java byte code to DEX (Dalvik Executable)
format and merged into the normally used (by Delphi's Android
deployment process) classes.dex.
To set this up, follow these steps:
 - Ensure the useful subdirectory of Android SDK's build-tools
directory is on the system PATH (e.g. C:\Android\android-sdk-
windows\build-tools\18.0.1 or C:\Users\Public\Documents\RAD
Studio\12.0\PlatformSDKs\adt-bundle-windows-x86-20130522
\sdk\android-4.2.2)
 - Ensure the Java Development Kit's bin directory is on the
system PATH (e.g. C:\Program Files (x86)\Java\jdk1.6.0_23\bin)
 - Run a command prompt in the project's java subdirectory and
ensure you can successfully launch each of these:
    - javac
- jar
- dx
 - Review the build.bat file and ensure the environment
variables are set correctly:
    - ANDROID needs to point to your Android SDK base
directory, e.g. C:\Users\Public\Documents\RAD Studio\12.0
\PlatformSDKs\adt-bundle-windows-x86-20130522\sdk or
C:\Android\android-sdk-windows
    - ANDROID_PLATFORM needs to point at an installed SDK
platform installation, e.g. %ANDROID%\platforms\android-15 or %
ANDROID%\platforms\android-17. Check for one that is installed.
    - DX_LIB needs to point to the lib subdirectory under the
Android SDK build-tools directory, e.g. %ANDROID%\build-
tools\18.0.1\lib or %ANDROID%\build-tools\android-4.2.2\lib
    - EMBO_DEX needs to point to the Delphi-supplied Android
classes.dex file, wrapped in quotes to take care of any spaces
in the path, e.g. "C:\Program Files (x86)\Embarcadero\RAD
Studio\12.0\lib\android\debug\classes.dex"
 - Run build.bat
 - You should now have a new file in the project directory tree
called java\output\dex\classes.dex
This file replaces the supplied classes.dex and has the Java
service and broadcast receiver compiled classes included in it.
Set the new classes.dex for deployment:
--------------------------------------
Open the project in the IDE
Choose Project | Deployment
Note that the classes.dex file from the project's
java\output\dex directory is set to be deployed.
You must ensure that the default classes.dex file is de-
selected. As you switch configurations, this de-selection will
be lost (the file will be re-set to be deployed) and will need
to again be de-selected. This is an IDE bug with Delphi XE5 RTM
and XE5 UP1 and is logged in Quality Central as bug 118472.
Register the service:
--------------------
This has already been done for this demo. It involves the
following:
 - Open the Android manifest template,
AndroidManifest.template.xml, which is generated on first
compile, from the project directory
 - Add in a description of the service in the application
element:

<service android:name="com.blong.test.SampleService" />
Build the Delphi Android application library:
--------------------------------------------
In the IDE choose Project | Compile ServiceApp (or press
Ctrl+F9)
Deploy the library to an Android application package (.apk):
-----------------------------------------------------------
In the IDE choose Project | Deploy libServiceApp.so
Install the app on the device:
-----------------------------
In the IDE choose Run | Run Without Debugging (or press
Ctrl+Shift+F9).
This will implicitly do the compile and deploy steps above, so
they are actually optional.
This step will uninstall the app if already installed and then
install the newly built version.

Tuesday, 12 November 2013

CodeRage 8 video replays are up

For anyone that’s been waiting for the replay videos from CodeRage to go up and has been getting impatient as the suggested 2 week window has come and gone, relief is now available as the replay videos are all there.

You can find them on YouTube on the Embarcadero TechNet page, or on the original CodeRage 8 session page.

Well, ok, maybe as I type one or two are still slowly dribbling onto the Internet and maybe the sessions page hasn’t quite got all the video links on board, but the majority are accessible in one way or another on YouTube at last.

I’ve updated my CodeRage 8 session files post to include the video links to my talks in case anyone wants to check them out. Enjoy!

Wednesday, 6 November 2013

Delphi and Android services

Since Delphi’s introduction of Android support with the release of XE5, there have been many questions posted hither and thither regarding whether and how you can build service applications with it. The pervading suggestion or suspicion is that maybe Delphi isn’t cut out to build such exotic Android creations.

Well, if your goal is to just build some sort of a service app I wouldn’t particularly recommend Delphi for the job right now, simply because it hasn’t got the wherewithal to support you in that endeavour in its current guise, and consequently it’s quite difficult. Really, if you just want to build a service app you’d probably have an easier time using Java or Oxygene for Java in conjunction with the Android SDK.

However if you are invested in building a Delphi Android app, are in the midst of building a FireMonkey application for mobile deployment, and need an Android service as part of that, well it’s quite possible. But as I may have mentioned, it’s neither particularly easy nor especially straightforward.

I am aware that I have (at this time of writing) yet to write up the business of adding Android menus to Delphi apps, employing a splash screen and launching Android activities and getting results back (as demo’d in my CodeRage 8 talk, albeit with code samples available in that linked post)*.

Now I can add to the list of things I have yet to write up the steps for creating a service application. If you take a look at this Google Play Store listing you’ll see I’ve built an app that, as well as a splash screen, also implements a service.

Service app running Service app includes a service

So yes, it’s quite feasible to build a service and a broadcast receiver in a Delphi app. That said, I’ve had to be a little creative on exiting the app to avoid a failure being evident on the screen.

As mentioned, these Android aspects that fall outside the standard simple business app paradigm haven’t factored into what is readily supported currently in Delphi’s Android support. Hopefully this will be improved as time goes on to allow all sorts of Android features and facets to be surfaced in Delphi Android code. In the mean time a certain degree of spelunking and skulduggery is needed to achieve certain ends.

I know quite a few people are clamouring for knowledge on how to build service apps. Hopefully in the near future I’ll write it up, but certainly in the nearer future I’ll release the code sample, once I’ve exhausted possibilities to clean up the wrinkle around app shutdown. That should satisfy the keener of you out there. In the mean time, be satisfied that it’s been proved to be possible at all.

Thursday, 17 October 2013

My CodeRage session files

At the time of writing my two sessions for CodeRage 8 are being broadcast around the Arpanet.

I’ve got two session this year, both related to Delphi mobile development, and both concerning how to reach out from the island that is the FM Application Framework (aka FMX aka FireMonkey) and gain access to the underlying mobile OS platform APIs.

The first session is Accessing the iOS API and looks at how Delphi-written iOS apps can talk to the CocoaTouch APIs and access additional iOS frameworks. We look at the Objective-C bridge and see how it is used to import iOS APIs, namely classes and protocols (Apple’s term for what we call interfaces), and how you can implement iOS interfaces and inherit from iOS classes. We also briefly look at how to pull in APIs that are not already imported by Delphi’s RTL. As a proof of concept we briefly see a Delphi iOS app that has no FMX code or units in it whatsoever, operating purely through the iOS APIs using the standard CocoaTouch model.

Files from the Accessing the iOS API session can be downloaded from here.

The second session is Accessing the Android API and looks at how Delphi-written Android apps can talk to the Android SDK classes. We look at the Java bridge and see how it is used to import Android APIs. We’ll also look at how to pull in APIs that are not already imported by Delphi’s RTL. We also look at how to add a splash screen to an Android app to cover up the startup time on anything other than the fastest devices, how to add Android menus to an app and how to launch external activities and get results back from them.

Files from the Accessing the Android API session can be downloaded from here. Take note that since several of the samples involve various required preliminary steps in order to function, as they step outside the comfort zone of Delphi XE5 RTM’s Android support, you should check the ReadMe.txt files supplied in the project directories of those projects.

[Update]

I plan to write up some of the subjects covered by these demos in further posts or articles as time and work schedules permit. However in the mean time I’ll respond to comments by expanding this post as necessary.

It appears that when the small Java source files get compiled, the Android dx tool expects them to be compiled by the JDK 1.6.x compiler as opposed to the JDK 1.7.x compiler. If you have JDK 1.7.x installed, you hit a problem with dx reporting:

bad class file magic (cafebabe) or version (0033.0000)

However, to avoid forcing a reinstall of JDK 1.6 you might like to modify my build.bat batch files and add in extra command line switches to the javac.exe command-lines. You need to insert this after the javac.exe command to force Java 1.6 byte code output, which is digestible by the Android dx command:

-source 1.6 -target 1.6

Thursday, 26 September 2013

Nostalgia. Is it just a thing of the past?

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.

Want to brush up on your Turbo Pascal 7 language? Or review the details of the Turbo Pascal Graphix Toolbox (all the Turbo Pascal manuals are here, while Turbo C manuals are here and Borland C++ manuals are here)? Or recollect the specific of Sidekick Plus (Sidekick manuals are here)? Or be reminded how Turbo Prolog worked (Turbo Prolog manuals are here)?

Turbo Pascal Reference Manual

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)

ObjectVision Reerence Manual

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

Turbo C User's Guide

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

Android resources

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).
  • Google’s sample icons pack can be downloaded with this 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.