Delphi to Oxygene for cross-platform coding

I moved to Delphi back in the day, because it had great support for RAD on Windows desktop. Now though, I’m needing to move onto RAD for desktop, phones & tablets.

  1. Do Indy, Zeos & Jedi run on Oxygene, or are there equivalents?

  2. How much of non-visual VCL (TFileStream/TBitmap/etc) is in Sugar?

  3. If I use something (eg. XML/JSON parsing) from the .Net framework, presumably it will fail in native iOS & Android?

  4. Just to clarify, does Oxygene compile to;

  • ARMv6/ARMv7 for iOS
  • x86/x64 for Mac/Linux
  • JVM for Android/Blackberry
  • .Net on Windows Phone/Desktop

TIA, Jim.

I don’t know about the Delphi questions you have but :

Yes. You could use mono but there are native built in JSON parsers on iOS and Android so you could use mapped classes for those (I do in my code).

[quote=“vannus, post:1, topic:4719”]
Just to clarify, does Oxygene compile to;[/quote]
ARMv6/ARMv7 for iOS - Yes
x86/x64 for Mac/Linux (Native on Mac, on Linux I think you’d need to use mono)
JVM for Android/Blackberry (Android - Yes, Don’t know about BB).
.Net on Windows Phone/Desktop - Yes.

Hello Jim,

You can use any .NET libraries that provide same functionality. There should be equivalents for .NET.

Sugar doesn’t contain Delphi components at all. Sugar is used for cross-platform applications (provides wrappers for frequently used classes like String, List etc.).

Best regards

I haven’t looked at the .NET side of things very much, but as near as I can tell there is nothing whatsoever, anywhere in existence, for Java (and, by extension, Oxygene for Java and Android development) that is a suitable replacement for Indy. For example, if anyone knows how to perform an operation as simple as POSTing to a login and retrieving the resulting HTML, while handling redirects and cookies correctly, they aren’t talking…

Have you looked at the free InternetPack that RemObjects provides for .NET? I just started using the ftp client in a Delphi app I’m rewriting.

I think Annus is asking about Cross Platform. Not just .Net.

The purpose of Oxygene is to go the “platform native” way using the platform native SDKs and APIs. And this is good so. Oxygene doesn’t need a ultra large RTL with thousends of bad wrappers to support different platforms (like Delphi).
The Oxygene RTL provides a good cross platform support for all common types. Sugar adds a great platform independent support for many usable complex types, date time, XML, lists and so on.

If you develop you business objects and business logic in native Oxygene code (using RTL and Sugar and platform indpiendent types) you can reuse them without changes and IFDef’s on each supported platform.
Within the platform specific projects you can add the required functionalities to your BO/ BL (in a platform native way) using extensions (class helpers), inheritance, observers or a seperate plattform specific “BL extension”.

Doing things in a way which is proposed by a single platform give you better results, is often simpler (see post of mwheeler), has more functionalities and is commonly faster at runtime (because there is no additional RTL ballast).
That’s much smarter then Firemonkey & Co. But you must learn a lot of stuff for all platforms that you target in your projects. This can be hard at the begining but will become earier each day you work with the platform native SDKs, because all the SDKs of a single platform providing anytime recurring concepts and APIs.

Forget FMX. It’s an endless wrapper hell, with many bugs, without clear concepts, changing 3rd party integrations and units in each Delphi version, and without native access to the platform SDKs which are proposed by the target OS. I paid for Delphi from Delphi 3 to XE6 and shortly tried to use FMX from XE2 to XE6 for my iOS Projects. In all that time FMX never did become “buisiness ready”.
Oxygenes iOS support is production ready since Version 6.0 and Android since Version 5. OS Updates doesn’t require to buy a new IDE Version, Bugs will be fixed quickly and doesn’t stagnate in a QC (like Embarcadero QC). In this forum it is possible to talk directly with the vendor developers and experts. They have anytime an open ear for your problems and needs. At Embarcadero you can only talk to the salesman to spend money for the next upgrade.

Using FMX you can rapidly develop small apps without deeper functionality and an OpenGL rendered UI, that’s bypassing all device specific SDKs and concepts. This apps working like a “foreign body” on any platform. In bigger apps you quickly run into unsolveable problems. Sometimes you reach a point where you need functionalities which are not provided by the Delphi wrappers or 3rd party components. You get bogged down in details because you never get contact with the underlaying native platform SDKs. The functionality of such apps suffers and the useability too. The energy consumption of a FMX app is expensive because of the OpenGL rendered UI and the device accu is rapidly empty (like as you playing a high end game).
Using Oxygene you get an app that’s working with the same “real word proven” SDKs and APIs that the device manufactors are taking for their development. It’s a realy “native” app that perfectly interacts with the underlaying device hardware.

Hm, something simple as typing “android http” ingot he google search bar give sme lots of promising stuff, including auto-completions that suggest there’s stuff about JSON (e.g. android http request json - Google Search) etc.

I’m not a huge Android dev myself, but i’d assume something simple as making an HTP request should be a “solved problem” even on that platform…

Also, Sugar does have a HTTP class, as well :wink:

Indeed. for example on iOS you pretty much wanna use NSURLSession, nowadays.

I’m not a huge Android dev myself, but i’d assume something simple as
making an HTP request should be a “solved problem” even on that
platform…

I assumed so too. Then I went and actually tried to do it. See the blog post I linked to for details. Suffice it to say, it appears to be anything but a solved problem. :frowning:

Exactly what problem has not been solved Mason ?

It took me two hours to get a working POST client up and running, and I’ve not touched a line of networking code in android before tonight. In fact it took me longer to write up my blog response! :wink:

Sugar.Http.DownloadStringAsync(new Sugar.Url("http://www.remobjects.com"), method (aResponse: HttpResponse<String>) begin
    Console.WriteLine(aResponse.Content);
end);

This is not a POST request. It does not send parameters, just for starters. I’ve looked at Sugar, and it doesn’t appear to have any mechanism for POST requests. (Unless that’s changed since I looked.)

Does Sugar handle redirects and cookies, BTW?

Thanks for the replies. I think I’ll have to try making some small apps in Xamarin/VisualStudio & Oxygene/Sugar to see which I find the most RAD for the various desktop + mobile platforms.