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

Remoting SDK
21

I’ve been using the weekend to evaluate Delphi Mobile and to some extent Oxygene to see how much effort it would take to get the apps up and running on both iOS and Android. Our app needs are very basic, report a status and location to our RemObjects server for resources out in the field (personell/equipment). It’s like a login call, report position & status, logout. Very basic.

I was able to create both iOS and Android versions of this in a few hours using Delphi Mobile and a simple Datasnap server that translated the report location calls to our RemObjects server, but the process was buggy as hell and felt like it could implode at any second. I also had a hard time getting the look of the application “right” using Delphi Mobile, I needed some colored buttons for the various statuses and couldn’t figure out how to do that using Stylebooks and whatever is needed there (I have done very little Firemonkey UI stuff).

I also gave Oxygene a go, and did manage to get an application on iOS up and running that used a NSTimer to check the NSLocationManager for position every now and then. The iOS environment is new to me and I know almost nothing about the classes available, but the Apple documentation was actually OK and after figuring out how to use a few services it was rather ok. However, it was a real pain to try to figure out how to use the XCode designer for storyboards/xib’s and I really did struggle a lot to find information on how to do this with Oxygene. I finally stumbled on a video and some blogs/wikis that somewhat explained this but it was at the end of my time allocated for this.

In the end I came to the realization that the best route will be to just bite the apple and learn XCode for iOS with Objective C and Eclipse/Java for Android. In fact, it will probably be more cost effective for us to just outsource the whole mobile client development and for us to focus on the server end.

I really wish the Delphi Mobile wouldn’t suck, and that RemObjects (clients) was available on that platform. The promise of code reuse on several platforms is really tempting, and specially the familiarity of it all for us long time Delphi developers.

I am disappointed that Embarcadero treats it’s technology partners this badly, I’ve heard similar (if not as graphic) complaints from other companies before (DevExpress comes to mind).

I must admit the animosity between the two companies makes me worry for the continuation of Delphi support here at RemObjects.

22

Tom
I couldn’t agree more with your comments. Anyone who seriously wants to create a decent mobile app will not waste time trying to have a single code base as such a panacea development tool is yet to exist.

For us, Oxygene is by far the closest thing, and it works, isn’t buggy and if you do find a bug it will be fixed pretty quickly.

I think RemObjects are right to not spend their limited resources on this, and think the animosity you mention is a secondary issue (entirely created by Embarcadero). RemObjects have realised (I think) that sensible people will come to the same conclusion you (and we) have. In fact, most of our stuff is done (RO) server side, so the mobile apps are just a GUI that makes calls/displays stuff, so it’s straightforward for us to do it with Oxygene anyway and actually it’s a lot more enjoyable - there’s just a bit of a learning curve but there’s a ton of docs out there (especially iOS).

Jeremy

23

Donald: https://github.com/remobjects/rofx-delphi-mobile has been created (empty). I’ll leave it to you to set that up and fill as you see fit, and to let me know who else should be invited (off this thread, i’d suggest).

24

Tom, Jeremy: lots of good points!

Tom, the experience you describe is exactly what is our concern. We don’t think “it was fairly easy to get something off the ground, even if the result sucked eggs” is something developers should strive for, and not something we want to support or even encourage.

This is not really about driving people to Oxygene. (Taking off my CEO hat), it doesn’t really matter of you choose Oxygene, or if you choose Xcode & Eclipse. What matters for creating great apps is that you chose the native toolchain — which either path supports.

Now, obviously we believe Oxygene has a lot to bring to the table over ObjC and Java. But that really is a secondary (and unrelated) decision to make. Whether you use Oxygene or Xcode/Eclipse, you are on the right path to great iOS and Android apps (with Delphi/Mobile you are not).

We appreciate your feedback re: finding it hard to get started with Oxygene for iOS work. We’re working on better tutorials, and any more concrete infos on what you found problematic would be appreciated.

As for the “animosity” between us and Embarcadero, as Jeremy indicated, that is entirely a one-sided thing. We have lots of experience dealing with Embarcadero, and we don’t find them a trustworthy company that we want to do business with. That said, we’re in business with our customers, not with Embarcadero. So we are fully committed (and will be indefinitely so) to our existing “for Delphi” products — not out of loyalty to Embarcadero, but out of loyalty to our customers, who have out their trust in us since 2002 to provide state of the art remoting and multi-tier data access for Delphi/Desktop.

We’re committed to the existing product, and the existing platform. But we’re drawing a line and not wanting to support the new mobile development platform coming out of Embarcadero (for mostly, as outlined above, technical reasons, but also in smaller part out of our disillusion with the company behind the platform and their way of doing business).

We (as does Embarcadero, very obviously, looking at their SKUing and pricing) consider Delphi/Mobile and FMX a new and separate product/platform; separate from the platform (Delphi/Desktop, VCL) that we have a longstanding commitment to our customers for that we are (of course) honoring.

Nothing (that i can think of) is going to stop us from honoring that existing commitment and from continuing to support our customers on that existing platform. We’re just not ready to take on the same commitment for a new platform out of Embarcadero, at this time.

I hope that makes sense, and explains the facets of this a bit better.

25

Thanks Marc for the repo, i will work on this. :slight_smile:

I delete all my other comments, prefer to be more polite. If somebody read old comments just ignore.

Best regards.

26

Marc the repo don’t exists, can be?

27

i need to give you access. It’s private, after all. what’s your github name?

28

sent via private mail

29

no mail so far…

30

yes ;). you should have access now.

31

Thanks, the repo is up.
Just to have a idea, theres any estimated for release of standard version for XE5?

I see no betas on beta section.

Bets regards.

32

should be out really soon. i’ll check with the team, lost track of that a bit myself this week, but i believe it’s almost ready (not sure why we haven’t pushed out a gamma yet :wink:

33

I’m happy to see that the small vocal “few” people asking for Delphi Mobile client support keeps growing.

Not because RO will support it based on requests, which can be seen they will not, but because it may create good ideas like the one Donald is presenting.

On the other hand it is a good opportunity for every Delphi developer which considers to keep running the latest tech coming from Emb to start making preparations for future migrations.

34

@marc i get compiled on XE5 the actual release, just have to change 4 lines of code (related to dmx) but imagine have no sense to send this to the team.

One time i have the official start point i will blog to get the most delphi/RO users there. Great time!

Best regards.

35

i’m building the RTM of our interim update for XE5 right now. should be available later today.

36

it’s out now.

37

Oh!

  • They have also made it very clear that they don’t want us supporting RO/DA on
  • Delphi, at all.
    Surprise. That’s way too early. Maybe EMB already rewrite the data snap. Who knows? Instead of bringing Delphi to all the other devices EMB simply could have redesigned the data-snap and provided the integration as it is now. That would have made sense as the developers/customers have to get to know the device landscape and the mobile operating systems anyway. Easier to argue and more wise form a tactical perspective, especially vs. the existing developer base still on ‘old’ Delphi versions.

I don’t ascribe that to EMB. A tool vendors logic is simply. Instead of selling those who care about the product, sell to those who don’t care about money. The latter are the majority and don’t try to exhaust the very potential of a tool. The bucks earned are the same or more. EMB will also have to consider their customers and except a few, many developers simply don’t care about modern things at all.

Such a head to head race as in case of Java and .net/C# does not happen very often at that large scale.

Beside these thoughts a question:

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?

38

@michaeltuma, can you please stop the polemics here? or what is your final intention? Why you remain blaming delphi users like idiots don’t care pay more money? Again: respect other developer, please, shut your mouth! we are trying to build bridges here and you are trying to be the smartest guy. Im tired of that comments and lack of respect for others developers. We get it, you don’t like EMB, don’t like Delphi, so why continue argue on this here? Move on and get a life.

39

DonaldShimoda :slight_smile: My comment was serious this time, but bloomy as always.

  • , many developers in general simply don’t care about modern things at all. This was a more general statement. I was not talking about ‘Delphi’ developers. Sorry that maybe caused confusion. Sorry for sharing my observations.

I know that there are many good companies out there with deep experience on both the Windows platform as well as Delphi as their development tool.

Donald not even in other places (.net, Java) you will find many people that try to get the most out of a platform. Maybe those who started in the early days and are used to. Remobjects Connect is very likely an exception.

I am not trying to be the smartest guy. I am not a developer, maybe what others call a VB developer.

Why should I have a problem with EMB? They simply evolve Delphi into a compact option that does provide everything I need out of the box, except for the diverse offerings on the GUI I don’t expect any tool vendor to cover. Datasnap is part of the integrative approach. That’s my guess. I call this a solution to the same problem from a tool vendor’s angle. There is nothing wrong with that.

To a certain point I was unhappy with RADStudio XE3 from the overall perspective. That’s true. That’s the only point.

Before I move on, I kindly suggest to read what I wrote. Totally unbiased.

Thanks for the fish. No need to answer my questions … I personally don’t care. Simply wanted to take the opportunity and ask, because that question came into mind. DA is used as an umbrella term for RO + DA.

40

@michaeltuma, is hard to read a your comments on a unbiased way, sorry.

I understand you are not a developer now, and you was on the past. That explain a lot.

Thanks for your opinion.