In the comments to my previous post, David Intersimone mentioned that Embarcadero are working on enabling support for platform native UI controls within FireMonkey!
The team is working to surface native controls for FireMonkey on each platform. Then developers will have the choice to use vector drawn components in their projects across all platforms – or to choose to have native controls on each specific platform. More to come when additional FireMonkey capabilities are completed.
This confirms what I had already heard through unofficial channels some weeks ago from a different source. At that time I was highly skeptical and thought that someone must have misunderstood what was going on.
Surely the whole point of FireMonkey – it’s very philosophy and raison d’etre – was to eliminate native UI bindings in order to provide a unified, and universal, GUI abstraction for all FireMonkey supported platforms ?!
i.e. if you developed a FireMonkey control (or indeed complete GUI) you only needed to do that work once and you would have something that worked on all supported platforms, using theming and styling to achieve platform “native-lookey-likey” where appropriate and necessary.
To now decide to include native controls in the framework surely constitutes a tacit admission that the FireMonkey approach was flawed from the outset ?
On the one hand, at least the realisation has finally dawned that native development is not just about the bits and bytes spewed out by the compiler, but also goes deeper (higher?) into the user experience and – I would argue – the developer experience when targeting a specific platform. We can perhaps now at least look forward to being able to create true native GUI applications on the FireMonkey supported platforms in the future.
But on the other hand, this capability is still going to be tied into the shockingly poor quality FireMonkey framework, and the precise approach being taken might itself be problematic.
I advocated all along that the (UI components) in the VCL should remain Windows specific, and that a separate UI framework be created for each supported platform as required. However, when FireMonkey was first demonstrated I genuinely believed that this “abstracted canvas” approach was actually a pretty good idea and had the potential to be hugely successful.
But that was before I actually had any experience developing on the other platforms that I anticipated FireMonkey would be useful for.
(As an aside I suspect that this might also be at least partly responsible for the mindset that led to the FireMonkey approach in the first place)
My biggest concern with a “universal native” approach is that the intention will be still to have a single FireMonkey control that will automagically surface an appropriate native UI control internally. This appears to be the approach being taken in the proposed NakeyMonkey project initiated by Jason Southwell, for example.
i.e. that they will still be clinging on to “the single GUI for multiple platforms” linch-pin of the FireMonkey approach
When employing native controls, the problem this suffers from is that of “Lowest Common Denominator”. A problem that even Embarcadero themselves recognise!
Any “TFMXNativeEdit” control can only sensibly provide functionality (in the framework exposures) that is common to all of the supported underlying native control variants. It can only do the things that both EDIT and NSTextField can do, presumably somehow yielding access to the underlying “true” native control for those things that need to go beyond that lowest common denominator.
Edit controls are perhaps a bad example to use for raising such concerns as I suspect the capabilities of such controls are pretty much the same on every platform, which is why they are also a bad example to use when testing out the feasibility of such an approach, imho.
In any event, the whole problem is very easily avoided by instead having separate controls for the different platforms. A TEdit, being tightly coupled to the Windows™ EDIT control can provide everything that an EDIT control can do, and a TNSTextField can (or rather could) do everything that an OS X / iOS NSTextField can do.
Yes, this means having two separate GUI’s in your application, but any self respecting developer these days has very, VERY little actual code embedded in their GUI. The GUI is – or should be – a very thin layer on top of underlying business rules that actually perform the functions that the GUI exposes to the user.
And having separate GUI code is an opportunity, not a problem. It gives the developer the ability not only to use controls that are native to each platform, but to also ensure that the entire GUI as a whole fits the user experience expectations of the platform, which goes beyond simply having “familiar” controls used in the windows presented to them.
I fear that Embarcadero believe that in FireMonkey they have a goose capable of laying Golden Eggs, when all it’s actually capable of producing is eggs of the Curate’s variety.
The Undiscovered Country
Of course, the future is yet unwritten for those of us not privileged to be under an NDA. My fears may prove to be unfounded but it is becoming increasingly frustrating that Embarcadero seem intent on dashing my hopes and expectations and all too eager to realise my fears.
But as I say – we do not yet know, and even now I am trying to remain optimistic.
IMHO it would be far better to at least have some idea, one way or the other.
But even those of us who have already paid for XE3 (i.e. on SA agreements) have NO information about what we will be getting for our money in a month or two’s time.
It’s like waiting for the Lotto results.
Or playing Russian Roulette.
Feel free to choose the metaphor you feel most appropriate to your situation. 🙂