A short time ago I had a harsh twitter argument with Nick Hodges (@NickHodges) about the FireMonkey framework in Delphi XE4 (you may know that I had the start of my professional career with Delphi and started as a speaker at Delphi conferences).
It all started with the definition of 'native' or - even worse - 'true native', but let's start at the beginning. I know the audience of my blog is mostly .NET focused, so let me get you all set with the required background information.
FireMonkey
So, let's start what FireMonkey is - or aims to be. FireMonkey is a application development framework (or platform, as Embarcadero likes to call it) and contains components that should enable the developer to build cross-applications with a singe code base for Windows, Mac OS X, iOS and soon to come Android. FireMonkey is written for Delphi and can also be used from C++ within Embarcaderos C++ Builder.
So the main idea is, that you design your forms with FireMonkey components and controls, double-click on buttons to add your business logic like Delphi developers did this for the last decades and then be able to compile the application for Windows, for Mac OS X and for iOS without changing it anymore.
And indeed, this works technically...
Architecture
...but this is also already the point where it starts getting wrong.
FireMonkey, by it's RAD approach, encourages the developer to click his user interface together, double-click on controls and put all the logic onto the form - where it doesn't belong. I'm not going to argue with anybody about decoupling, testability of code and all the other Clean Code aspects and concepts. A good developer should have the inner urge to produce code at a certain minimum quality level and putting everything on the form is nothing that helps here. So, the basic concept that FireMonkey encourages is wrong.
New and not-so-advanced developers tend to adopt this bad style and start running into a direction that will end up in fatality. Good developers instead will start by building up a good architecture for their application. Most probably working with tests, that makes the usage of some DI container a no-brainer. This most probably also lead to a good decoupled architecture on the application frontend, perhaps introducing some MVC concept for their GUI. Only this enables them to take a good approach to real and thoughtful cross platform development, but more on that in a minute.
Cross-Platform
Let's talk about cross platform development in a general way, before we go back to FireMonkey.
Every platform has its specifics. And a user - that is, in fact, our customer we want to sell our application too - chooses his platform for some reason. There are multiple approaches to make the user happy, and the most simple thing is, to integrate the app seamlessly into the environment (platform) the user chose to please him.
Let's talk a little about UX. I'm thinking about the overall user experience with your application here, not only the look & feel of the GUI. It's the whole full package including a good guidance through the workflow, helping the user to not enter crap into your app, assisting him to solve problems when he does, make everything accessible for everyone, especially impaired users, and of course also response times and stuff. As said, the whole package.
All platform vendors have thought about how their platform / devices should behave, how software should behave on the platform and what they expect from an application. They offer UX guidelines that describe what fits into the environment and how applications can fit seamlessly into the platform, providing an overall exquisite user experience to the guys you want money from.
Comparing just Apples (iOS and the Mac) and Googles (Android), which are the current relevant platforms for FireMonkey besides Desktop-Windows, UX guidelines shows you how different the platforms are. They are fundamentally different in how the control flow in applications is expected from the user. Leave alone Windows RT for tables and Windows Phone, which have a radical new approach to interacting with applications. But since Windows RT and Windows Phone are not (yet ?) supported, we don't need to get into those details right now. Just so far right now: Delphi is marketed as the best/fastest/most productive dev tool for Windows. Why can't you target Windows RT? Or write Windows Store applications for Windows 8 with it? Well, thats another topic. But still taking into account, that the main target audience for FireMonkey are Delphi (and as such mainly Windows-) developers, this leads into a fatal direction:
FireMonkey encourages the following: The Windows-Developer designs his FireMonkey form for Mobile Devices just as he would design a Windows-Application form. This for Windows designed UX is ported in a one-size-fits-all attempt onto the Mac (not so extremely terrible bad), but also to iOS and later Android (overly extremely bad).
Why is this bad? Because the user chose his platform with something in his mind. This something is the overall user experience with the device and of course with the applications he gets from the store within the platform itself. It's a closed ecosystem for his needs. He expects his iPhone/iPad-Applications to come in his loved iOS style or he expects his Android-Applications to come in an Android-Style. So again, we need to please our customers because they are the ones buying our applications and giving us their money. So how can we make them happy? Give them, what they expect.
Users expectations, and a sub-plot
That can be done only in one way: To embrace the platform and behave like a good citizen on that platform.
Developing a 'native' application is not the only way, but whatever technology you choose, the result should still integrate seamlessly into the environment.
A good example is Exfm. They have a music sharing service, and used to publish a 'native' iOS application. Native as in written in Objective-C with XCode. It had a 4-star rating. Still they did a rewrite of the app - with HTML5 and JavaScript - based on PhoneGap. During the rewrite and despite the fact that they were actually programming a web application that runs in a UIWebView browser, they incredibly focused on iOS detail behaviour like the scroll bounce thingy or the possibility to scroll-bounce elements that don't need to be scrolled because they are not larger than the area displaying them. They even mimicked the iOS behaviour that you can tap and hold on a button, move away from it, slide over the button again and lift your finger to trigger it. They did that with HTML 5.
They did that for one reason: To behave like a good citizen on iOS. To please their users.
And now they have a HTML application that you can't tell apart from a native application that uses the native UI controls of iOS. The new app now got a 4.5 star rating and more downloads than ever. Here's an article with a lot of more detail information about the little iOS details that make the app feel 'right' on iOS.
Now let's get back to FireMonkey.
Einheitsbrei
I'm trying to introduce a new word to my english speaking friends: 'Einheitsbrei'. You already use some german words like Zeitgeist and Kindergarten, and now it's time for 'Einheitsbrei'.
Einheitsbrei is a word that could be translated with 'boring standard mash'. Is used deprecative and describes things that are boring, common, and don't have any specific characteristic or outstanding elements.
FireMonkey apps are Einheitsbrei. They are sub-standard on every platform and don't take into account the little, loved by users, elements of the platform they are running on. And in some cases they don't even get the basic things right.
Architecture, the second: Doing it better
In the first architecture section I described that a good application architecture very probably involves some sort of DI and MVC on the GUI part.
Nick said on twitter:
@phoenixhawkAnd you have full platform access with Delphi for iOS.You can call any API you want.
— Nick Hodges (@NickHodges) April 23, 2013
So, let's take this for granted. When I can call 'any API I want' with Delphi for iOS, then I would have full access to all native UI controls on iOS. When I already have MVC in my application, then there is nothing that would hinder me as a developer to use the DI container to instantiate a view for iOS that is using the iOS native UI controls, and to instantiate a view for Android that makes use of the native Android UI controls there.
With just a little bit more effort on the views using the platform APIs, bypassing FireMonkeys UI controls, your app could behave like a good citizen on the very specific platform my customer chose for himself for a reason. Remember: that customer guy is the guy I need to make happy because I want him to give me his money.
Conclusion
Yes, it's more effort. Yes, it will take longer. Yes, it will require you to learn about the platforms UX design guidelines and about the platforms native UI controls. But it's worth it. Like extfm, who re-wrote an existing app with the goal to their iOS users more happy and another one that makes their Android users happy.
FireMonkey instead encourages you to produce Einheitsbrei. And this is just so wrong. You will find out, when you don't get the ratings required to have enough sales for your app. Users are cruel. They buy your app, and rate it down when they don't like it. And they tell other users to not buy your app, when they are not happy with it. They will, however, rate your app up and tell others to also buy when they really like it. But just when the app's buttons are so good, that they want to lick them.
Your app needs to be outstanding, of high quality and provide a well designed user experience to be successful and to be able to compete against other applications. Einheitsbrei doesn't sell. And FireMonkey, by design, encourages Einheitsbrei. You won't do yourself a favor by using it.
This is my opinion on why FireMonkey is just so wrong.
Correct, if an app needs to sell in the app stores it has to have the look and feel of the gui.
But, there are more apps than these in the app stores. If a company needs the exact look and feel on all platforms for their inhouse projects then Einheitsbrei makes sence. Especially the training department will like the idea.
So it depends on your goals
Just my 2 cents
Markus
I’ve got to agree that an application should follow the guidelines of the platform on which it is running. Having said that, why can’t a delphi programmer write business logic in separate classes and write a different GUI layer for each platform that talks to the business layer. Surely this approach would resolve the issues you have identified?
And as to your point on the click-click code paradigm, you may find a lot of c# winforms developers do the same. If the event handler simply routes to a business object and does something with the results, I fail to see the problem. As far as I can see, your problem is with the separation of GUI from business logic. I don’t think this is unique to delphi.
Incidently, I’ve been writing c# for the last 9 years and see all these problems with winforms too. I think the idea of being able to develop a GUI for each target platform in a single IDE is amazing!
The only thing special about a smartphone is that it’s mobile. The “user experience” argument is exactly the opposite to your opinion. Serious users want simple and intuitive relatively-standardized functional UI design, not some iOS-or-Android-specific special way to swipe your finger across the screen like a Harry-Potter-wannabe or shake-shake the phone to make your playlist shuffle! Better stick to Angry Birds and your “dotSlow” “platform”! (;-D)
This is a good post and I do not disagree with your basic points, but here is my hope for Delphi and Firemonkey. The power of Delphi to me has always been that RAD thing. And feeding the RAD has been the large component base. I can see the Firemonkey component base expanding into more native UX options. That component base will no doubt fork to the different supported platforms. And as already shown in some of the Embar. demos, minor changes to make the code base run on the different platform.
I don’t think einheitsbrei is a real problem.
Firemonkey is able to detect the operating system and the programmer has to adapt the program’s look and feel to the OS (and screensize). Lots of code can be general, but it wil take some effort to adapt the screens to the OS (and screensize). This is much faster and cheaper than recoding a whole program for different OS’s.
Choosing only one OS you support and have customers to adapt to your choice (or they won’t be your customer at all) is even worse these days.
Einheitsbrei will be welcomed for incompany programs where a mixture of desktop and mobile equipment is used. When writing a manual you’ll prefere a program looking and working (almost) the same on any OS or screen.
Developping a different version for every OS and perhaps even for different screensizes, in a more native developing environment will result in better and faster programs. If that’s your point I must agree, but I’m glad Firmonkey gives me the opportunity to write programs for both Windows and Mac’s.
Well probably a good approach is the One from tms software …. A good way to develop should be the Apple way, to develop code on portable datamodules and components or objects, then linking to more native UI. But behind firemonkey i find still a useful connection with data Access and datasnap, to let Apps easy interact with Application servers
I don’t see any argument against Firemonkey except your feeling of the same application looking and feeling the same on different platforms which is actually great.
Imagine a PC User @home who has Apple at work and may use the same application (e.g. an email program/office) without reorganization.
Somehow I feel like you are worried about having somekind of Microsoft Frontpage HTML mess in a 56k world. But since the compiler creates two independant executables which fit to “their” OS and not just create the Windows Exe, screenshot it and paste it as an image to the Mac OS form I don’t see any problems with drag drop components.
While the argument about the architecture side is correct; I think this is developer-related problem, Microsoft products has always directed the developers in the wrong direction, however the tools don’t prevent the seasoned developer from creating great applications with good architecture, the same goes true for Delphi/Fire Monkey
On the other side; the ability to use the same code base on different platforms is amazing even with some minor needed changes especially on the view layer, think about the effort and learning curve needed for developing the same application on iOS and Android for instance.
I think if Delphi/Fire Monkey focus on the future will be a high quality and reach set of components, Delphi golden days are back.
You argument is fundemantally wrong is every aspect. Programming is such a task, that should not involve platform specific details (if possible). Which is better , multi platform, balanced, good performing, but UI components doesn’t seem platforms original ones or the one only works in that platform and using original components ?
For commercial programs (is there any other category ?), costs are highly reduced avoiding platform specific details, no one cares platform specific UI components. The thing is if the program works with a fine but different UI, it is ok and if the program works in more than one platform, we call it the real solution.
We’ve just finished a mobile project about 35.000 lines of code in firemonkey for android and IOS platforms. But we developed it as a desktop application for windows first, all debugging was done in windows desktop platform. So development speed was really awesome. Now, all the project can be compiled to mobile platforms without any need to change a single line of source. No one cares android or ios specific components. In every aspect of programming concepts, work is done, and this is a real working solution.
There are points we can criticize about firemonkey, real points, not the ones about UI. For example there are important gaps in firemonkeys library, or some real missings in the very heart of the framework. We are expecting RAD team to close these important gaps.
Look at TMS’ iCL and mCL components. This is why I think FireMonkey is the work of an evil genius: You can now use Delphi for all platforms with native look and feel. You can’t crosscompile, but you don’t any longer have to learn several different language for each platform.
Sebastian,
It seems the only beef you have with Delphi/Firemonkey is, that it’s possible dbl-click the elements at designtime, and write code in the autogenerated eventhandler. Thats obviously just one approach to building a program.
About Enheitsbrei: I would say that in some apps einheitsbrei make perfect sense. In other apps, especially apps you want to SELL for money in appstore/Google Play store, I agree 100% with you. An iOS user expects the look and feel of an iOS app as well as the Android user expects the look and feel of an Android app.
I am pretty sure that developers that want to target more than one platform are very aware of that. I really do not think that anyone in their right mind would want to target iOS with an app that looks like Windows, that would be stupid.
Sticking all the business logic in their own code files, and calling them from different user interface elements makes perfect sense to me. Currently I am building an app for iOS. All the “business-logic” is seperated in code files away from the GUI. The look and feel is very much iOS. When I’m done, I’ll start a completely new project and build an android app. The Android app will have the look and feel of android apps, and use the same “business logic” files created with the iOS app.
I think also one must realise that is was never Embarcaderos intention to build “The one and only tool”. The goal was not to build the best tool for iOS apps nor the best tool for Android apps. But to build a tool that can build very nice apps, with the correct look and feel for both (and even more) worlds.
And they’ve done a very good job of it.
Regards – Jens Fudge
Sebastian, I mostly agree with you about the design principle. What you said about architecture is true. What you say about how average developer build is application is also true. But not all developers are average. Some are able to build the application by carefully separating business rules and user experience. Whatever the UI framework is. You should not blame FireMonkey, but the way most IDE work today: letting the average create his simple application fast by clicking here and there. We all know that this average developer will never build the best application… In that landscape, FireMonkey is not different from UI framework form other vendors.
What you seems to ignore is that FireMonkey offers the required features, as HTML5 does, to build good citizen application in all target platform. Of course this require some work from the developer, but the tool is here with a growing number of features to easy cross platform development.
One has also to think about platform vendors business. They all want to catch the entire market, if possible. The want to offer the latest nice UX feature the other don’t have. But is this what the user really want?
There are 3 kinds of users: the professional user, the gamer and the geek. professional user has a work to be done. They want an application to do that work, as easy, fast and seamlessly as possible, without gadget. The gamer wants fast and fancy graphics. And the geek want the latest nice feature to show his friends. OK, there is a 4th category: all the other. They almost don’t care about to do a task as long as they can do it. Anyway someone else will show them how to use it. In a sense this 4th category is closer to the professional category.
Maybe the next killer application will be one doing a real work, basically just doing that work. Very simple, without any special nice UX feature. And maybe this killer application will look and behave exactly the same on all platform. It would be nice if a user can pick a smartphone, a tablet or a desktop computer of any brand and just run the same application do to whatever it needs. This of course will not what platform vendors will like to see.
the nice thing of Firemonkey is the low efforts I as an Software developer have to pay to get 80 % of Android, iOS, …..; I know that there are certain limits and I wont have the full native look and feel with this approach, but I’m fast on making the first demonstrator. And I must report that some of my customers are happy with this “80% solution” , I’m paid for this but not for any further native feature /look and feel.
Ever heard about something like compiler directives?
Everybody knows the differences between Windows and Android or IOS GUIs. But you know what? -A programm isnt just about GUIs – usually there is a much bigger codebase behind that GUI stuff. The only function of this article is to run firemonkey down. Otherwise you wont spread lies while saying “fundamentally wrong”.
I simply don’t agree. I think it is a great alternative for making something really multiplatform. No matter what platform you’d choose, it would behave the same. And that’s the goal that was achieved. Using API is ok, but API is different on every platform. And FireMonkey gathers it all together to one code. If you don’t understand the idea, maybe you shouldn’t be using Delphi at all. Because it always was about it.
I agree with Ben Wittman. FM is a great idear of unified development and if Embarcadero continues with the effort they put, many companies and developper will focus on making it better with components and other stuff. Any beginning is time for tribulation but to be firm and moving inspire faith. We are waiting XE7 and we know it will have greater impact then Delpgi7.
Just one word about Fiemonkey’s lovers. Dragging, Dropping and Doube-Clicking are user kinda things. Stop being an user and become a real programmer… Or a coder if you’d prefer.
you still did not get the point
I’m a programmer…
And, I’m a photographer.
So, let me tell you a story about photography.
A camera usually has manual modes and auto modes.
An ocasional photographer generally uses one of the auto modes, because he does not know how to use manual modes, and is aware of his limitation.
A professional photographer will know which mode to use in each situation. He does know there is a time to use auto, and a time to use manual. He will know a manual mode does give him the ability to make the best photo, but in some cases, the auto mode will give him the ability to take the possible photo.
He will choose accordingly and will get the best work done.
An enthusiast photographer, however, will often know how to use the manual modes. But he will also often think that manual modes are the only way to make the best photo.
In even worse scenarios, sometimes he will not know how to use manual modes, but in his eager to be a pro, he will use them nonetheless. He will use in in-camera photometer to adjust the exposure to what the camera says it’s best, and will make the photo thinking his a pro for using manual modes.
Well, he’s not. His just a guy who’s poorly using tools he doesn’t understand trying to be something he’s not.
Using a manual mode and relying on the built-in photometer is exactly the same as using the auto mode.
The only difference is he’s wasting time, and that fantastic one time moment is gone by the time he set’s the camera up.
Programming is much the same.
Yes, ocasional programmers will love the click-click of a RAD IDE.
Yes, the pro programmers will use all tools available in order to get the best work done, without pre-conceptions about who should use what.
And yes, there are other programmers who will always think the best way is the one they think is best, without ever trying to gasp the big picture; and miss opportunities while doing it.
So…
Which one are you?
This is my opion Sebastian:- FireMonkey is an indespensible tool for developers working in a new dynamic mobile environment(the quicker a quality app is developed and the wider it is distributed internationally, the easier to fix bugs and redeploy – one code base, one team! the better for the company):
Major Features of FireMonkey
Cross-platform abstraction layer for OS features like windows, menus, timers, and dialogs
2D and 3D graphics
Powerful vector engine (like Adobe Flash or Microsoft WPF)
Fast real-time anti-aliased vector graphics; resolution independent, with alpha blending and gradients
WYSIWYG designer and property editors
Advanced GUI engine – window, button, textbox, numberbox, memo, anglebox, list box, and more
Advanced skinning engine based on vector graphics styles with sample style themes
Shape primitives for 2D graphics along with a built-in set of brushes, pens, geometries, and transforms
Advanced animations calculated in background thread; easy to use and accurate, with minimal CPU usage and automatic frame rate correction
Bitmap effects rendered in software, including drop shadows and blurring
Flexible layouts and compositing of shapes and other controls
Layered forms, Unicode-enabled
JPEG, PNG, TIFF, and GIF format read/write support
Multi-language engine, editor and examples
(source: http://docwiki.embarcadero.com/RADStudio/XE6/en/FireMonkey_Application_Platform)
Yes Firemonkey is another Ninja on the rise.
by Bernard Sibanda
I think Firemonkey is still in its infancy and over time will mature. I have used Delphi going on 14 years. Trust me when I started using Firemonkey I was pulling my hair out left and right and ranting and raving to no small degree. I felt that I was going backwards, but the more I used Firemonkey the more I grew to be comfortable with it. Sure, it is not the answer but it is a good step in the direction of developing applications for the “mobile world”.
The bottom line is that this experience has made me a better developer in many degrees. It forced me to go back to school. I think I got “too” comfortable.
I agree with you. The framework is growing including new classes and classes are expanding more deeply including new functions. Notice that each class/function must incapsulate 3 times the hosting system functions, and … i hope as soon … 4 times with linux (but now only just server, probably a webbroker oriented architecture for REST and web development stand alone or in junction with apache)
As many others have pointed out the Visual Studio “suffers” of the same “problem”. I’s up to programmer to develop better code. I have rewritten a small application made with Titanium Studio in two days with Appmethod, the original took two weeks. Never would have started to code with Titanium if I was aware of Appmethod. It’s true RAD and delivers what it promises.
The author’s opinions and arguments are wrong at all. Sorry man, but you can code CleanCode with Delphi and FM too. Your preconceptions about coding with Delphi are so wrong. Yes you can produce bad architecture with Delphi but this is not a Delphi problem. The problem sits behind the keyboard.
If you really don’t know Delphi and FMX: simply shut up and keep on coding your stuff like you wants. But I really cannot accept the bashing of Delphi and FM here.
Who the fuck I am? A Pro-Software-Developer for more than 15 Years. And yes, I know what CleanCode is and I also know other things like Delphi. Most of my time I code other stacks than Delphi. But I love Delphi a lot! For good reasons.
More recently, I have used every version of RAD Studio/FireMonkey since XE2 and it is improving, and the pace of its improvement has picked up since the date of the original post. Its documentation is also improving. I disagree with the author’s assessment that FMX is fundamentally wrong. RAD Studio/FMX is a very productive tool that especially makes sense for Enterprises in need of a more consistent mobile platform for deployment. It is possible to access platform specific API’s and fine-tune the GUI that I personally prefer to avoid whenever possible. However, in the Business World it is generally more important to keep development costs low, and get from point A to B as fast as possible, and this is one of the areas where RAD Studio truly shines.
I gave up on firemonkey but also the bugs that it does contain and just get fixed in next releases which forces you to buy a new version (absurd!).
– firemonkey is slow as IDE but also slow as building/compiling;
– firemonkey: if u see the coverflow example, it’s one huge meshed up code, all kind of issues in it. How can they call it a demo? (absurd!).
– new versions: just minor updates which is not worth couple of 100 dollars.
– how about new iOS/OSX releases and support: buy every have year a new rad studio/delphi version? that does drill yourpocket;
– productive: it is not when you find out how powerfull xcode/objective C has become; all the tools are there, hardly need for add-ons;
– it’s cheaper to do some training for xcode and create native components instead of using ugly full of bugs rendered firemonkey components;
The tone of the article seems to be focused on UX and that, supposedly, Delphi apps build with Firemonkey don’t leverage the look and feel of the device. And, it also seems to be focused on the RAD approach that Delphi originally promoted.
First, I was not a big fan of Firemonkey when it first came out. It was difficult to use and full of bugs. But, we are now at XE7 – and, it’s come a long way. Having grown up on the VCL, writing apps using FMX is just as easy. Writing components for FMX is a bit more involved than the VCL. Still, the theming and styles coupled with the multi-device designer enables developers to customize their UI per device. The provided premium styles provided with the product make it easy to create a Windows, OSX, iOS or Android application with native look and feel. Or, once can tweak a style or create their own. It’s quite powerful, actually.
As for the design methodology, it is clear that the author wants to promote MVC and seems to think that Delphi is simply about the default double-click event handlers that reside in the form file. ANY Delphi developer worth listening to knows that this pattern is only suitable for a quick prototype or very small application. ANY Delphi developer worth their salt knows how to decouple the business logic from the UI. And, most will implement an MVC architecture simple because it’s easier to maintain. And, most know the correct design pattern to use is based on the problem domain and will choose the correct one appropriately.
The use of default event handlers in the form file is not encouraged. And, it’s just as easy to create the same sort of crappy code in the author’s beloved .NET environments.
The downside of FMX is that early versions were slow and buggy. Embarcadero has taken great strides in improving the frameworks. It still is a bit overwhelming at times and there is limited material by subject matter experts detailing the nuances. There was one FMX book…I think it was the original FMX. Nothing since. Then again, this is the story of Delphi these days – there are no new books out there because the market for them is too small for most publishers.
Native components? I know of the D.P.F. frameworks, free and open source that provide native components for iOS and Android. iCL and mCL from TMSSoftware address the native issue on iOS and OSX respectively while remaining FMX compatible.
So, who go tit completely wrong? The original author.
Hi, because I am a newby and absolute beginner on FMX (I just worked making ‘console’ applications and some demons using the core level of Firemonkey portable Framework) I read about the components for both ios and android (now I’m still stuck on delphi XE4 but moving to XE7 starting with trial). This is the project D.P.F. that i found http://sourceforge.net/projects/dpfdelphiios/ is there another link for delphi android? 🙂 Thanks.
you’re so wrong too. if a good developer wants, he/she may separate screen from business logic by units, folders, etc.
I too think that native controls, etc. should be part of firemonkey also for the desktop (not just for mobile platforms like in XE7, which is a good start though).
However, if your arguments would be true for any application, Adobe would have to be dead already (their UI looks the same on OSX and Windows)…
The idea of having one IDE and code base across platforms is good – if it worked as expected.
Problem is Firemonkey even in XE7 is so buggy and problematic, that it can take a project down, even a company down. Graphics are too slow, many many things are not implemented or have severe bugs. Firemonkey XE7 cannot be used for anything involving drawing, gaming etc – only very basic and simple apps can be developed.
XE7 is a prototype, not even a beta. If you happen to code in C++, documentation is 90% absent, after days of research of how to do a simple task, you finally get the message “not implemented”. They have made it so difficult to change font colors and background colors at run time, that you almost suspect they have done their very best to make it as impossible as possible for you to make apps.
So I say Firemonkey is ready for commercial use in 3-4 years from now.
I have a strong need for a 100% professional dev environment. I need fast graphics, pdf rendering, high level xml, cross story. FMX does not fulfill that in any way. I am using Qt now. A very smooth and excellent framework.
Your main criticism is about RAD.
But you can use RAD to build the UI, not the logic.
You could follow the clean code patterns, even write a full DDD application using Delphi, e.g. with our Open Source mORMot framework for Delphi or FreePascal – http://mormot.net
And still building the UI with FireMonkey would be much productive than VS or XCode.
I built WCF/WPF/MonoTouch/MonoDroid services and applications for years, and I can tell you than a Delphi solution is faster to develop, deploy and run.
I agree with what berkant said – “You argument is fundemantally wrong is every aspect.” When you start with flawed arguments the conclusion ends up as such.I dont know what exactly you mean by “…They are fundamentally different in how the control flow in applications is expected from the user.” Mind explaining ?
“And still building the UI with FireMonkey would be much productive than VS or XCode.”
That is only if Firemonkey works, it is documented, the features you need are there, and most important that it is reliable.
None of the above is unfortunately in place with XE7, having spend 2 months just to conclude had I started in another IDE, I would have been finished long time ago with a fairly simple App I have coded already in other environment. Indy still not reliable, a simple task as a Tcp Client is not working at all. Forget anything about DB, fast graphics – and forget about use it for commercial use.
Many severe compiler bugs, even string compare is with bug, loop parameters too.
But look forward to XE15, which should hopefully be a release version of Firemonkey – not a prototype.
Sounds to me like this author has sour grapes. There is NO better IDE than rad studio. Sure if you are making rocket scientist software then by all means use VC or ASM if you are really geeky.
I am soooo unsure if I should port my VCL application to firemonkey. Is it really that bad or is it actually usable witout lots of workarounds?!
@Jansen
>”Indy still not reliable, a simple task as a Tcp Client is not working at all.”
What exactly does not work? TIdTCPClient is working. You probably just don’t know how to use it.
>”Many severe compiler bugs, even string compare is with bug, loop parameters too.”
What? Source please. I hear this first time.
i read your acticle carefully and get it that your point here is all about: “Every platform has its specifics”. I’m fine with that too by the way.
so using that premisse you agree that java does the same thing? it encourges the developers to write once and compile everywhere without the need to addapt anything to the target plataform.
just to mention, i don’t use firemonkey, i’m not here to defend or attack each plataform.
Many good points in the article. However, I personally don’t see anything wrong with “double click and write code”.Customers don’t really care. They only care about whether the app works and looks good.
Your can still separate UI and business logic with units (some form of “MVC”).
This argument is flawed in that the majority of customers don’t “choose” their platform, inasmuch as they are even aware of what the platform (most Windows and mobile users would stare blankly at you if you talked about platforms). They probably wasted their money on a power-hungry iPhone because the box was pretty. Who cares. Firemonkey (ike Delphi, like VS like .NET) has its flaws, quirks and limitations. But the ability to target multiple platforms from one code-base is *very* cool. Its up to the developer to take care to modify behaviour to match the platform (if that’s even required at all).
The main issue is not whether one likes the approach or not – the approach is great – main issue is whether Firemonkey is ready for commercial or not – and I say NOT, after 7 months with Firemonkey XE7 and now XE8.
Having used Rad Studio since the Borland days almost every day – I took the chance back in November 2014 to make an app in Firemonkey. and I cant recommend this to others, unless they are fully aware of the risk involved using Firemonkey at this state. You need as a minimum to be super user of Rad Studio.
Firemonkey XE8 is full of severe problems and bugs – apart from the very very slow graphics, which makes Firemonkey impossible for anything involving graphics or speed, there are countless bugs which I have spend many hours to try work around. Some bugs cant be solved by a workaround, others not – and you have to live without them, and hope they will be be solved/included some time in the future – XE10, or XE11, or XE12.
A common bug is components not repainting, some may repaint, some dont, no matter which tricks in the book is used for for a repaint of a text label, button etc.
Other problem is “out of memory” messages, compiler crash, very slow and buggy scroll boxes.
Documentation is incomplete or non-existing.
I say they need at least 5 years to make Firemonkey ready for commercial use.
Firemonkey XE8 is for very simple applications, non-critical and non-enterprise.
I say – Embarcadero has to rewrite Firemonkey completely in terms of graphics, the present approach is not the right one, whatsoever the present approach is. Especially for Android, and probably also for iOS.
To those from Embarcadero I will put the following questions:
1) How and when are you going to provide Firemonkey with sufficiently performing graphics for Android an iOS ?
2) When are you going to solve the problems of controls not updating, even when forced update using “Refresh”, “Repaint”, show/hide etc?
3) When are you going to provide bug-free and fast Scroll Boxes having the same performance both when at the top and bottom of the index ?
4) When are you going to provide an IDE which dosnt crash all the time ( minor problem compared to above) ?
5) When are you going to provide a proper documentation, with examples, also in C++ ?
6) Why is Android OS alerting the app has access to automatically perform phone calls during install of the app, even no functionality is present in the app to perform automated phone calls ?
The above questions are very basic and just “scratching the surface” – to go deeper would probably require books.
Problem is, not even the basics are working.
Firemonkey is an experimental IDE, and should be marketed as “experimental”.
For me the most important things are: Performance, look and feel, time to market, learning curve, development effort.
So for me, they have a good score on almost all this aspects.
Performance is key – after 10 months of development, we now have concluded that Firemonkey cant unfortunately be used for anything else than Windows and probably MAC. The response time on Android is simply to slow, or the app dosnt react at all on a simple button push.
So we will now ask a team to clone what we have made in Firemonkey to another development environment in order to have a performing app for Android and iPhone.
Just completing a firemonkey app. Delphi Seatle.
Learnt quickly NOT to use the skins as they really slow things down.
Made good use of TRectangle to provide most of the “themed/colored” container stuff (like VCL panels).
The app talks to our database via RealThinClient components is is quite fast.
Very happy with the platform so far.
About the Delphi’s Programmers behavior I would say that the only issue are for those who started programming by themselves and did not go to any programming school. I used to code in Delphi like you said, only using code directly into the component’s events. But that was ten years ago, and now I have a IT degree and I code my own classes and objects separated from the form unit.
About FMX I would say it is going up on every year. I would like that Embarcadero fixed some priorities like Windows Phone and the final size of the Android Apk Files. But excluding that, I think they are going in the right direction, they now have a visual editor that separates temples for every platform the developer wants to have with, REAL native visual.
I don’t know why developers from other platforms and languages care so much about criticizing Delphi.
But thanks for care anyway!
You said the business logic behind buttons are fundamentally wrong! Couldn’t agree with that more!
… But that is how Delphi was designed and worked, Microsoft .NET Web forms worked, Windows worked.. and well, any other RAD tool worked. But is up to the person in front of the programming keyboard to decide what the code behind should do, no RAD or any other development tool can make that decision for you. So I don’t see why Fire monkey is worse than any Microsoft product for that matter. I feel that your “opinions” in this article are way too skewed to have any value for the community. Sorry!
As a programmer all I care about is if I design a GUI on Fire Monkey form designer following its guidelines, it should work the same way in all the platforms they support, without me jumping through the hoops to get it right.
It is a general problem for Embarcadero and the Rad Studio, that they keep changing compilers, the components, they havnt been in a stable version since Borland C++ Builder 2006.
Having used now 1 year making an app with Firemonkey, it is still too slow, actually now slower than before, 15 times slower than it should be. A data crunch which takes 10 seconds on a 1.2 GHz Windows machine, takes 150 seconds on an Android Device. Thats 15 times slower, which explains why the Firemonkey apps are that slow in response.
I think they are cross compiling the code into a scripting language, this is the only explanation for a x15 slower performance.
On top of that, about everything except the raw program code you write if “dirty programming”, changed from version to version. There is no connectivity which can be used reliably and with predictable behaviour; database, database drivers, TCP connections, everything having to do with data snap etc etc.
The good old problem of missing graphics continue – they have made a new Windows 10 styleset, but it is full of bugs – TSpinEdit miss the right border, text is always to the left and look stupid.There are no button icons for Windows, you have to make them your self.
Embarcadero say this is for enterprises – no it is no – no enterprise would accept to upgrade every 6 months – but the amateurs at Embarcadero do not know that enterprises test an application before it is released for more than 6 months ! We made a test of the new Seattle C++ Builder, our application which runs fine in XE8 now freeze randomly – WE DO NOT HAVE THE TIME TO TEST EVERY 6 MONTHS !
So all in all, Rad Studio is crap, dirty programming, unreliable and unpredictable – and we are unfortunately stuck with it.
A hint to other users of Rad Studio from Embarcadero, is to use DLL´s made in Visual Studio for all connectivities, including reading and writing files as this is also unreliable and unpredictable in Rad Studio.
This is unfortunately no a walk around for MAXC, Android and iOS. For these devices, if you absolutely must do it in Firemonkey, to keep it as simple as possible, using only Indy HTTP connection to communicate – it is fairly reliable.
@Jansen –
Are you a regular crack smoker? I can’t imagine that one could disparage the reputation for Turbo Pascal/Borland Pascal/Object Pascal’s ability to perform file I/O??? For goodness sake, these products have been used to develop flat file database systems dating back to ’83.
You remind me of a bloke I had the misfortune of coming across several years ago. My company was switching from Interbase to M$ SQL Server. Several of us were sent to a SQL Server version launch presentation, primarily because all attendees would get a free(?) licensed copy of the product.
The presenter actually started off his presentation by loudly asking the audience, ‘Is anyone still using Pascal??’, in a hugely mocking tone of course. Quickly seizing the initiative, I threw my hands up in the air, jumped up and down and yelled ‘YEAH! YES! WHOOO HOOO DELPHI’! Completely took the starch out of this arrogant idiot’s presentation.
This article may have made some valid points, but clearly this is far from a professional s/w developers blog. M$ groupies, apparently.
@Decoder – I have used BCB since the early days of Version 4, about 15 years ago. Much has happened since BCB 6, where Code Gear and then Embarcadero began to rewrite all the code behind BCB. BCB has not been in a stable and reliable version since BCB 6, they are constantly changing the source code, the compiler – access to a Memory Page in XE8 dosnt work any more in XE10, etc etc.
There are so many problems with BCB access to about anything; files, database, networks – functionality is unpredictable and unreliable. BUT – this can be overcome by using VS DLL´s, or simply use a Http CGI call to something which works reliable.
We gave Firemonkey a last try the past month, as the idea and concept is in general solving a lot of problems in terms having the same code base across the 4 major OS.
So we did the following – as the app for Androd did crash in XE10 on or/and after install – not in XE8, plus speed problems, problems with gestures not working, bugs in Style Pages .. you name it:
1) First we tried to replace the TabControl with TRectangles, but this made it even slower. Then we replaced all TPanels, TButtons with TRectangles. That made the trick, the app didnt crash any more.
We are now using our own “Buttons” implemented with TRectAngle, a TLabel and if necersary a TImage, and a timer.
2) All communication with the outside world is done by using Indy Http calls to a native C/C++ CGI; we have made a custom API where the interface is a CGI.
3) Trying to connect to Amazon Dynamo DB did as expected not work – so we will use a CGI to make the calls to the Dynamo DB.
4) We are using a TabControl as the base of the app – we place a TRectangle on top of the Tabs so we cannot see the tabs of the TabControl. A TToolBar cannot be used.
5) We have made our own gesture swipe functions, using MouseDown, MouseUp and MouseMove plus a timer to implement the swipe gestures. Since the Firemonkey gestures are unreliable. When swiping, we simply change the TabItem -this works perfectly, one cannot see this is actually a TabControl changing to another Tabitem.
6) For resizing and rotation, we use the OnResize of the TabControl – where we have a function for Horizontal and for Portrait. We arrange every simple TRectangle, label, button in this function. We use always then default scale 1:1, not zoom etc. This works perfectly across all screen sizes, resolutions, rotations. No need to size labels panels etc – for some reason they get the right size independentlty of screen resolution. Font size on text labels need to be set at run time in Android, since there is a bug – text labels get too big in Android.
7) On Android, we do not use the splash screen – but a second TForm with a picture only which is closed and the main form is shown when the app is booted.
The above solves the problems, we implement all graphics as custom – we can thereby change graphics theme at runtime, looking the way we want, since the biggest problem in FM is graphics can not be changed, or it is so difficult that better to make all your self, using TRectangles, labels and timers.
The BCB SpinEit is useless, for this we have decided to use the TMS Software Spinner. Once again TMS Software solves fundamental problems in BCB.
So we now have a quite well performing app, flying on a Sony Xperia C4, acceptable on a low end Chinese phone,we are in full control of the graphics and not dependent of FM bugs. Time works for Firemonkey, with more cores and higher processors clocks, graphics processor becomming standard. Which makes Firemonkey a preferred choice for app development.
Surely you bet by doubleclick a default method where you enter your code, and a beginner will
shurely be tempted to do so in more sophisticated situations ( for simple tests or situations i think it is ok, for a simple test you dont have to construct a mvc environment ).
But i think a skilled beginner will notice very fast that in bigger projects this is a little to simple approach, and then i cant see a bareer which will hemper him to code with another aproach, as is eg. mvc.