To init() or Not to Init(), That is the Correction

[Estimated Reading Time: < 1 minutes]

The short answer is: Yes, init()

In a previous post I lamented the fact [cough – Ed] that some Java class imports appeared to support the underlying Java constructors via an init() method, where others did not. This wasn’t a “fact” at all. It was a misunderstanding based on an incomplete grasp of the machinations of the Java class import mechanism in the AndroidAPI units.

In the code that was presented as part of that post, I demonstrated the construction of a JIntentFilter followed by separate initialisation. This can actually be achieved more directly.

Code completion offered only a parameterless constructor (Create) on the TJIntentFilter class which I incorrectly took to represent the Java class I was working with (IntentFilter).

It is in fact only a wrapper around that class, constructed by the TJavaGenericImport base class.

The wrapper exposes the members of the enclosed Java Class through the JavaClass member. On this member are to be found the Java constructors in the form of appropriately overloaded init methods.

So this code:

  filter := TJIntentFilter.Create;
  filter.addAction(TJIntent.JavaClass.ACTION_BATTERY_CHANGED);

Is more properly written as:

  filter := TJIntentFilter.JavaClass.init(TJIntent.JavaClass.ACTION_BATTERY_CHANGED);

Which is even uglier and less Pascal’ly than ever, imho, but does at least mean that you can consistently apply this constructor pattern when instantiating imported Java classes.