How to talk to RemObject SDK Servers from Delphi Mobile (FireMonkey iOS and Android)

Remoting SDK
1

We have a several services written in C# using RemObjects SDK that I need to talk with using mobile clients written in Delphi using FireMonkey (iOS and Android). We are talking over a Super HTTP encrypted connection.

My understanding is that RemObjects has decided to not support Delphi Mobile at the moment, which is very disappointing.

Regardless of this disappointment, the real world is moving on and I still need to be able to somehow talk with our RemObjects servers so I would like to know what options there are. Suggesting Oxygene or XCode/Eclipse is pointless and will not be considered, we do not have the luxury or manpower to switch development languages and IDEs.

My initial idea is to write a separate DataSnap server that “translates” or “forwards” requests to the RemObjects servers, but this is both a ton of work and a really, really stupid way to do things. Is there ANY way I can communicate directly with the RemObjects servers?

2

The anser is no, you can´t, and yes, you must find a alternative , poor way, to connect to actual Delphi servers using Delphi mobile. The result will be you will get a subset of the cool functionality you already have on Delphi clients for Windows o OSX.

I have to say i understand the reasons for RO not following that path, but that don’t make less painful the process, don’t help to delphi users at all be here.

OTOH, as the silly Delphi user i am i really hope that situation change on the future. You are not alone with that problem, there a lot the RO and DA users there.

I dont know if that will change or what is needed to try to make RO take Delphi mobile path, so i really don’t know what to recommend to you, because i , again, I’m on the same situation freezes.

Best regards.

3

Does Delphi/Mobile support the open standard SOAP? If so, you could simply expose your servers visa both RO/Bin and via SOAP, as so called Smart Service. This way, it would would be accessible from any platform where no RO client library exists.

No need to redo or drastically change the server (beyond dropping the extra SOAP message component)

4

Thanks Marc, i will do some experiments to confirm this.

5

Yes, we can use SOAP but one of the features of our software is the RemObjects support for the SuperHTTP two-way channels, binmessage and the encryption support. We can use SOAP over HTTPS, but it will not be the same.

I hope you guys at some point would reconsider your decision, or at least support RemObjects clients in Delphi Mobile.

6

I don’t want to rule out a change of plans in the future, but i don’t see this happening any time soon. Several things would need to change, for us to copnsider supporting Delphi/Mobile:

(a) it’d need to stop being terrible
(b) it’d need to be feasible for us to maintain one (sane — ie not IFDEFs on every line) code base between Delphi Desktop (including older Delphis) and Mobile
© a significant demand from users
(d) a vague indication that it’s possibly to create decent iOS/Android apps with Delphi
(e) Embarcadero becoming a company we’d actually want to be partners and do business with, again

That’s 4 very big “ifs” and one near-impossibility.

7

LOL! That’s one very definitive NO then :slight_smile:

I’m not sure I agree with (a) and (d), at least not for the kind of apps we need to develop (very basic apps). The familiarity, ease of use and especially the UI design interfaces of RadStudio XE5 currently far outweights the cons of using it (FOR US). I am pretty confident I would be able to create apps that “doesn’t suck” using it. Learning a whole new toolchain and environment really isn’t very tempting.

I understand that (b), © and (e) is something only RemObjects can know anything about. For ©, at least you have my vote. I would like to have RemObjects clients working on Delphi Mobile.

8

Im sure (b) can be solved, many others thirdly party solve it. Can we please know the details of this? Why are so needed many ifdefs? Is the lack of Ansistring the problem or theres something else? I can work on find a solution to avoid that ifdef Marc.
Now, talking of (a) no offense , is a matter of opinion, and i can´t see how if we solve (b) the fact that tool s*ck will affect RO. You support very early beta products (like lazarus) for years. You surely can support as is Delphi mobile, again if we solve (b).

I mean, i only see a win win situation if you bring to delphi users the support to mobile solving , again , (b). Don’t you?

Maybe if we know all the problems to implement Delphi mobile we can work together to get a very descent implementation with zero impact on the main RO/DA branch. I refer to delphi/ro users, no RO stuff, you already have a lot of work, i understand this.

© has no impact on your daily work if others solve (b), right?
(d) again, is a matter of opinion and i think that is a very personal opinion, every user will make the smart election according every reality, impossible to judge that.
(e) is out of our scope, and who matters? How will that impact on your product? You already need XE5 to support Delphi standard RO/DA libraries. Why will affect you EMB is a bunch of idiots? (not sure about this… I’m just trying to made a point here).

Just my guess and thinks on this problem, because a big part of your loyalty users have, trying to help them and help me too. :wink:

Best regards.

9

I think this really has been discussed to death on other threads already.

We’re a very small company, and we have very limited resources. We already support RO/DA for FIVE different platforms/editions (at least two of which give excellent support for the mobile platforms, one native and one via Xamarin). All else being equal, would it be nice of we could offer RO on 10 more platforms? Sure. people ask for PHP or Ruby clients, for example. Is it feasible? No. Delphi/Mobile is just one of those platforms where it doesn’t make sense for us to focus our (very limited) energies.

On the technical side, yes, lack of AnsiStrings is one huge issue (not per se, none of the other platforms have AnsiStrings, but when considering that we need to keep supporting Delphi 7 and above as well, and we need to keep supporting existing user projects that use AnsiStrings). The totally fucked up and ass-backwards way that Embarcadero is making strings zero-based is also a major issue, and there are more.

As for testing early with betas: HAH! From the very get-go, Embarcadero has not allowed us beta access to either the iOS or the Android versions of Delphi. They have also made it very clear that they don’t want us supporting RO/DA on Delphi, at all. If we’d wanted to support this (and we don’t), we’d have to go and pay thru the nose to buy a copy of the over-expensive Mobile Pack, ourselves. [that part is not why we aren’t supporting this, it’s just the cherry on top].

Embarcadero being a bunch of idiots (to use your words :wink: affects us deeply, in so far that — as i mentioned before — we have very limited resources and already are spread very thin. Given that, why would we want to spend precious resources supporting a platform that (a) we don’t believe in (b) is, technically speaking, crap © is a niche within a niche, and (d) is built and sold by a company that hates its customers, and hates its partners and supporters even more — and lets them know it every chance they get. We wouldn’t. No-one would.

We’re frankly just not interested in being in business and dealing with Embarcadero any more than we are forced to — which right now is limited to two areas: (1) supporting the customers who bought RO/DA for Delphi/Windows from us over the past years, and making sure that that product lives on well and (2) on our own dime taking care of everyone who got fucked over by how Embarcadero dropped Prism after caching in on everyone’s SA renewals.

We’ll be happy when (2) has run its course sometime in the middle of next year, and we sure as hell don’t want to add a (3).

That said, if you want to work on making RO/DA build and work with Delphi/Mobile, that is fine (you can do with the source as you please, internally), and if you want to submit patches for Delphi/Mobile that are limited in scope and sane, our team will be happy to consider merging them into the core code base, where possible.

10

+1 Marc, thanks

11

Marc, thanks for your explanation. I already know some of this details, as you know, but i think is important to let the customers know in depth the situation.

Last question is , we know you allow to individuals to work on a delphi mobile version of RO/DA. But i believe it can get better and quicker if a group of people with that interest share that code. As i see, theres no way to do this, we are restricted by license. The only possible way i see is RO managing access to that group (and code) and publishing this on some GIT repository, private, only for Delphi/RO users with a RemObjects coordinator (maybe the same team leader for delphi RO product?).

Yes, i know, is more work for RO. Im just asking if this is possible, to avoid make any mistake on the use of the RO/DA source code. I believe severals developers working alone have no sense at this point.

Best regards.

12

I forget to mention, strings zero-based can be disabled (return to previous behavior) with a compiler option. Sadly we can revive AnsiString in the same way. :frowning:

Best regards.

13

As long as all people involved have a proper RO/DA license, we have no problems with people collaborating amongst each other, in a limited group, in whatever way you find work best. We’re fine, for example, with you putting the RO code in some (private!) git repository, and sharing that repository with other people working on this.

We’d not be making such a repository available ourselves; sorting this out would be between you and your fellow contributors.

Just make sure that everyone involved has a license, and that the git repository is not made available publicly (or “globally”). IOW, we’d not be fine with some “any RO user anywhere, just email me to get access to this” arrangement. RO is not an open source project. This would be for a select handful of people to collaborate on this, with the intent of using this themselves and/or seeing what level of changes could eventually be submitted back to us, only).

Does that make sense?

14

That have sense. I will implement this and ask you via private mail for every request, to confirm. One time is implemented i will post details here.

Thanks, as always, for your pro active attitude. :slight_smile:

15

Marc, see theres no free options for private git repo. Theres any way to implement this on remobjects server? Jut let me know, if theres no way i will pay a subscription on some site.

Best regards.

16

Cool. Please invite me and Eugene to your repo, too. (git preferred :wink:

17

Sorry for ask again, may we put that repo on remobjects servers? That way your team can control who access to the source code. Let me know or i will subscribe to some payed service (or mount on some own server, but we don’t have a git server on our public servers right now)

Best regards.

18

I can set up a private repo on github tomorrow.

19

Thanks Marc!

20

This sounds encouraging. Like Tom above, I simply don’t have the resource to move to something like Oxygene - Delphi mobile will be “good enough” for my requirements. I’ve been using RO/DA for 9 years now - with a large codebase - and the prospect of having to move to something like OData instead is pretty depressing.

One question though - will you need to have an active subscription to get access to this repo? Not trolling here Marc, but the Delphi version looks to me to be in maintenance mode and it’s hard to justify continuing a subscription (I let mine lapse a year ago). Then there’s the associated point of which version will be branched - or will the aim be to roll any mobile related changes into each official update?

It might also be worth considering generating diffs - which would obviously only be of use to those with the source code.

Bob