after extensive research of dataabstract and related products (SDK, oxygene) i need to decide what to choose.
There is many points of view that we can discuss. In that post I wish to compare Delphi/Firemonkey/DataSnap (DFD) concept with Oxygene/Dataabstract (OD) concept.
In our case we must develop middle layer app server that support as many as possible clients.
So both concepts (DFD and OD) can be used. But which one is better and more prepared for future delphi versions ?
I know that dataabstract is much much more powerfull than datasnap.
But …
With firemonkey i can create almost same GUI on all important clients (Win, iOS, Anroid nad Windows 8).
Most of them are native compiled or will be in the future (XE3…).
DataSnap connectors will work on all clients and should connect to datasnap server.
In OD concept i can use oxygen and implement same sever on different platforms.
All important clients are supported. But I need to create GUI for all clients particulary.
For GUI i need to know particulary GUI classes (components/controls).
And finaly… Can i move RO server to cloud ?
So. Please comment and help me to decide. Any pros or contr. are welcome
sebit said: With firemonkey i can create almost same GUI on all important clients (Win, iOS, Anroid nad Windows 8).
for one: just because you CAN, doesn’t mean you should. using a common UI between Windows and iOS, say, is a terrible idea.
for another, if you do decide to go for FireMonkey, DA fully supports that as well, of course.
sebit said: Most of them are native compiled or will be in the future (XE3...).
for certain definitions of native, yes. FireMonkey apps will not be native apps on iOS, they will use badly mimicked UI controls. Dito for Mac, Android, and Windows 8 Metro (if and when those last two get supported by FireMonkey).
for truly native APPs, you will want to use Cocoa, on iOS; Java (or Oxygene for Java) on Android, and .NET or C++ on Metro. Data Abstract of course supports you on all of these (with DA/Java being in “very usable beta” as of this week).
sebit said: And finaly... Can i move RO server to cloud ?
depends on your definition of Cloud, but yes. You can run RO/DA servers, for example, on EC2, Azure, and many other cloud platforms. We ourselves run lots of services on EC2.
@Mh: “if you do decide to go for FireMonkey, DA fully supports that as well, of course.”
In other words: I take RO/DA for Delphi to create server and client with firemomkey GUI and live binding. Then I compile it to MAC OS and everythink works fine. Is this correct ?
If so then RODA client classes are platform independent. Agree ?
sebit said: In other words: I take RO/DA for Delphi to create server and client with firemomkey GUI and live binding. Then I compile it to MAC OS and everythink works fine. Is this correct ?
yes, DA/Delphi client components will run fine on Mac, with Delphi XE2
sebit said: Will DA/Delphi run on IOS and Android if Delphi XE?
Delphi XE doesn’t support Android or iOS. Neither does XE2, except for a weird hack that uses Free Pascal to build for iOS.
From what i understand, iOS support in the Delphi compiler is planned for XE3, and Android support is planned for a later release. Rumor has it, this won’t quite be the Delphi people know. But we’ll be testing with that as soon as we ge the chance, and we’ll have information on iOS and Android support in DA/Delphi once support for those two platforms in Delphi is a reality. We certainly intend to support DA/Delphi everywhere that Delphi is supported, if possible.
In the mean time, we do have native platform support for iOS and Android dia DA/Xcode and DA/Java., of course.
sebit said: Will be Oxygen for java included too ?
No, Oxygene for Java is available separately from us, only. Embarcadero has not shown any interest in it. We do have special upgrade/crossgrade pricing if you have Prism, so send us a mail to sales@, if you are interested.
sebit said: Do you have any informations how Android support will be implemented ?
i’m not sure what you are asking. Oxygene for Java has full native Android support, now. i cannot comment on Embarcadero’s plans for Android in a future version of Delphi.
I’ve never seen any point to doing that though and their statements lead me to believe it’s a waste of time:
“Using native code does not result in an automatic performance increase, but always increases application complexity. If you have not run into any limitations using the Android framework APIs, you probably do not need the NDK.”
Sounds to me like having Oxygene compiling to Java bytecode is the best solution. Or Perhaps that’s the method they’ll try for Delphi, though. I once read that they demonstrated a Delphi => Java bytecode compiler at a BorCon years ago. In any case, they aren’t talking…
With Android implementation i have in mind Embarcadero’s.
@Ron:
From Android point of view i agree with you. Why use low lovel programming (ARM) if we could use java in java Dalvik VM as native environment for Android. Like RO does.
What if sometime there will be Android implementation on non ARM processor.
RO project will still running. Embarcadero’s won’t.
Ron_Grove said: I've never seen any point to doing that though and their statements lead me to believe it's a waste of time
yep, that's my thinking, too, and i just love that quote from the Android SDK page; i'm seriously considering making that a center stage of our Cooper marketing ;).
i do believe/expect Embarcadero’s way will be to go for the unmanaged, straight ARM code. i.e. what they call “native”. we’ll see how that works out…
sebit said: [Oxygene] project will still running. Embarcadero's won't.