The repository is ready. Marc, tell me how will we manage subscriptions, they will send you an email?
Donald: for one, let me remind you that the idea is to for this to be repo for everyone to get access to. The idea is that this is a place for you and a select few to work on this. For people who want to have access, please coordinate with them, and then you please send me their github.com account name and remobjects.com account name, per email.
Michael: âDoes RO/DA include the RO/SDK on the server side too, in the context of that statement? Or did you talk about the DA option. Question then. Are you considering to move the Relativity Server to the JVM?â
iâm not sure what you are asking here? RO/DA Delphi is client and server. Does server support make sense on mobile? no, not imho. i;d assume Donaldâs project would probably be for getting RO/DA client to work on Delphi/Mobile, not server. Who wants to host a middle tier server on their phone? 
Marc - No. The relativity server as it is just on the JVM. No need on a mobile device. JDBC level 4 drivers. Thatâs why I am really happy about Oxygene on the JVM. Scope - not today not tomorrow, maybe the days after tomorrow.
I cannot say that even under Windows I didi experience trade-offs concerning speed, but I cannot really test at high load.
- They have also made it very clear that they donât want us supporting RO/DA on
- Delphi, at all.
I was just asking. Is this about RO-SDK and DA or DA only?. I do not assume they talked about Delphi mobile only.
Donald - I cannot comment on XE5 Mobile. I can only say that XE5 imo works better than XE3 and is more responsive than XE4. I will wait with the mobile stuff on Delphi. Honestly I expected the data-snap to improve first, which would have been more wise 3 years ago. I do neither have a pure RO Server on Delphi or decided for DataAbstract. It just came into my mind that also RO-SDK severs could be hurt by EMBs âwishâ. On VB developer - I donât care about GUIs - not more than just in fashion of building a nice GUI with devexpress VCL components, in most case serving my personal decent purposes. The FMX in general is another story (the OS/X part). For some visualization itâs helpful but in my case I can live WPF for that since there is no heavy manual input involved.
I was very surprised to hear Marcâs words on what EMB made clear. That matches two other observations I made over the last year. Then there is a tendency to get rid of anything/anyone else except for the GUI. Maybe just because to be in the position to sell more Enterprise licences. Thatâs my concern.
@marc ok, so you donât want i promote the repo on my blog to attract more coders on this?
"i;d assume Donaldâs project would probably be for getting RO/DA client to work on Delphi/Mobile, not server. " Yes exactly that is the idea.
Best regards.
Michael: right now we have no plans for additional DA/Server platforms. DA/.NET and Relativity (which uses DA/.NET) is where out focus is for the (DA) server, for the future. We are looking into supporting RO servers on more platforms (most prominently Java, maybe Cocoa) in the future (but no timeline, probably second half next year, at the earliest).
âThey have also made it very clear that they donât want us supporting RO/DA on Delphi, at all.â â I cannot really go into details, but i can tell you that Embarcadero does not like professional networking and database technology to be available to delphi users who did not buy Enterprise. At one stage, we were encouraged/asked to make Data Abstract âbuilt on DataSnapâ, in order to force people to buy Delphi/Enterprise to use it. I imagine i donât have to describe what our reaction was, and how far across Berlin my laughter could be heard.
As for DataSnap â i have heard rumors (not from anyone at Embarcadero directly, only via secondary sources, mind you) that DataSnap is being discontinued/replaced. No comment on that, aside from that i assume that is awesome news for everybody who bet on Embarcaderoâs âmulti-tierâ strategy.
@marc for sure DataSnap can be compared to RO/DA. Another additional reason to get working delphi mobile client with RO/DA .
P.S. I dont know why or when but quote stop working at all. Im using safari latest version.
Thank you, Marc. No need for another platform. I can confirm that âOxygeneâ on JVM works for me together with JDBC. I always go bottom up and look for the one or other advantage that could be gained. I donât have the overall picture you have. I see DA and Relativity as progress. I am not here to suggest additional features.
Thank you for clarification. The only thing I have heard that there is no intention to acquire anything else. (status a few months/ not a year ago). That led me to the conclusion that there are 2 options left. When I quit from RAD Studio Enterprise I let EMB know that together with the (Sender AS) SDK a cheaper solution can be found if you have the life time license. A few days later the option went away. I donât know if there is any relation.
Donât get me wrong. From a tool vendors perspective it does make lots of sense if customers choose for the more âcapableâ edition. Because the code is ready to deploy to a few hundred or a few thousand or any number.
/*
In the 90s there was a saying about tools/âtechnologiesâ, when people complained. Be happy, the day things are finished you must start to look for the replacement. Either things became crappy or expensive.
*/
The edition must be more capable. Between an AnyDAC in disconnected mode (Windows*)) having the âpseudo middle/tierâ business logic stored in DB procedures and the no discussion - we cannot risk to use anything but what the technology vendors (the huge) do offer - enterprise league there is a huge gap. This gap cannot be filled by one add-on to Delphi. EMB would have to build a second company at the size of EMB around that add-on. The argument - we write Enterprise on a box and anything that competes to what we think we offer should only be allowed to be used together with that box is strange. Dependent on discontinuing or replacing the data snap Delphi is the last C/S tool, which is a niche indeed (@Donald - joke). EMB will invent something different, I am pretty sure. This trick does not work on a Smartphone (there is polling involved iirc). AnyDAC simply checks - is there activity on the GUI and closes the connection.
If I think of Android and polling queues for messages ⌠thatâs cumbersome. You have the events. Maybe it can make sense if you extend the RO-SDK into the direction of a push notification kind of service hosted on the server instead of the super channel. I am not sure if that helps or is can be unified so simple on iOS/Android.
Just to give some news. The repo is loaded , im testing with AnsiString options to get a build working with NextGen compiler.
Hi, great news again!
The glorious Andy get working strings on XE5 mobile (Nextgen).
http://andy.jgknet.de/blog/2013/10/the-return-of-the-byte-strings/
We are closest of a final solution. I will test libraries tonight and let you know.
Best regards.
Fantastic stuff! Great work! 
Again, more news. After a lot of revision i see this will take a lot of time and effort and the success is not guarantee. I have not the enough time right now-
OTOH, i try some work with fire monkey and im impressed for the slowness and unstable it is, right now. Can be that be improved in a future? I donât know, but right now is only suitable fro prototypes in my humble opinion.
I will start working tomorrow with Oxygene for a Android project i need asap. Im not sure how much stable is oxygene in a real project but i will do my best effort and with the help of another oxygen users maybe get it working soon.
Best regards.
P.S. In any case, Ro translation to delphi mobile is dead.
Following the tests, i find the faulty component is tab control. I replace for other and now it âjust worksâ using fire monkey. Now im in process of test how stable is because i need this running in kiosk mode 24x7.
I have to add a datasnap server.
Thank you for the update. Keep us posted whenever you can.
Very sad, continue to use RO?
Im trying to use Delphi RO server and get the SOAP message into my Delphi Mobile client. The problem right now is the WSDL generated by RO Delphi Server is not compatible with Delphi for some reason.
RO developers team are working in find the problem, i hope they will soon.
In that way, i can use RO Delphi server as any other web service only, not the full functionality we can use on any Delphi RO Client, but is something i guessâŚ
Best regards.
FireMonkey (iOS and Android) very good, very fast development of mobile clients, the most important is a cross-platform source code, I hope RO able to change plans
I want to share with anybody following this topic my experience,
First, i want to say will not put any effort on this project. Sorry, but theres many reasons to abort this now.
At the start, when i was using FM and believe is a viable platform I contact to EMB friends trying to fin help with this tasks.
The response i get was EMB will never give support to AnsiString for mobile. I ask then for steps to help with the migration to the new supported strings and they show a total lack of interest. Im talking about first line EMB people. Zero interest.
I explain my idea to allow delphi and rem objects developers and allow having more options. Is clear EMB don´t want RemObjects in the delphi markets. This is the only conclusion one can get.
Then i start using FM to develop a Android app. I already blog about that, was a pain. Unstable, lot of bugs and the final size was impressive⌠in the bad way.
For this reasons i want to avoid giving false expectation about that effort i start and be clear: i will not work anymore on the migration from rem objects library to the stupid lack of AnsiString Delphi XE5 and beyond.
Im a Delphi Enterprise SA customer and i be forced to comeback to XE2 for the amount of bugs not only with FM, also with VCL, making my 24x7x365 app unstable. Theres some post showing the XE5 compiler is not efficient and adding a lot of problems.
I start with this initiative because i believe the FM approach was better than the Oxygene approach, in terms of rad development. I understand now, after using and coding real world apps, Oxygene approach is a lot better. Yes you must to have to app, can share some code, but the final product is perfect for the platform you use. You canât say the same of FM and i think will never be the better solution.
See my blog about this if you have any doubt.
Sorry guys, i will ask to Marc to remove this repo if there nobody interested in it. Im not, i hope be clear.
Best regards.
I also began to develop ANDROID/IOS applications, use DATASNAP, there is no other better choice, really very much need to solve their own
1 Like
I try Datasnap. Thanks for the offer. i prefer to stay with Oxygene + RemObjects for all my mobile projects.
1 Like