Archive for the ‘FireMonkey’ Category

Running FireMonkey apps on the Beaglebone Black

This is the Beaglebone Black

Beaglebone Black

It’s a single-board computer, about the size of a credit card. It’s powered by an ARM Cortex A8 and includes the NEON floating point accelerator. Happily that matches nicely with the Android device requirements for RAD Studio and AppMethod.

When I saw that, I wondered what it would take to deploy a FireMonkey app to it. Like most things, it’s pretty easy once you know how, but it took me a few false starts to get it all figured out. Further, much of the information online assumes you’ll be doing this from Linux. Given my aim of running FireMonkey apps on the Beaglebone, I really wanted to show the steps from Windows.

So here they are.

Read On…

ShowModal on Android

FireMonkey does a lot of work to allow you to write one set of code that compiles and runs on different platforms.

Not only that, it also does a lot of work to make many of the coding patterns that some of you are used to from the VCL on Windows, work unchanged on other platforms.

That’s great, but in some cases, re-using old patterns is not desirable. ShowModal is a case in point. Read On…

“No Code” Calculated Fields in RAD Studio and AppMethod

In Perth last week I was showing the new FieldOptions property on datasets. As part of the demo, I had to create a calculated field, and when I brought up the New Field dialog an audience member suggested I create an InternalCalc field instead.

I’d never heard of an InternalCalc field at the time, so later I did some research into what they are. In FireDAC they do everything a normal Calculated Field does, but in addition, you can define the value using the DefaultExpression property of the field, rather than having to write an OnCalcFields event handler.

Read On…

Using the FM Messaging System for In-process Publish and Subscribe on Windows, OSX and iOS.

For quite awhile I’ve been using a messaging bus within my apps to de-couple different sub-systems from each other. I use this heavily in my MVVM-based apps to minimise the dependencies between my Views and ViewModels, but it applies to non-MVVM apps of reasonable complexity as well. Read On…

A Facebook-style layout for your mobile app

I’ve been working on a ShowCase App for the Delphi XE4 release, and as part of it I wanted to have a “drawer” layout. I first saw this in the iOS and Android Facebook app, but it has shown up in other apps since.

If you’re not familiar with this, it is where your main content takes up the bulk of the screen, except for a toolbar at the top. The toolbar has a “hamburger” button that slides the main content area over to the right to expose a second content area (often a menu) underneath. Read On…

Cross-platform Special Folders in FireMonkey

firemonkey_folders2

There was a question on the ADUG list last week about how to retrieve “special folder” locations on OS X. By special folder, I mean locations like the user’s Home directory, the Documents directory, Temp directory, etc. I thought I’d write up the solution both because it’s probably something that more people will be wondering and also because it’s a nice little introduction to calling out to the OS X API.

If you want either the path to the Home or the Temp directory, this is ridiculously easy. The IOUtils unit already contains TPath.GetTempPath and TPath.GetHomePath, and these work on both Windows and OS X.

However, if you want another directory, such as the Documents directory, you need to do a little more work.

I’m sure many of you have done this same thing on Windows, using the Windows API SHGetFolderPath, like this:

As an aside, the first parameter to the SHGetFolderPath is a HWND. In VCL, you could just pass in the Handle of the form, however in FireMonkey the Window handle is a TFmxHandle, not a HWND. The Fmx.Platform.Win unit contains a FmxHandleToHWND function that, as the name suggests, will take your FireMOnkey handle and give you back a HWND.

So, back to the point, if this is how we do it in FireMonkey on Windows, how do we do it on OS X? Let’s have a look:

First thing we do is get a reference to a NSFileManager interface. It, and the TNSFileManager class that implements it, can be found in the Macapi.Foundation unit.

Once we have our NSFileManager reference, we can use the URLForDirectory method, which is roughly equivalent to the SHGetFolderPath call in the Windows example. We need to pass in a NSError variable and then check it to make sure everything worked OK. We raise an exception if not.

However, what we get back from URLForDirectory is not a string but a NSURL instance. In order to get a string containing the path, we use, not surprisingly, NSURL.Path. However, this also is not a String, it’s a NSString. How do we convert that to a string? Well, NSString.UTF8String is a quick, easy way to get back a UTF8 encoded string. If you want a different encoding, check out some of the other extraction methods on NSString. Update : Chris Rolliston has written a nice follow-up post digging into converting NSStrings to Delphi Strings in much more detail.

In the example project, once I have the full path of the Documents directory, I use the IOUtils classes to enumerate over the folders and files in that folder and add the names to a listbox:

Here’s the resulting app on Windows:

Screen shot 2011 09 22 at 10 05 32 PM

and on OSX:

Screen shot 2011 09 22 at 10 07 25 PM

You can download the sample project from my delphi-samples repository on github.