You are browsing the archive for Guest Post.

Android resources

September 20, 2013 in Guest Post, Java, Oxygene, Prism

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.

Oxygene 6 now includes Oxygene for Cocoa

May 31, 2013 in Guest Post, Java, Oxygene, Prism

Ah, it’s been released… The May 2013 release of Oxygene, released on 27th May 2013, brings us Oxygene 6.0, and Oxygene 6.0 brings us the official release of Oxygene for Cocoa.

The Oxygene language now gives ways of coding for all the currently interesting platforms using the three available editions of Oxygene:

  • Oxygene for .NET (formerly also known as Delphi Prism) – targets the .NET platform, allowing you to build Windows applications, Windows phone applications, Silverlight applications and so on, using the relevant .NET frameworks. Also targets the Mono platform, allowing applications to go to the many places where Mono goes, such as Mac and Linux and also Android and iPhone/iPad using Xamarin.Android (aka Mono for Android) and Xamarin.iOS (aka MonoTouch) using those frameworks.
  • Oxygene for Java – targets the Java runtime, allowing you to build Java apps, Java servlets, Java applets and also, perhaps most interestingly, Android apps. Java apps will use your chosen Java frameworks and Android apps use the Android SDK framework.
  • Oxygene for Cocoa – targets iOS and OS X allowing native ARM applications to be built for iPhone and iPad as well as 64-bit native OS X applications. Applications are built against the native OS X Cocoa and iOS CocoaTouch frameworks.

Oxygene is hosted in Visual Studio 2012 (support for Visual Studio 2010 has now been phased out in Oxygene 6.0). If you don;t have a copy of Visual Studio 2012 the Oxygene installer can set up the Visual Studio 2012 shell first.

For existing users of Oxygene for .NET and/or Oxygene for Java there are some new features added to Oxygene 6.0, including a spate of new conditional defines to help distinguish which compiler built your code or which platform you are targeting:

Oxygene 6.0 edition Edition define Platform define GC/ARC define
.NET ECHOES DOTNET GC
Java COOPER JAVA GC
Cocoa NOUGAT COCOA ARC

However the main thrust of the release is Oxygene for Cocoa, which works in conjunction (if you want) with Apple’s UI designer to support visual UI design via nib (.xib) files or storyboard files. It also understands and fully supports multi-part method names so that it fits in directly with the Objective-C naming system and can represent and refer to any existing methods. It support the iOS Simulator, supports debugging there and on-device and offers all the options needed to sign and provision your apps. It supports ARC (automatic reference counting), understands bridging and uses an LLVM back-end to generate good ARM and 64-bit Intel code.

It ships with all the standard frameworks imported and has a tool that allows you to import any additional libraries you need to work with. Because Oxygene always uses the frameworks that natively exist on the target platforms, there is not an awful lot to learn specific to Oxygene when building Mac or iOS apps. Anything you learn on the Internet about how to build aspects of Mac/iOS apps applies directly – it’s just a case of expressing the various local API calls in the Oxygene syntax, which is a very familiar Object Pascal based syntax.

During pre-release development Oxygene for Cocoa was called Project “Nougat” and I worked with it a lot to keep tabs on how it progressed. I’ve built a whole bundle of test apps to keep on top of (mostly) iOS application development techniques by simply following various online Objective-C tutorials, and just entering the code in Pascal instead of in Objective-C.

I’m delighted Oxygene for Cocoa is now released as I’ve been productive with the tool for quite a long time now. I’ve wanted to make blog posts about how I do thing with it, but given it’s just a syntax shift there hasn’t really been much of a need for it. I guess maybe I’ll do one at some point to show the basics of building up an iOS app in the Visual Studio IDE and getting it launching in iOS Simulator, but after that it’s just writing code in the same way any other iOS developer does; just in Pascal.

On June 17th I’ll be demonstrating the product with a talk at a Developers Group meeting in Maidenhead, UK.

You can find more information about Oxygene for Cocoa at these links:

Buying Oxygene is reasonably pocket-friendly. If you’re new to it then $699 gets you all three versions. Otherwise there is a $499 renewal price for existing Oxygene for Java or Prism customers, a $599 cross-grade price for any users of Embarcadero Delphi or of older Embarcadero Prism versions (XE2 and below) and also a $99 academic price.

If you want to see how you get on with Oxygene 6.0 without committing you can always pull down a trial version first.

Free issue of Blaise Pascal magazine to registered users

November 5, 2012 in Guest Post, Java, Oxygene, Prism

I must have missed this one being announced, but registered users of XE, XE2 and XE3 products can pull down a free copy of Blaise Pascal, the magazine for all things Pascal-based.

Details are on this edn post by Tim DelChiaro and you can pull down the PDF magazine from Code Central.

The free issue, Issue 24, runs to 120 pages and has a number of articles from notable authors (such as Cary Jensen, Bob Swart and Bruno Fierens) on a variety of subjects including FireMonkey 2, Smart Mobile Studio, HTML 5, Delphi XE3 Styles, Delphi XE3 helper types, and interviews with various industry luminaries, including Marco Cantu, Mike Rozlog, marc hoffman and David I.

Also in the issue is my second article on Oxygene for Java: Supporting new android features in old android versions with Oxygene.

Download the magazine – I hope you like the contents!

Native iOS development for Delphi programmers: Project ‘Nougat’

September 25, 2012 in Guest Post, Java, Oxygene, Prism

If you’ve kept up to date with developments in the world of Delphi, you’ll be aware that Embarcadero have teased us with a multi-step way of targeting iOS devices using the cross-platform FireMonkey framework and then just recently taken it away again (for now…).

It seems almost prescient, then, that RemObjects have just announced Project ‘Nougat’, which is the next incarnation of their Delphi-like Object Pascal based Oxygene compiler.

Oxygene will soon be natively targeting three platforms:

  • .NET: Oxygene for .NET (aka Delphi Prism aka Embarcadero Prism) is the longstanding .NET compiler that took over from Delphi for .NET in Borland/CodeGear/Embarcadero’s RAD Studio suite. It was released in 2005 and supports all the platform features such as LINQ and the Parallel Framework and targets regular .NET, Silverlight, Windows Store (aka Metro), Mono, in other words anything .NET can be targeted from Oxygene for .NET.
  • Java & Android: Oxygene for Java (previously Project ‘Cooper’) was released in 2011 and supports the targeting the Java Virtual Machine and also fully supports the Android toolchain. This means you can target regular Java apps, Java servlets, Java applets, and also build apps for Android phones and tablets. I’ve posted quite a bit already on Android development using Oxygene for Java.
  • OS X and iOS: this is what Project ‘Nougat’ is all about. It is in development, and the beta is expected to start in early October 2012, with release in the first half of 2013. ‘Nougat’ will target:
    • 64-bit OS X apps
    • 32-bit ARM v7 iOS apps
    • 32-bit Intel iOS Simulator apps

    There will be no wrappers involved in the generated apps, so nothing like Mono will be necessary. You will get native apps out of Project ‘Nougat’, coded in Pascal but as native as if you’d used Objective-C.

This is a great move forwards to fill in the gaps in what Oxygene can target and now gives a full spread over the major desktop and mobile platforms in one permutation or another.

If interested in native iOS and OS X targeting using all the regular native APIs as nature intended then be sure to read the series (in progress) of posts by RemObjectsmarc hoffman:

Additionally (and perhaps importantly), if you buy an Oxygene subscription for $499 (that’s the price for a new subscription – it’s $349 for a renewal) you get all three platforms: Oxygene for .NET and Oxygene for Java (and Android) and Project ‘Nougat’ (you’ll get access to the beta and also the shipping product when it comes out in the first half of 2013).

Visual Studio 2012 and those… CAPS

September 18, 2012 in Guest Post, Java, Oxygene, Prism

Anyone who’s glimpsed Visual Studio 2012 has seen it shouting at them and wondered why, given the luxury of having both lower and upper case available, Microsoft has chosen to go for all upper case in the menu bar. Well, if you really want to know, read the post on The Visual Studio Blog as that explains their reasoning.

I read it. To be honest it didn’t seem very convincing. There is mention of All Caps being a strong signature element of styling for navigation in Microsoft UIs. They do point at some upper case in a web site and on the Zune, but given the main UI thrust at the moment is Metro^H^H^H^H^H the Modern UI in Windows 8 and on Windows Phone and those don’t appear to focus on upper case I remain dubious.

I am aware that Office 2013 will also be using the upper case motif (you can see it here). This to me and to many who share a certain sensitivity of eyesight is somewhat regrettable.

Fortunately, with Visual Studio at least, you can instruct it to forget all about the upper case fad and just ‘be normal.’ This involves a little registry hackery. Run regedit.exe and in the HKEY_LOCAL_MACHINE hive navigate to the Software\Microsoft\VisualStudio\11.0\General subkey. Add in the DWORD SuppressUppercaseConversion and give it a value of 1. As you might expect, a value of 0 reverts to the short-sighted choice of upper case again.

This trick is getting reasonably well known around the Arpanet, but I’m posting it to help ensure the message is spread as far and as wide as feasible. I’ll cross my fingers that Office 2013 also offers up a trick available to turn off its SHOUTY MENUS.

Getting an Android app’s version number

September 18, 2012 in Guest Post, Java, Oxygene, Prism

A while back I was preparing an app to upload to the Android Market Google Play. One of the requirements of uploading is that the app must contain version information. As of the August update of Oxygene for Java 5.2, the default Android application template does not contain version information so you need to insert this manually, and then update it as and when your code is updated.

You add version information to your Android application by editing the manifest file. In the outermost element, the manifest element, you add in a couple of attributes: versionCode and versionName.

versionCode is an integer that can be anything you like, as long as each new version code is higher than the last – clearly an incrementing number is the simplest option here. versionName is the string that is shown to the user – it’s not used by the system so can be any test you like.

So, for example, you could open the manifest element like this on your first app version:

<manifest
    xmlns:android=”
http://schemas.android.com/apk/res/android”
    package=”com.acme.app”
    android:versionCode=”1″ android:versionName=”1.00″>

Each time you want to issue a new application you simply update the two version-related attributes, maybe like this:

<manifest
    xmlns:android=”
http://schemas.android.com/apk/res/android”
    package=”com.acme.app”
    android:versionCode=”2″ android:versionName=”1.01″>

With that done, what’s involved in displaying some version information to the user, say in an About screen in the app? Well that’s what I wanted to do with the app mentioned above – it was my Plasma app (a free graphics plasma effect demo written in Oxygene for Java).

To get version info we must access a PackageInfo class for the app as that can give us information about the Android package gleaned from the application manifest file – specifically the class exposes versionCode and versionName members that return the values from the manifest discussed above.

How do we get a PackageInfo class? That can be arranged by a PackagManager object that offers a getPackageInfo() method (that we can access as a PackageInfo property). Pass it the package name and it will return the goods for us.

The Context class is what Activity inherits from, and it defines two useful methods: getPackageManager() and getPackageName() – hopefully it will be patently clear these will finish the job off.

In the case of my plasma app I have layout resource containing a TextView called aboutText. I also have two string resources that define formatted strings waiting to have a version string (the version name from the manifest file) plugged in. For example, one of them is used to set up the About activity’s title and is defined thus:

<string name=”plasma_about_title”>About Plasma %s</string>

The code to access the TextView control and give it a formatted string containing the version information looks like this:

var aboutTextView: TextView :=
 
TextView(findViewById(R.id.aboutText));
var versionName :=
  PackageManager.PackageInfo[PackageName, 0].versionName;
aboutTextView.Text :=
  String[R.string.plasma_about_text, versionName];
Title := String[R.string.plasma_about_title, versionName];

If you want to use the original method names as defined in the Google Android documentation, as opposed to the equivalent implied properties, it would look like this instead:

var aboutTextView: TextView :=
  TextView(findViewById(R.id.aboutText));
var versionName :=
  getPackageManager().getPackageInfo(
    getPackageName(), 0).versionName;
aboutTextView.setText(getString(
  R.string.plasma_about_text, versionName));
setTitle(getString(R.string.plasma_about_title, versionName));

Notice we are making use of the overload of getString() that takes a string resource id and a list of format string arguments to use when building the formatted string.

Porting some Android SDK samples

July 13, 2012 in Guest Post, Java, Oxygene, Prism

As I mentioned last time, I’ve been porting some of the Java Android SDK demos over to Oxygene for Java. This is for various purposes:

  • to ensure I am on top of various Java code layout approaches. The one that requires the most faffing about is nested classes. In Java the nested class gets access to members of the outer class, thanks to having an implicit this parameter passed through the constructor. That requires a bit of manual rewiring, which is a bit of a bore, but no big deal.
  • to get some exposure to various additional Android programming areas.
  • to run more and more code through Oxygene for Java and report any latent bugs that show up when trying it out.
  • to build up more useful Oxygene for Java examples that can be packaged in with the product and thus be of reference use to Oxygene users
  • to find out what issues and bugs are lying in wait for unsuspecting newcomers to Android programming within the recesses of those SDK demos.

I’ve uploaded a bunch of them to Google Play now (see the end of this post) so anyone interested can check them out and report any problems left in there so I can try and remedy them. Of course they are demo apps and so you shouldn’t expect too much of them. They’re just there to demonstrate certain Android programming techniques and so aren’t professional-level applications.

In the last post I looked at the poor support for the exit-the-app-and-come-back situation with Lunar Lander and JetBoy. Well, poor support isn’t really accurate as the apps just crash out when you try and resume them. Poor implementation, poor planning, something like that perhaps.

Anyway, other common themes that come out of more demos are as follows:

1) Background image resources are not resized to accommodate screen sizes. Perhaps back when these demos were written, the various bitmaps used in AccelerometerPlay, JetBoy were larger than the largest of screens. Not now with tablets and large display phones.

In the case of an image on a game that will get an initial size on startup and not change, for example a game that is fixed to landscape or portrait orientation, then you can size the bitmap once after having loaded it. JetBoy is fixed to landscape orientation thanks to this attribute in its activity declaration in the Android manifest file:

android:screenOrientation=”landscape”

Similarly the AccelerometerPlay demo is forced to portrait with this attribute in the activity declaration in the Android manifest:

android:screenOrientation=”portrait”

If you draw in a View descendant, then override the onSizeChanged() method and you can resize the bitmap by passing it to the static Bitmap method Bitmap.createScaledBitmap() along with the target width and height, typically as passed in parameters to onSizeChanged(). For example, in the accelerometer demo I now have this:

method SimulationView.onSizeChanged(w, h, oldw, oldh: Integer);
begin
  // other stuff is here
  …
  // Resize the background bitmap
  // NOTE: original code did not resize the background bitmap
  // so it did not cover the background on larger displays
  mWood := Bitmap.createScaledBitmap(mWood, w, h, true)
end;

If you’re working with a SurfaceView and have implemented the SurfaceHolder.Callback interface then you can do much the same thing in the surfaceChanged() method.

You can also choose to size the bitmap on-demand when it’s needed from its original size to the required size for the target canvas. This will be a little less performant than a one-off resize but can be useful. For example, the JetBoy app has a ready screen before play starts. The background to that screen was not resized appropriately. If you didn’t want to resize the background bitmap once ahead of time you could identify the current size and target size as Rect objects and call an appropriate override of the Canvas object’s drawBitmap() method:

method JetBoyThread.doDrawReady(aCanvas: Canvas);
begin
  var src := new Rect(0, 0, mTitleBG.Width, mTitleBG.Height);
  var dest := new Rect(0, 0, aCanvas.Width, aCanvas.Height);
  aCanvas.drawBitmap(mTitleBG, src, dest, nil);
end;

2) Older games were coded to assume the presence of a directional touchpad (D-Pad). Most modern devices come without one of these, so to make them usable on current devices I’ve had to add in onTouchEvent() overrides in either the View or Activity for simple screen touch responses. In the case of the Snake demo app I implemented GestureDetector.SimpleOnGestureListener to handle directional swipes.

3) Some demos have been updated over the Android releases to take on newer behaviour. For example, there is a simple Bluetooth Chat demo. You can install it and run it on two devices and the users can connect and do a simple Instant Message type chat. In the most recent SDKs for Android 4.0.x (Ice Cream Sandwich) this demo has been tweaked compared to what you see in the samples for the older Android versions. This newer version uses the so-called Holographic theme introduced in Android 3, which adds an ActionBar to the app as a side-effect. What are menu options in the earlier version are now ActionBar actions when installed on a more recent OS.

Also the newer version of the app offers both secure and insecure Bluetooth connections, something the original version didn’t as insecure Bluetooth connections were introduced in Android 2.3.3 (Gingerbread MR1).

The initial question was which version of the demo to bring over to Oxygene. In the end I got the translated app to operate on any Android version from 2.0 (Eclair) onwards.

To get the Holographic theme to be applied for Android 3 (Honeycomb) and later (and thus get the ActionBar) I took advantage of Android’s resource system (as mentioned here). I defined an app theme to be based on Android’s default old-school Theme in a resource file in res\values as per usual.

<resources
    xmlns:android=”
http://schemas.android.com/apk/res/android”>
  <style name=”AppTheme” parent=”@android:style/Theme”>
  </style>
</resources>

But then I defined the same app theme to be based on Theme.Holo in a resource file in res\values-v11.

<resources
    xmlns:android=
http://schemas.android.com/apk/res/android>
  <style name=”AppTheme” parent=”@android:style/Theme.Holo”>
  </style>
</resources>

If running on API 11 (Android 3.0 aka Honeycomb) or later the theme definition will be pulled from this latter directory. All that’s left to finish the job is to apply the app theme to the application in the Android manifest file:

<application android:label=”@string/app_name”
             android:icon=”@drawable/app_icon”
             android:theme=”@style/AppTheme”
             android:debuggable=”true” >

  …
</application>

That’s the appearance. But it was also important to ensure the option for establishing an insecure Bluetooth connection was removed from the menu if running on Android earlier than 2.3.3. Since the menu is defined in a menu resource file this simply involved having two menu definitions, one in the usual res\menu directory and one in res\menu-v10. The menu definition in res\menu has the problem option removed; the menu definition in menu-v10 will be used on Android API 11 (2.3.3) or later and has all menu options defined.

The final aspect of keeping the app version-agnostic is to check the code and what relies on the newer aspects of the source. Anything that needs to be skipped on Android versions earlier than 2.3.3 can be conditionalised using Build.VERSION.SDK_INT, something like this:

if Build.VERSION.SDK_INT >=
     Build.VERSION_CODES.GINGERBREAD_MR1 then
begin
  …
end;

Uploaded demos

Ok, so I’m done pulling Java code over to Oxygene and making it work properly for the time being. I’ve tidied up the demos that I’ve ported and uploaded them to Google Play, giving as useful a description as I can for each of them. The following are online – if you encounter any problems or have any simple improvement suggestions (bear in mind they are meant to just be ports of existing demos) I would appreciate hearing from you.

  • AccelerometerPlay: demonstrates the accelerometer sensor by representing a slab of wood with three shiny balls on it. Tilt the device and the balls roll in a quite realistic manner.
  • Bluetooth Chat: install on 2 Android phones and you can establish a connection (secure or, if on Android 2.3.3 or later, insecure) and have an IM-style chat
  • Cube Live Wallpaper: two live wallpapers. One is a rotating wire cube. One has a settings page to allow to to choose between a rotating wire cube and a rotating wire dodecahedron. On Android home screens that support it (not HTC Sense 3.0 or later, or Android 4.0 or later) the wallpaper responds to offset messages, meaning that the shape will rotate as you move from home screen to home screen.
  • JetBoy: a scroller game that demonstrates Android’s JET audio engine. Destroy a certain number of asteroids in a certain amount of time by firing in time to the music.
  • Lunar Lander: use direction and thrusters to safely land on the landing pad. I’ve mapped touches on areas of the screen (as per the app description on Google Play) to the D-Pad controls, but apparently it’s still a but tricky. This could just be a function of the game implementation, or maybe the D-Pad to screen mappings. Any thoughts, let me know!
  • Snake: The classic snake game. Swipe the screen to change the snake’s direction and reach the apples. Mind yourself and mind the walls!
  • Wiktionary ‘Word of the Day’ Widget: install on your home screen and you get Wiktionary’s word of the day displayed, along with the word’s definition. Touch the widget to open up a Wiktionary browser where you can follow links to other words, search for words or go to a random word.

The full set of Oxygene-ported Android SDK apps can be found at this link.

Alternatively all my Oxygene-powered Android apps can be found at this link.

Android game loops

July 10, 2012 in Guest Post, Java, Oxygene, Prism

I’ve been porting some of the Android SDK samples from their original Java over to Oxygene for Java, with the hope they’ll be included in a forthcoming update to the product.

I’d already contributed a port of the AccelerometerPlay demo, which is a neat little demo of using the accelerometer to control several balls on a surface (the screen).

Among other examples I’ve been looking at are the Lunar Lander and JetBoy demo games. Now, if you wanted to start writing a graphics frame-based game that used a SurfaceView as its output you’d think these would be a great starting point, right?

LunarLander

Wrong!

Well, kind of wrong anyway.

JetBoy

The games work ok and you can play them, although they both have the shortcoming that they were written back in the days when most devices had a D-Pad (directional pad) and/or physical keyboard. Consequently the original examples are unplayable on many current devices. That’s no problem – it’s not much trouble to add in support for touches on bits of the screen or swipes across or up and down the screen. Actually I had to add in swipe support for the Snake sample game, which also relied on a D-Pad, but since that one’s not based on a thread (being a simpler game it uses a Handler and its sendMessageDelayed() method).

The problem with Lunar Lander and JetBoy is with how their thread-based operation has been laid out. The JetBoy architecture was based on the simpler Lunar Lander and so both games suffer from the same problem. The symptom is that if you switch away, maybe by pressing Home or by a phone call coming through, and then switch back the game crashes out. If you look at a logcat from either app running and crashing you’ll find that the problem is an IllegalThreadStateException being thrown with the message:

java.lang.IllegalThreadStateException: Thread already started.

This doesn’t look like a very good basis for a couple of evidently appealing sample apps, being designed with a thread crash in… Clearly people will base their own games on these apps and be rather frustrated by this poor design.

Anyway, enough of the criticism. What’s the issue here? Well, a cursory search on the web shows this has (unsurprisingly) cropped up a lot of times and there have been various ways it has been responded to. So let’s look at the problem and the solution.

The games have an Activity whose UI is made up of a SurfaceView descendant. The game logic is contained in a Thread descendant. When the app starts up and the activity’s onCreate() method runs it creates the custom surface view and asks that view to create the thread.

The surface view has a couple of methods that mark the lifetime of the actual drawable surface: surfaceCreated() and surfaceDestroyed(). In surfaceCreated() the thread is set in motion with a call to its start() method. When the surface is destroyed, for example by switching back to the home screen, two things occur. Firstly a member field flag is set to indicate that the thread’s body (its run() method) should stop whirring round updating state and drawing frames. Then the thread’s join() method is called, which blocks the surface view thread until that run() method has done its job and exited.

Ok, with me so far? No evident problem so far. What happens when we switch back to the app?

Well, when the app’s UI resumes the surface view’s surfaceCreated() method is called, which calls the thread’s start() method to start it off again. And therein lies the nub of the problem. As the documentation states, start() will throw an IllegalThreadStateException if the thread has been started before.

Because of this coding scheme the Lunar Lander and JetBoy apps are set up to fail. So, what’s a good solution?

Well, I’ve tried a couple of options, some of which are frowned upon as not being the right way and settled for the suggestion of StackOverflow user Pompe de velo in this post. The changes required are as follows:

  • in the thread define member variables:
    • var mPauseLock: Object := new Object;
    • var mPaused: Boolean;
  • have the thread’s run() method keep iterating endlessly (while true do… instead of while mRun do…).
  • in this loop, after all the individual iteration’s physics update and frame drawing add:

    locking mPauseLock do
       while mPaused do
         try
           mPauseLock.wait
         except
           on e: InterruptedException do
             { whatever };
         end

  • if your thread already has pause() and unpause()/resume() type methods implemented then great. If not add them.
  • have the pause() method do this:

    locking mPauseLock do
      mPaused := true;

  • have the unpause() method do this:

    locking mPauseLock do
    begin
      mPaused := false;
      mPauseLock.notifyAll
    end;

  • in the activity’s onPause() method call the thread’s pause() method
  • declare a member field in the surface view:

    var mGameIsRunning: Boolean := false;

  • in the surface view’s surfaceDestroyed() method remove all the code relating to managing the thread
  • have the surface view’s surfaceCreated() method change the call to thread.start() to this code:

    if not mGameIsRunning then
    begin
      thread.start;
      mGameIsRunning := true
    end
    else
      thread.unpause;

Yeah, so there’s a few changes there, but once done the app can survive being switched away from and back to.

It would probably be a good move to take the fixed app, strip all the logic out and use it as a skeleton gaming loop app, which I may well do.

For now, I have more bugs to fix in SDK demo apps I’m porting over. Currently I’m getting on top of an issue with the BluetoothChat demo where exiting and restarting the app means connections from another device no longer show up on the UI. It would appear the Android SDK demos didn’t get a particularly good test through….. What’s more of a shame, though, is that despite numerous people reporting issues, the demo apps do not get updated to fix the problems.

<sigh>

Retro effects with Android

July 8, 2012 in Guest Post, Java, Oxygene, Prism

A few weeks back I was browsing Paweł Głowacki’s blog and saw his write-up on implementing both a parallax starfield as well as a 3D starfield using Delphi and FireMonkey. Quite taken with the classic starfield demo idea I though it might be neat to have a go at putting together an Android implementation in Pascal using Oxygene for Java.

As Paweł did, I used the basic Python logic from http://codentronix.com/2011/04/27/a-cool-parallax-starfield-simulation-using-python to build up the parallax version from and then used the logic from http://codentronix.com/2011/05/28/3d-starfield-made-using-python-and-pygame for a basic 3D implementation. Then I bumped into a nice DHTML JavaScript implementation of an interactive starfield at http://www.chiptune.com/starfield/starfield.html, where moving the mouse changes the aspect of travel through the starfield.

So I knocked up some equivalent logic in Oxygene in an Android application and uploaded the result to the Android Market, oh, I mean Google Play. You find the free app through this link if you want to check out the results. The interactive starfield has some settings to customise the number and speed of stars as well as whether touching the screen changes the travel aspect.

StarfieldAppMenu StarfieldAppSettings

StarFieldApp StarFieldApp2

Clearly the logic is reasonably straightforward – in each case it’s really just dots of various sizes drawn on the Canvas of a SurfaceView. This is done again and again after having moved the positions of the stars in ‘space’, but of course care must be taken to be CPU-friendly. To that end an Android Handler is used and each time a frame is drawn, the next one is scheduled in for some small time period later using a call to its postDelayed() method.

Anyway, I was quite pleased with how this little app turned out, and how it gave me an opportunity to go through the Google Play application publication process. And then I started thinking about other old effects from the demos that used to be quite popular in the late 80s and early 90s…

My favourite was the plasma effect: an undulating oozing flow of colours shifting through the screen. A bit of research helped me understand the general principle of how the plasma effect is implemented, with a plasma function at the heart of it. I found a selection of different plasma functions and rolled them into a configurable Android plasma app built with Oxygene for Java, available for free at this link:

Plasma1 Plasma3 Plasma2

Plasma4 Plasma5 Plasma6

These plasma effects are implemented by pre-assigning an interesting palette of colours and then iteratively calculating the value of each pixel of the plasma surface and plotting it on a bitmap. To keep things performant the plasma surface is typically rather less dense than the pixel count of a smart phone screen and so this bitmap is then stretched onto the Canvas of the underlying SurfaceView. However, to minimise the evident pixellation some of the effects actually render virtual pixels and use a random jitter (x & y offset) in conjunction with opacity to smooth out the edges.

Having been bitten by the bug of retro demo effects I then bumped into the Demo Effects Collection Open Source project. This shows, in C++, how a whole raft of old demo effects are implemented, so I picked a few other effects I had a nostalgic affection for and concocted Retro Effects, another free Android app built with Oxygene for Java and available at this link. This one has a fire effect, a particle explosion, shadebobs and copper bars (as well as a starfield and plasma implementation for completeness):

Fire Shadebobs

Copperbars Explosion2

This has all been a terrific trip down memory lane for me, resurging my interest in the old demo effect scene, and using Oxygene for Java has allowed me to build the apps on my favourite mobile platform, Android, using my favourite language syntax, Pascal.

Oh, just in signing off I should mention that I also uploaded a couple of live wallpapers, one with the interactive starfield and one with the configurable plasma functions. Live wallpapers are quite a nice distraction and needn’t be as much of a battery hog as they are sometimes made out to be (especially if implemented carefully). The Android live wallpapers do, however, have a nominal download charge associated with them.

I’ve been porting some of the Android SDK demos from the original Java to Oxygene, including the live wallpaper demo (a rotating cube and a rotating dodecahedron), so I’ll probably blog some technical details on how these things are built at some point in the near future.

Android development session at mobile-focused conference

May 17, 2012 in Guest Post, Java, Oxygene, Prism

On 29th June, 2012 I’ll be travelling to Cambridge, UK to speak at Mobile East 2012, a mobile-focused conference. I’ll be delivering a session on Android development using RemObjects’ Oxygene for Java development tool and catching several of the other sessions during down-time on the day.

I’m looking forward to it – it’s been some months since I’ve spoken at a conference!