We have had almost a year of monkeying with fire now – enough time I think for people to have formed a view as to whether it is truly a viable multi-platform framework for the future, or just a convenient cross-platform solution with limited, genuine utility.
At the same time, we have had OS X and some iOS support for the same period, with the prospect of more platforms being made available to us Delphi developers in the future.
So, looking ahead, do we see FireMonkey as providing a solid foundation for a cross-platform future, or would we prefer to see tighter, closer “native” support for MULTIPLE-platforms (both currently supported and envisaged/promised) ?
I know what I think:
As much as I’d prefer to use ObjectPascal, I quickly decided that using Delphi + FireMonkey for OS X / iOS was like trying to ice-skate uphill. I couldn’t shake off the feeling that the disconnect between me, my code and the environment I was writing for was going to be a source of nothing but constant pain and frustration, and so decided to learn Objective-C and Xcode instead.
I anticipate this will be only worse when it comes to Android, so that will mean also tackling Eclipse and Java – a far less enticing prospect for sure.
Which led me to wonder, am I the only one that finds FireMonkey so disappointing ?
So I decided to run a poll to (unscientifically) gauge the feelings of the community in this regard.
The (very) early numbers are quite interesting, suggesting that people see some utility in FireMonkey but also a keen interest in (as I read it, tipping ever so slightly “in favour of”) native platform support at least as an alternative.
That makes sense to me.
Even though I do not currently have a use for it, I can see the potential of FireMonkey as a conveniently cross-platform graphics/visualisation sub-system for use within “platform native” applications. I just wouldn’t want to build my entire app that way.
What do you want ?
I do not think the world needs another multi-platform write once, deploy everywhere solution. We have sort of 2 – Java and Javascript + PhoneGap – and quite frankly – Javascript + PhoneGap performance is good enough that there is no real need, imho, for compiled code for most multi-platform apps, and those that do need it – need to go down to the metal without FireMonkey, honestly.
There is room for both native support and a cross-platform widget set, I would say, but neither are panaceas. The problem is that the current approach is basically FMX or nothing (nothing visual).
Having platform-native UI components that could (optionally) mingle with FMX (or other component sets, f.i. you could have one based on a WebView rather than DirectX/OpenGL) would be preferable. Yes, that mean each native UI “form” wouldn’t be cross-platform, and that if I make a windows UI with VCL I can’t run it in iOS where I would have to use iOSCL instead. However you can rarely use the same UI across devices with vastly different screen sizes and paradigms, so even with a cross-platform UI, you end up needing to build different UIs anyway (and FMX styles only cater to form theming, not form layout, unlike CSS f.i.).
That would mean each xxxCL could cater to the specific UI needs and capabilities, and could include FMX elements where/if they make sense (ie FMX could be a container component available on all xxxCL). FMX could then also be incrementally added in apps where it makes sense (where eye-candy matters, not necessarily in every form).
In the end, it’s all about performance and native looks: if you don’t get at least one of them nailed to perfection, then you’re just going to be at a disadvantage against native solutions and the likes of HTML5/PhoneGap, which will both run circles around you (different circles, but circles still)
Exactly. And the other problem is that if the compiler engineers are told “don’t worry about extending the language and compiler in order to bring the language closer to the platform, we won’t need it with this super-duper cross platform abstraction” then you end up not getting the bindings you need to work effectively with other aspects of that platform that aren’t covered by the GUI abstraction.
So they end up building (incomplete) bridges across the platform divide, which is how FPC started out with OS X support. They quickly dumped that approach in favour of extending the language to embrace the platform. Which means that you can write platform code in FPC Pascal where needed, and platform agnostic code everywhere else.
With Delphi as it currently stands, the only real platform is FMX. Everything else is the Ugly End of Hackville. 🙁
Opposite to your comments regarding a year being enough time, I’ll believe it is not. A lot of people who could exploit the advantages of FireMonkey is just waiting to move on from the “first” version effect.
We will see a lot more third party work and more developers working on FM on XE3 and on. I for one will love to be able to target a lot of platforms without having to jump into a wide variety of solutions, do I need FM now? probably not. Would I use it later, probably yes, I’ll think that around XE3 it will be solid enough to start developing some apps directly on FM to work under Windows, just to keep the door open to offer our products on other markets once they grow more than their current %s.
It’s enough time to understand the architecture and the approach and form a view as to whether it is an approach and an architecture that will be viable on other platforms.
As soon as I ran into the question of “How do I invoke performSelectorOnMainThread ?” I realised that no matter how good FireMonkey might eventually become, without the language and the compiler cosying up much closer to the platform, it was simply a non-starter, or at the very least very limiting, and limited, approach.
FireMonkey as it was/is was not good enough. If it becomes “good enough” then it is still not enough to make Delphi a viable choice for serious OS X work without those language and compiler changes (the avoidance of which one must presume was decided when the FireMonkey approach was adopted in the first place, so the sooner we stop kidding ourselves and start telling Embarcadero that it won’t work, the sooner they can start doing something about it).
And the problems on Android I imagine will only be even greater still.
As soon as I ran into the question of “How do I invoke performSelectorOnMainThread ?”
What was the context, out of interest? (The fact a method isn’t on the wrapper interface type declared in the relevant Macapi.* unit doesn’t mean it isn’t callable.)
The question was “how do I execute some code in the context of the main thread”. I stopped using “Synchronize” a LONG time ago (back when it was badly broken) and use the platform supported mechanism for achieving this on Windows – much simpler and more reliable than “Synchronize”. Looking for the same mechanism on Cocoa I found “performSelectorOnMainThread” which as you know is not included in the bridging interface in the MacAPI units, and of course all references on it’s use assumed that Objective-C was being used.
Red flag #1 – when developing for the OS X platform the vast majority of references and resources will be of virtually no use to a FireMonkey/MacAPI.* developer.
But more important than this omission on it’s own was that this brought to light the whole concept of “selectors” (bearing in mind this was before I had sat down with any Cocoa or Objective-C references) and in particular how these things called “selectors” had to be fabricated on the “Delphi side” in order to be used across the divide on the OS X side.
When I found the swathes of code required to coerce and cajole Delphi code to “play nice” with OS X (of which I surmised this business with selectors would be just the tip of the iceberg) it immediately “smelled” bad. I couldn’t believe this was the only way it could have been done, which is how I then discovered that this was EXACTLY the way that was initially tried with FPC and subsequently – and quite quickly – ABANDONED for the same reasons that I found it so questionable.
Red flag #2.
You don’t put a bad egg in an omelette and just hope that the other good eggs will mask the taste.
Er, I don’t quite know where to start:
– You want Synchronize functionality – seriously?
– Funnily enough, the FMX/OS X implementation of Synchronize is not the same as the VCL/Windows one back in 1999 or whenever it was you last used it. What problems did TThread.Synchronize in FMX actually give you?
– performSelectorOnMainThread works on a selector because it is an Objective-C method. Big surprise, eh? I really don’t understand why you think you need to call it: TThread.Synchronize is for ‘synchronising’ property and method calls on VCL (and now FMX) objects, and plainly, you don’t set an FMX property by sending an Objective-C message.
– The Cocoa threading API sits on top of the underlying pthreads API; the Delphi RTL’s threading functionality, on OS X, sits on top of the underlying pthreads API.
– Admittedly, it is true you can’t use the Cocoa thread pool (‘Grand Central Dispatch – Apple have a thing with names, eh?) from Delphi, but then you can’t from FPC either.
– “when developing for the OS X platform the vast majority of references and resources will be of virtually no use to a FireMonkey/MacAPI.* developer” What crap, sorry. Reason 1: the Cocoa API layer is not everything (there’s also the C-based Mach, POSIX and CoreXXX APIs, all of which remain current). Reason 2: the Delphi to Objective-C bridge is good enough for its purpose, and despite what you insinuate, you are not stuck with the small set of wrapper interfaces provided. Reason 3: where on earth do you think I got the information for posts like this and this on my blog? The Apple docs and OS X developer sites, that’s where.
– Your hyperbolic attacks on FMX now are as overwrought as your hyperbolic praise of FMX back in August. Remember when you claimed it would be an industry-changer?
I’m quite hopeful for FireMonkey and I think it has great potential, but it is quite buggy (aside from the whole native/not native arguments). I made a decision to focus on producing movies on the VCL (I’m almost 2 hours into part 3) and ignore FireMonkey for now. XE3 might change things, but I suspect not. I think it will be quite some time before I consider producing a commercial FireMonkey video (I’ll still produce free ones however).
My point is that we need some usable Pascal language on OSX/iOS.
But FMX emulation layer never catches platform. You simply can not fit perfectly inside platform. On iOS GUI code/events/animations runs inside kernel, so it is responsive thing. FMS code on iOS runs as custom app, so no priorities and you always recieve lags. Maybe hardware evaluation can dither this fact, but current generation devices are unable to perform perfectly with FMX emulated controls (with medium/large custom data inside controls).
The only cross-platform thing in apps is wire-compatible core of application. GUI layer always should be platform-native to provide good user exp, look&feel, and native design for designed screen size.
Maybe we need some approach as SmartMobile studio have: compile Pascal code in some platform-native one, with platform-native bindings, and some interoperability with platform. For iOS/OSX maybe it should be CodeGen for Objective-C from Pascal. Will mail folks from SmartMS about this)
/me in role of R&D in $$$: Either native or as-simple-as-gets-to-run-everywhere JavaScript. (That’s why I like Smart.)
/me in role of private developer: Whatever works.
Of course, the first role has a bigger budget and is of more interest to software makers. Therefore – sorry, Emb, we are not really interested in Firemonkey. We want VCL to be actively developed.
We have a huge graphics app on Win32/64 and want to deploy that app on Mac too. But the majority of code won’t run on FM. The different interface is the main problem (I am not talking about Win API things).
In those days, when only appeared VCL it is also blamed for many of the imperfections and predicted a quick end.
It seems to me that there is a future Firemonkey.
Ivan, I don’t remember the days when the VCL was blamed or criticised in that way. CLX, yes, and we all know what happened to that.
But the VCL has always been a strong point of Delphi. Yes it had it’s fair share of bugs but the critical thing was, the VCL was never the ONLY way to write Windows applications. Indeed, ObjectPascal in Delphi has been extended and enhanced over the years to specifically cater for the Windows platform.
No such effort has gone into embracing OS X or the other platforms now being supported.
In contrast, that is precisely the approach now taken far more successfully (imho) by FPC – they abandoned a long time ago the “bridge it where we can, ignore it where we can’t and hope it doesn’t matter” approach that Embarcadero have stuck to.
I mean in 1995-1996 at the time the opinion is also double vision, and if you do not remember it does not mean that this was not.
There are no some basic components that every visual library needs to have. It’s why I’m still with VCL.
I’m my country, as in many other countries around the globe (except U.S.A.), the Apple market is close to 0 zero, in the Mac front as in the iPad, iPhone front.
I really prefer to see a cross compiler for Linux rigth now even for non GUI server side apps (I know CrossK… is there, but we prefer something more current)
Mac apps for now is just a curiosity or novelty, Android market is by far much larger, but phone paradigm is totally different from desktop apps so trying to get a code for my multi-dll-w/runtime-packages-multi-MB desktop application that run on a Android device (event a tablet or the super Samsung SIII) is just plain stupidity beyond my wildest dreams.
When I need a mobile app I will use the tool and the paradigm that fit the mold.
Firemonkey could be the key of success for delphi. I hope really that the new compiler of delphi will be based on llvm and open new target os (and javascript too with emscripten). My dream will be to write once code and compile in native code on android, ios, windows, linux, mac for performance or compile on javascript for rich web apps. FIremonkey for javascript will be really a must. Smart mobile studio is really nice but the ide is not ready for prime time IHMO and we cannot compile native code. Firemonkey have somes architecturals problems that could be resolved but all kinds of UI are realizable. this is the main advantage of vectorial gui framework. We are not constraint by the native ui framework of a particular platform or Os.
SmartMS can make PascalToObjectiveC CodeGen, just like JS CodeGen)
It’s just my idea, but main problem is VCL/RTL for OSX/iOS
A native interface is really necessary for xplatform Delphi. FMX is an interesting option, but its too shallow to rely on unless all you do is run-of-the-mill, paint-by-numbers applications. As long as I waited for a Mac compiler for delphi, its a shame that I cant port my applications because of the lack of some very essential bits of functionality. If a native interface was available, I could at least do what you do under windows – use the native functionality directly. But FMX doesnt let you mix and match user interface elements like that. Its always one step forward, one step back with them. Create a great xplatform compiler, and then cripple it by essentially limiting people to FMX.
Hi JerseyGuy! How’s the wife?
Although it is a bit tedious, Delphi can use native controls, using the Macapi.* units. I put a demo on StackOverflow. I guess it is also possible to load an IB file with Delphi, link up to the controls and use that. You are not really limited to Fioremonkey, although doing without it is a lot more tedious than, say, using the VCL in Windows.
I still hope someone, or some group, designs something like a simple VCL for Cocoa.
VCL for Cocoa;
Me too. In fact, I had hopes that the LCL-for-Cocoa (lazarus) would be that, but it seems a “90% done, 90% to go” effort.
Warren
Win 8 is for me as an business software developer unacceptable – I will use Win 8 on my private gaming and internet surf station computer – but I can’t use it with my business. Customers will stay at XP or WIN 7 for a long time.
As a conclusion I guess LINUX OS system like UBUNTU will have a good change to gain more market share , not only in the server domain. FM not only for IOS but including UNIX and ANDROID will have a bright future under one constrain — fast spread over many platforms , this is my forecast
technical bugs in FM will not be the limit if EMBA can delivery many frequent updates and the comunity sees their strong support
Short and sweet, I have high hopes for Firemonkey cross platform! I want to create code one time only 🙂
Hello:
What do the posters here think of using Lazarus (with Free Pascal) as a means to port Delphi/Windows code to Mac OS X and Linux instead of using an unrelated development environment such as Objective-C and Xcode? (Although the current – stable – version of Lazarus only fully supports Carbon, while Cocoa is still in development.) From what I’ve read, it seems that Embarcadero thinks well enough of Free Pascal to include it with Delphi XE2 as the iOS compiler.
I have no experience yet with Object Pascal, Mac OS X or Linux development, but I’m interested in the opinions of those with experience.
Thanks!
Jerry
Firemonkey is a joke at this point, a lot of bugs and Embarcadero keep saying they will support Android, they don’t support iOS at this point.
They think we will wait 2 years from now to have something that works, even if it will work in the future.
“My point is that we need some usable Pascal language on OSX/iOS.”
Isn’t Free Pascal usable on OSX?
“Isn’t Free Pascal usable on OSX?”
This is something I intend to find out very soon. 🙂
FreePascal is good compiler, but lazarus is bad IDE. Delphi XE2 is good IDE, but RTL on OS X is tightly coupled with FMX emulation layer, so its not native for OS X. Its a problem, IMHO, and this makes Delphi near to useless for iOS – due to emulation nature of FMX – performance on iOS is not good.
http://op4js.optimalesystemer.no/
FMX left such a bad taste in my mouth that I have left it. Instead I using SMart Mobile Studio – well worth checking out. See link above.
I am in no way affiliated with them but for me it was a excellent means of being able to leverage my pascal knowledge to build HTML5 apps and enviroments.