RemObjects release a new Oxygene version + C# sister product

I’ve just noticed RemObjects have released a new Oxygene version together with ‘RemObjects C#’, a C# sister product that was codenamed Hydrogene – check out the announcement here. The improved cross platform support sounds interesting (traditionally, the Oxygene language would differ somewhat depending on the target platform), and in the case of RemObjects C#… well, it seems a competitor is a bit rattled!

Miguel

Dearie me – read that and you would never guess that when it comes to targeting Android, Delphi and Xamarin are on one side of the fence and Oxygene and RemObjects C# the other, for better or for worse…

Update

And now we get this…

Hoffman

At least Delphi has done generics on OS X since 2011 ;-)

Delphi (and C++Builder) XE5 ‘mobile add-on pack’ currently being discounted

I’ve just noticed the ‘mobile add-on pack’ for Delphi (and C++Builder) XE5 Professional is currently selling for half price on Embarcadero’s online store (link). If you’re tempted, then it’s probably prudent to buy support and maintanance at the same time, which does admittedly bump the price back up… though still not to the non-discounted price of the ‘add-on pack’ itself. Also, keep in mind the ‘mobile add-on pack’ is something specific to Delphi Professional and C++Builder Professional – if you have RAD Studio Professional or higher, or Delphi or C++Builder Enterprise or higher, then mobile support (iOS and Android for Delphi, just iOS – currently – for C++Builder) is built-in.

CCR Exif v1.5.3 + Android app based on it in Google Play

Recently I have committed some updates to CCR Exif (my open source image metadata parsing library) that get it working with Delphi XE5, and in particular, Delphi for Android. In the main, that wasn’t hard to do – in one place I’d (mis)used the Objects property of a TStrings instance to hold casted enum values, which is a no-no under ARC, but otherwise things (with the odd [Weak] added) were fine. Well, fine with one major caveat: the code needs Andreas Hausladen’s patch to restore AnsiChar, PAnsiChar and UTF8String. Bluntly, if support for those types really does go away in XE6, then I’ll just have to say the code will support Delphi for mobile in XE5 and XE5 only, because I’m not going to crappify it.

The whole issue is a shame, because the general language and RTL compatibility between platforms (Windows/OS X/iOS/Android) and frameworks (FMX/VCL) is excellent. For example, for reading XMP metadata, my Exif code uses the IDOMxxx interfaces, the lower-level counterpart to the rather more heavyweight TXMLDocument. Both are available to use whatever the platform. Another example: at various points the FMX platform code for Android needs to wait on another thread (the Java thread) finishing a method call. What does it use for the task? Why, TEvent, using exactly the same method calls you might have made in a VCL project ten years ago.

Anyhow, proof of the pudding, I’ve written up an Exif editing app and put it on Google Play – it’s called Exif Inspector and is available here:

https://play.google.com/store/apps/details?id=com.contiguity.ExifInspector&hl=en

Brickbats welcomed, partly because you’ll have to pay a small amount to make them ;-)

Loading the app’s icon into a TImage on Windows

Last time I showed how to load the icon of an FMX for Android app into a TImage. In practice, a lot of the debugging of a Delphi mobile app is likely to be with a Win32 ‘mobile preview’ build though… in which case it would be useful to load the icon when running on Windows as well.

To do that, you need to first add a *.ico version to the project. This is done via Project Options: select the Application item on the left, then All configurations – 32 bit Windows platform from the combo box at the top. Probably stating the obvious, but the icon loaded here should be a .ico version of the .png files set up for Android.

Once done, the most direct equivalent of the Android code I presented previously would be to use the LoadIcon Windows API to load the icon, then GetIconInfo and so forth to get the bitmap bits to copy to a FMX bitmap. Easier is to use the VCL however – since Vcl.Graphics.pas doesn’t bring in anything else of the VCL, there’s little point in deliberately avoiding it. As such, here’s an expanded version of the code I presented last time with a VCL-based Windows implementation added:

unit AppIconLoader;

interface

uses
  System.SysUtils, System.Classes, FMX.Graphics;

function GetAppIcon(Dest: TBitmap): Boolean;

implementation

uses
  {$IF DEFINED(ANDROID)}
  AndroidApi.JniBridge, AndroidApi.Jni.App, AndroidApi.Jni.GraphicsContentViewText, FMX.Helpers.Android,
  {$ELSEIF DEFINED(MSWINDOWS)}
  Vcl.Graphics,
  {$ENDIF}
  FMX.Surfaces;

function GetAppIcon(Dest: FMX.Graphics.TBitmap): Boolean;
{$IF DEFINED(ANDROID)}
var
  Activity: JActivity;
  Drawable: JDrawable;
  Bitmap: JBitmap;
  Surface: TBitmapSurface;
begin
  Result := False;
  Activity := SharedActivity;
  Drawable := Activity.getPackageManager.getApplicationIcon(Activity.getApplicationInfo);
  Bitmap := TJBitmapDrawable.Wrap((Drawable as ILocalObject).GetObjectID).getBitmap;
  Surface := TBitmapSurface.Create;
  try
    if not JBitmapToSurface(Bitmap, Surface) then
      Exit;
    Dest.Assign(Surface);
  finally
    Surface.Free;
  end;
  Result := True;
end;
{$ELSEIF DEFINED(MSWINDOWS)}
var
  Icon: TIcon;
  Stream: TMemoryStream;
begin
  Result := False;
  Stream := nil;
  Icon := TIcon.Create;
  try
    Icon.LoadFromResourceName(HInstance, 'MAINICON');
    if Icon.Handle = 0 then Exit;
    Stream := TMemoryStream.Create;
    Icon.SaveToStream(Stream);
    Stream.Position := 0;
    Dest.LoadFromStream(Stream);
  finally
    Icon.Free;
    Stream.Free;
  end;
  Result := True;
end;
{$ELSE}
begin
  Result := False;
end;
{$ENDIF}

end.