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 ?
Mixed Blessings
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.
Mea culpa.
(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.
That is, there will be a TFMXNativeEdit control (invented/speculated name) which on Windows™ will surface an EDIT control and on OS X / iOS will surface a NSTextField control.
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. 🙂
I love the idea having all the native specific features instead only having common features that all support.
So they need to implement VCL like platform specific libraries for all platforms
or
they have to render native controls from native languages(or libraries) directly. (eg: ability import objective C classes for IOS development (LLVM may help them))
and i really love the second approach and EMB is only having a small team and it is really time consuming to created libraries for each and every platform . but for second approach what they need is a small but very talented R&D team to let RAD studio support native libraries. (just as they did with typeLIB in windows)
but in both approaches it is impossible to render native controls in design time when IDE running on Windows… 🙁
I did not see any need for Lowest common denominator, due IMHO UI layer on each platform should be specific. You can use tools to convert Windows forms into OS X, if you need, but for iPhone UI you definitely need to design UIfrom scratch.
And I m fully support platform-native UI! You should be first-class native citizen on each platform, not mimicrated alien)
I thought I’m the only one Delphi developer who thinks this way… I completely agree with your opinion. There should be separate GUI’s for each platform. This is how cross platform development should be done IMO.
You are somewhat right here. It would be better to have separate controls for all different platforms but this is good only in theory.
I would be nightmare for developers they will have to build multiple UI for all platforms and maintain them.
Another approach would be to have one UI control that will popup (automatically surface) based on the platform it is running. In short it is better to have GUI abstraction. But to overcome the limitations that you have suggested there should be specific properties and methods responsible for adding or enhancing platform specific behaviour for each control and these have to be set programmatically by the developer using #IFs structure.
But I still doubt that EMB will be able to add specific behaviour for each platform. For example a dialog box in Windows just comes up (at position that we specify) when called or showed but in case of OS X it slides in from top. So my question is that will such OS specific behaviour be maintained when a developer uses FMX?
If EMBT are hoping to cling to a Windows designer for OS X controls, I still think they are heading for a whole load of hurt. Take the humble button control for example: the Cocoa library provides no less than 13 different types of button. Then there are controls like the NSBrowser, for which there is no Windows analogue at all.
So, we are already at a point where Delphi doesn’t even provide designer support for the present range of Cocoa controls; there is absolutely no concept of navigation or tab controllers for iOS and Apple-registered developers are already playing with a whole new bunch of features and controls for iOS 6, which is due for general release about the time when XE3 is rumoured to escape.
FMX would indeed seem like the Curate’s Egg but I still feel that cross-platform UI design may well be more the King’s New Clothes and EMBT have bought the whole suit.
I m agree that design-time support for Cocoa controls on Windows req some magic)
But my idea is to implement design time support for Cocoa via extending PAServer on mac os x side to generate render of designed form, and sending this render to RAD Studio. Sure, you should exteblish permanent connection with mac side. Then RAD Studio can move controls, set properties, etc.
I think it’s all about the user of the software we create with Delphi. Having a standard look and feel across all OSes is what I like to offer to users.
If an edit control on one OS has different features than another OS the user will feel alienated if they have not been exposed to both OSes.
I would probably go with separate, but compatible visual component frameworks for each OS. It’d be more difficult for Emb to keep in sync, but it’d be the best of both worlds. For those apps where the ‘lowest common denominators’ are all thats needed, the code would cross (desktop) platforms with minimal changes. BUT, extend the Mac version of TNativeEdit with any mac-specific items so the can be used, if desired. So the core properties (x, y, width, text, onclick) would be the same, but each platform would then also expose other capabilities specific to the os (specific border options or whatever).
Mobile is a whole ‘nother issue, but I dont think anyone really is pushing for a single ui across both desktop and mobile platforms.
Isn’t that exactly what Microsoft’s doing with The Interface Formerly Known As Metro? 😉
Nothing wrong with both approaches. Java passed that way years ago with SWT and Swing. But SWT abstracts platform controls so that you can design under Windows and run lunder Linux.
The only problem is Embarcadero available resources. I would prefer Android development in Delphi first and fixes for font rendering issues on current FM.