[DUG] XE7 and Android Development

Thu Jan 22 20:21:13 NZDT 2015

Hi Jolyon,

I’m afraid you have missed my point, perhaps you are making some rather incorrect assumptions about our application.

The code we want to re-use is not strictly VCL code (as in it is not forms or frames), but it turned out we were using a moderate number of records and methods (such as TPoint) which are part of the VCL library and not generic RTL. Our code also made use of TADOStoredProc components for loading data. We also have quite a lot of drawing code which draws via a class of our own using Enhanced Metafiles and then onto a VCL canvas. There were some other miscellaneous problems with using platform specific methods.

All of this can be refactored to remove the dependencies – we can and probably should have had our own TPoint (since we were using it for our own uses), we can use TDataset references instead of TADOStoredProc (which is what we did in the hacked version, with appropriate helper methods to do things like set parameters, however in the properly refactored version we have a much neater solution in mind), and we can produce different VCL and Firemonkey subclasses of our drawing canvas class. 

During the prototyping when we were producing the Android app for the trade show we took the quickest path to solving many of these problems on the basis that providing a working proof of concept was more valuable than getting bogged down in detail before we had a good understanding of the whole picture. Now that the prototype worked, was well received and we have a good handle on the issues involved in doing it properly, we intend to refactor things properly. The prototype branch will be binned, but that doesn’t mean that the effort was wasted – we will copy a moderate amount of the changes out into the final version and those we choose not to copy will highlight the areas which we need to refactor properly instead.

I get the impression that a lot of your work is on quite small projects. Sure, if you are developing an app which will take 120 man hours then why would you spend 80 hours refactoring existing code to provide a base, just write it from scratch. But when you are working with an application suite which has had 50+k man hours put into it and you want to re-use code which would take 5+k man hours to rewrite… well, you’re a hell of a lot better off spending those 80 hours so you can re-use your existing code than starting from scratch! Not to mention the fact that the end result of refactoring is a single tidier code base (many of the refactorings are things we would have done anyway if we had more time) which we can evolve in future years rather than having two disparate code bases which we need to maintain in parallel with all the hellish side effects of duplicate code.

In our case it was totally a no-brainer to go with Firemonkey and refactor our existing code rather than develop from scratch in a new development environment. Not even a contest. Other people will have different situations and hence may reach different conclusions. However I would point out that the Android app worked well, ‘looked’ like an Android app (even if it wasn’t Java) and we were happy with it, so Firemonkey is a more viable solution than you sometimes state.

Regards,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jolyon Smith
Sent: Thursday, 22 January 2015 7:16 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] XE7 and Android Development

@David Brennan - I don't see how you reach the conclusion that XE7 + FireMonkey makes sense "if you have an existing code base", given that if you aren't already developing in FMX then that existing codebase is almost certainly VCL and given all the observations you made about how utterly UN-re-usable your existing VCL code base was in your case.

The pre-amble seems to point to the exact opposite conclusion.  No ?

For Eric, I would ask why you are interested in using Delphi for this ?

If it is to exploit existing VCL code, then you have little chance of realising any benefit without an awful lot of work (perhaps even more than starting from scratch with an alternative tool/tech).

If you seek to leverage familiarity with Delphi to fully exploit any and all Android devices, I suspect you will be similarly disappointed both because the Android support is simply not complete as well as because "Delphi for Android" is a quite different animal than the Delphi you are used to.  You might as well learn Java or apply any knowledge you may have of C# with Xamarin.

Or, if you simply wish to continue using Pascal, you could look at RemObjects Oxygene (also previously known as Delphi Prism, in it's .NET garb as re-branded by Embarcadero for a time).

I developed a very simple app in Oxygene for Android, iOS and WinPhone.  In all three cases the app was developed using Oxygene (ObjectPascal with knobs on) but compiles to genuine, platform native binaries (i.e indistinguishable from those produced by Android Studio, Xcode or Visual Studio). 

The Android version is here if you are curious:

https://play.google.com/store/apps/details?id=itchbox.txt2park <https://play.google.com/store/apps/details?id=itchbox.txt2park&hl=en> &hl=en

The downside of the Oxygene approach (as some see it) is that you have to learn how to develop for each platform since there is no comprehensive cross platform abstraction library (although there is a library - Sugar - which makes a certain amount of re-use possible at the RTL layer - sharing common string manipulation routines etc etc).

But imho this platform specific aspect of the approach is absolutely NOT a downside for any serious mobile developer as you will quickly realise when you come to appreciate the differences between the platforms and learn how to write apps properly that look and behave properly on each platform, instead of taking a "one size fits all" approach.

It also means that you are learning those platforms and if necessary can apply that knowledge directly to development using the platform native tool chains.

i.e. With my simple app I have learned how to program a (simple, VERY simple) SMS sender app for Android, iOS and Windows Phone.  I happened to use Pascal, but what I learned about the platforms is just as directly applicable in Java, Objective-C or C# (respectively).  It also means that you can *learn* from people with expertise in the framework even if they are using other languages.

It is worth mentioning that all 3 versions of the app were developed in just one weekend even though there was zero code re-use between them.  The app is essentially 100% UI, and each platform works completely differently when it comes to the SMS APi's so there was no real chance for useful code re-use in such an app anyway.

Actually, there were 6 apps in total since I also learned the advertising API's and controls appropriate for each platform (again, different in each case) and created two separate versions of the app for each platform, one free/ad supported, the other paid for with no ads. 

Creating the 3 ad supported apps was another weekend.  :)

But Oxygene also is not hosted on Linux, being a Visual Studio plug-in (it is also supported by the free VS Community Edition, so there's no extra cost for using VS "Pro" any more).

However RemObjects are also working on "Fire", an OS X hosted IDE (still not Linux but at least also Unix based) for all their languages, since they also provide their own C# compiler as well as 'Silver' - a.k.a Apple Swift.  All three languages support all platforms:  Java/Android, iOS/OS X, .NET/WPhone.

Just my $2 (it was going to be 2c but thought I'd better protect it against future inflation).  :)

On 22 January 2015 at 16:29, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

We created an Android app in XE6 using a moderate amount of code from one of our big Delphi projects. It went OK and we successfully demonstrated the app on phones at a trade show recently, people liked the app. During development we had a few annoyances with how Firemonkey behaved but in general it wasn’t too bad.

However getting our existing code (even units with no forms/frames) to work was a bigger issue than expected. We did it in a development branch were we hacked things a moderate amount to get uses clauses and everything to compile with ifdefs, commenting stuff out, etc. A surprising amount of basic classes such as TPoint, TRect, etc (I think if I am remembering correctly) are not available in Firemonkey so we had to do quite a bit of hacking. As a result the ‘hacked’ development branch can’t be used to compile VCL apps and will be thrown out (effectively it was a prototype). The next step is for us to refactor our code properly to allow us to cross compile between VCL and Firemonkey with a minimum of ifdefs. This will be a reasonable sized project so it is waiting while other more valuable projects are being worked on.

Based on that fairly limited experience we believe Firemonkey to be viable for serious apps and we think it makes good sense if you have an existing code base which you want to cross compile between Windows and Android/iOS. Whether Firemonkey is the best choice for someone who doesn’t need to cross compile is a different matter, you get some benefits from prior Delphi experience but the controls, designer and some RTL portions are different so you still have a bit of a learning curve.

Cheers,

David.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Eric A
Sent: Thursday, 22 January 2015 3:15 p.m.
To: delphi at listserver.123.net.nz
Subject: [DUG] XE7 and Android Development

Has anyone in the DUG :

a) done serious Android device development using XE?

b) installed and used XE7, particularly for Android apps?

If not XE, what are people using/recommending as the best development platform for Android app development? (would be nice if it could be hosted on Linux, but not essential).

Eric

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with Subject: unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20150122/8e30a193/attachment-0001.html 