I can’t see FMX ios as a good choice for everyone.
My delphi application will stay away from FMX, even the desktop application, and for mobile, the right choice is Oxygene, I want my legs, so no FMX 
jcarlos, you do that. But for people working with Delphi and using Delphi DA guess what will be the ideal choice to work with Mobile?
You can argue on “ideal” from your point of view, but if Delphi is setting up a full GUI designer, compiler, etc and working full time on it, it makes sense for Delphi Developers to want to continue developing with Delphi using those available features.
My RO/DA licenses will expire at the end of the year,I hope RO SDK next version to support DELPHI/IOS(FireMonkey Mobile Application)
estebanp - On maintenance mode. There is a certain truth in your words but going beyond what Data Abstract provides now does open Pandorra’s box. You can do, simply implement what you think you need. Data Abstract is a class library too. Supporting an additional framework does help no one. It’s maybe a drawback because DA does provide the same functionality via the different technologies supported. I could live with a .net only that is more capable or Java on server-side instead of Delphi.
I don’t want to interfere deeply into this discussion because it’s specifically tied to evolutions in the area of Delphi. I have no idea about Delphi for iOS, no one really could tell me, what Delphi for iOS can be used for and if it does work satisfactory, will it integrate with the server side (datasnap) in a way beneficial for both the developer and the end-user. I doubt the latter, otherwise people would not be here.
RO does support Delphi because part of Remobject’s philosophy is to combine those tools who provide the best user experience if not for both at least for the end-user on the client side. But only one technology. On the server side almost the same. So I am wondering why the bother with Delphi still. It’s a certain kind of favor to the Delphi community because of common roots or minorities are considered in democracy.
The just regular case would be. Everyone takes the data-snap and those who want to go beyond choose for Remobjects. Remobjects mission is not to compensate several Delphi owners shortcomings. Data-snap works in general somehow maybe behind an IIS. If this is not possible with Delphi + Delphi for iOS forget this option at the moment. Learn something you will need tomorrow, WPF + Winforms and X/Code Cocoa. I know about Delphi’s strength but I am concerned about the fact that almost all forces are put to the Delphi for iOS.
So what’s on the list to come according to EMB’s visions
a) Third-party vendors should support the latest version with the current update, does mean no older version of Delphi
b) Maybe the compiler changes or not. In both cases no need to start something new until cards are put on the table
c) …
I personally understand ROs decision and Marc’s statement. Delphi for iOS must boom otherwise you all will have to force the rewrite of what you have or at least flag your development as legacy. Rethink what b) does mean in practice.
Let me put in my $0.02.
I have been a Delphi developer since Delphi 1.0. I loved the product immediately. I upgraded to almost every version up until Delphi 2007, which I think is perhaps their best version ever. I didn’t like the changes that started to come out in the post-2007 versions, and I felt the product was NOT as stable as the previous versions. I did buy 2010, and even XE2 when FM first appeared. But FM did not impress me at all.
I did not like the direction Emb was taking with the product, and quite frankly when rumors of a “Delphi for Mac” surfaced, I was a bit excited. Needless to say when I saw “Delphi for Mac” was simply FM, I simply had it. At that point I made a really difficult decision and purchased Oxygene from RemObjects.
I have not looked back. Yes, there was a few weeks/months of growing pains, but the language is awesome. I still maintain Delphi apps in D7/D2007, but all new products are written in Oxygene, and when there is time, I migrate small apps over.
I’ve invested quite a bit in RO - the SDK for all platforms, Oxygene - but RO gets it right, whereas Emb (in my opinion) is taking the wrong road to what some see as the same end result.
I would strongly suggest all Delphi developers look into Oxygene and make some honest comparisons. I am quite pleased that I made the switch.
Couldn’t agree more aolson, same with us except we have kept our Delphi versions up to date so far (XE4 is the last though) for projects built with Delphi.
I agree with estebanp about Delphi appearing to be in maintenance mode - it’s the reason I didn’t renew my RO subscription last year. That, and the fact I could see the conflict of interest with EMB/FM coming. I do think though that the FM vs Oxygene choice is not as black and white as is made out. Nice work by Simon Choi and Jason Southwell demonstrated the use of FM apps with native controls and now this choice is commercially available through the TMS iCL components. So FM now lets me combine native controls with FM controls for which I can’t see a native equivalent. For example I have customers who need tablet apps with charts and grids (both iOS and Android) - how would I produce this using Oxygene?
I think Remobjects as a company are drifting into risky territory by competing with EMB and alienating many Delphi developers. The lack of iOS support for FM has pushed me into investigating other options for data access - in particular the use of ORM frameworks. I recommended RO/DA to a C# team a couple years back and they did adopt it for its cross-platform capabilities, but they did think the dataset approach to be a bit “old hat” (they were llblgen and entity framework fans). IMO Remobjects should have focussed on their core competency - data access. If they’re not careful they could find themselves in a situation where DA is seen as outmoded by ORM, and EMB make a success of FM due to its ability to mix native and FM components. Still, the competition can only be good…
I agree with estebanp and rdevine
@rdvine: I do some performance rating. Yes, using stock native controls from iCL have acceptable performance. But FMX controls have HUGE lags and HUGE performance problems (CPU=95% even on iPhone5), so using them is no-no for any app. Next, FMX have memory footprint problem (200Mb virtual memory minimum). So I can not recommend you mixing iCL with FMX controls in any case (as for FMX3).
But iCL have own problems: first is extensibility problem due to using native controls on Delphi XE4 is a pain. You can look into sources of iCL and see that all calls to native controls is “wrapped”, and you can not do any extension to ObjC class in Delphi code (poor interop with ObjC). So if you speak grids, with Delphi you will not have any custom cells, and can not do fast grids for iOS. You should use Objective-C to build your grid, then “wrap” a control to use it inside Delphi, and you should manage some interop with FMX to properly “embed” your grid into FMX app. IMHO, all of this is a pain.
So, cool and fast grid for iOS can be done via native controls with Oxygene. About charting controls for iOS/Android: its not a problem! You should use any native library with charts. On iOS you can browse CocoaControls.com for charts, or GitHub - there are some (a lot of) free/openSource charts. On Android there is a lot of charts, but i did not do many android this days, so you can google yourself.
About “DataAccess” vs “ORM”. IMHO, ORM is on top of data access, but ORM have some trade-offs like no-transparency working with data. So, if you like to have more control, you can use data access/remoting data. If you want to build fast prototype of app, ORM is cool. But ORM is poor when you forced to do some “briefcase” scenario, or if you fight with communication errors. Why poor? Because data and comm layer in ORM is isolated from your code, so you should digg into ORM to handle difficult cases. For me, ORM is cool for desktop app with permanent LAN-connectivity, or (maybe) for server. But mobile client should be crafted more precisely.
What I can see here is some users that are already using Oxygene telling us the wonders of their tool, which I respect their opinion, but has nothing to do with the users that are also happy using their own tool (Delphi) (and reason behind the post) and the continuation of development for Delphi by RO.
We are finally considering not to renew our subscription after reviewing our gains on Delphi for the last year and so. Other than a few bugs ironed out we are obviously helping to finance development on other areas which we are not getting a benefit and it seems we will not on the days to come.
Certain topics like improvement on Olympia and its redundancy (multiple instances), quasi-LINQ, built in support for structures on sessions, initialization of enumerators with different non consecutive values, (put your suggestion here) etc. were left to gain dust and we do not see any kind of Delphi road map on RO other than saying they will support the next version of Delphi, as long as it has nothing to do with the new features Delphi is bringing to the table.
We will make a decision once the Android support on Delphi shows off later this year. You can see by EMB tours, updates and material online they are investing heavily on it and it is a path we want to follow.
TMS did a great job showing how to introduce native controls on FMX and we are all certain they will improve it, which in any case was a great 1.0 release.
Hopefully we will see an update on RO’s Delphi Roadmap.
The wise bunny knows much time can be lost worrying about wolves that never appear.
Better two chicken mcnuggets than one.
Coming from Delphi XE, XE4 is looking extremely good, I will have to say a very stable, fast and reliable release. Live bindings are great and class helpers for all basic types are a blessing.
Small apps (nothing serious so far) on iOS Mobile are quite enjoyable to built, I think they have a winner. I’m hoping even more we will have RO support for the new compiler.
RemObjects SDK what time will support FireMonkey Moblie Application developer?
My RO/DA license expires in spring next year, I’ll need RO SDK support FireMonkey Moblie Application
FireMonkey Moblie Application will be support ANDROID, I’ll need RO SDK support FireMonkey Moblie Application
Any chance that RemObjects review their position in relation to XE4/5 iOS/Android support ? I really would like to have this functionality and will definitely expand a lot usage of RemObjects products (in terms of number of purchased licences). To me it looks very natural to support as many platforms as possible (and yes, I understand all technical difficulties in multi-platform support). But, hey, thats exactly what differentiate average company from great company – ability to solve problems which are not that easy to solve. And I always thought that RemObjects IS GREAT company.
Anyhow, would be great to get an official update on this issue, so we could plan our development…