Where the platform allows, supports delayed rendering, virtual files, change notifications, and inter-process TClipboard-based drag and drop. The code originates from the FMX TClipboard I published a few years back, though is much extended, and was refactored to support the VCL too (XE2+). For more info, check out the readme first…
Disclaimer: supporting multiple FMX versions ain’t no fun, so if you come to try it in XE4 or whatever and have an issue, I may not be able to help you. Also, if you’re interested in drag and drop on OS X, consider using my code with any version lower than XE8 a ‘proof of concept’ only…
Just a quick post to say Embarcadero have released hotfix 6 for XE5, which resolves significant issues when attempting to develop iOS apps in conjunction with iOS SDK 7.1 and Xcode 5.1. More info is available here; the hotfix itself is downloadable from CodeCentral here.
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.
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:
Just a quick post to say I see Embarcadero have released an updated Android platform style for Android 4.4 (KitKat) – for more info see Sarina DuPont’s blog post here, and to download the actual style file see here.
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:
System.SysUtils, System.Classes, FMX.Graphics;
function GetAppIcon(Dest: TBitmap): Boolean;
AndroidApi.JniBridge, AndroidApi.Jni.App, AndroidApi.Jni.GraphicsContentViewText, FMX.Helpers.Android,
function GetAppIcon(Dest: FMX.Graphics.TBitmap): Boolean;
Result := False;
Activity := SharedActivity;
Drawable := Activity.getPackageManager.getApplicationIcon(Activity.getApplicationInfo);
Bitmap := TJBitmapDrawable.Wrap((Drawable as ILocalObject).GetObjectID).getBitmap;
Surface := TBitmapSurface.Create;
if not JBitmapToSurface(Bitmap, Surface) then
Result := True;
Result := False;
Stream := nil;
Icon := TIcon.Create;
if Icon.Handle = 0 then Exit;
Stream := TMemoryStream.Create;
Stream.Position := 0;
Result := True;
Result := False;