It seemed to make sense to me to at least finish of this series to the same audience as previous. I have thought about posting future articles to the Delphi for Android/iOS groups, but it occurs to me that this group is actually less appropriate for such posts.
A group specifically for people already using FireMonkey for Android/iOS is less likely to be interested in alternatives to Delphi. Such posts are more likely to be of interest to people who like Delphi but are not convinced by the mobile offering and considering the merits (or otherwise) of Pascal alternatives.
Maybe, but you are specifically targeting android - if you were targeting windows then I'd agree but you're not, just struck me that the main Delphi group was perhaps the wrong place for it :-)
You may very well think that. I couldn't possibly comment.
But since you bring it up, I do think that there is a segment of the Delphi community that are in denial.
It beggars belief that they can defend FireMonkey as just needing time to settle down and get some serious bug-fixing done on the one hand (entirely ignoring the architectural problems that cannot simply be "fixed" since they are an intrinsic part of what makes FireMonkey even possible), and then turn around and complain about long-standing bugs going unfixed and new bugs being introduced on the other.
Is there a development tools specific variant of Stockholm Syndrome ? :)
I think there are alot of people who have much invested in delphi working. I kinda like the smoking ape, but then I have been told I am a masochist :-)
It remains to be seen if the issues with it can be resolved, I am leaning towards the same opinion that you have - that the faults with FM are intrinsic and its never going to work. On the other hand, I would really like to see it work - the concept is IMHO a good one - the implementation leaves much to be desired. There are elements involved here at my work that are of the opinion that the speed issue with FM is all down to the amount memory being moved about and the impact of that - I am starting to think they are right and this can't be resolved.
The biggest problem I see with FireMonkey is inherent to it's (initial) appeal: It's a transitional technology. It specifically aims to get you from A to B with a minimum of fuss.
The problem being that to do this it first wraps you up in a protective bubble. You were never truly at "A" at all, and when you get to "B" you're never really there either.
You are on a train. A technologically advanced, very attractive looking train with a nice observation deck upstairs, but you can't get off. All you can do is sit in the station where-ever it takes you. There may be some limited excursions on offer, but you can't just go off exploring on your own. And other than those packaged excursions, if you want to engage with the local culture you can only do so either from the observation deck or courtesy of whatever samples the station manager is able to bring you.
As such, I'm afraid I have to disagree and say that whilst the technical achievement might be impressive on an intellectual level, the concept is intrinsically and fatally flawed from the outset.
Unless you enjoy train rides. :)
Imagine where we might be today if Embarcadero had teamed up with RemObjects - left the language development to the incredibly talented guys at RO and deployed the resource at Embarcadero to creating a cross-platform RTL using Oxygene (specifically not a cross-platform UI framework)....
Thats a little unfair, you can get out of the box in both iOS and Android - its just not very pretty :-)
I can't comment on Oxegene, I don't have it to try - I do write (these days) in C++ (horrible,horrible), Java (Android Studio - meh, OK apart from the case sensitivity, which is stooooooopid if you ask me), C# (VS and, in the past, Mono) plus some cross platform work with Lazarus (via CodeTyphon). I will say that none compare to Delphi 5, I will also say that my boss was unimpressed with Oxygene (why I do not know).
I will say that I have looked at Oxygene in the past and rather liked the language look (apart from putting VAR in the middle of code), especially the multithreading with futures and what not. Dunno, can't really compare. I don't FM is that bad, like I said, concept wise its a good idea - but as you say, there are several layers of abstraction surrounding the platform services which I don't like - I would rather have slightly different implementations for each platform that work and then ifdef my code than fight my way through the fog that is the lack of documentation in XE5.
".. you can get out of the box in both iOS and Android"...
Really ? Show me a FireMonkey based Android AppWidget or Service. ;)
Getting out of the FireMonkey box you find yourself in the iOS box. The shortcoming on iOS are less obvious because iOS itself is more of a walled garden than Android. Walls made of Cocoa or walls made of Monkeys, doesn't make much difference. ;)
If FireMonkey had come for Android first, with all the shortcomings inherent in the architecture, I'm not at all sure it would have been taken seriously enough to survive to see an iOS version. I suspect this may even have been one reason for delivering iOS first.
Platform architecture aside, FM also perpetuates the folly of embedding business logic and data in the UI - even more deeply than with the VCL. It's a shockingly primitive approach when you get past the initial scene based rendering technology.
As for the language features:
Inlining "var" in Oxygene is entirely optional. Use it if you like (when it's convenient/useful). Don't if you don't. :)
Case sensitivity is also less of an issue using Oxygene for Java. It is more intelligent in knowing what a given symbol means in context and does not rely solely on case
Rectangle = public class .. end;
var rectangle: rectangle;
method Foo; var r: rectangle; ...
All works exactly as you would expect. "rectangle" used where a type identifier is expected will find the "Rectangle" type. You will get a warning that the case is incorrect with the ability to fix it directly and automatically from the compiler warning itself.
Ah well, you have me there. There is no way to write a service in FMX - its limited by the NDK, targeting native ARM was a total mistake IMHO,I reckon they'll end up implementing a load of java support classes to get around all this, but then the NDK was never intended to support this kind of thing.
They should bin it and concentrate on Dalvik output, but is there time? I will see what comes up in coderage, if I get a chance I will be asking a few hard questions I think!
TBH,I think if we were to jump from Delphi/Rad Studio we'd just get properly into Android Studio for android work and use our own compiler for pascal work (yes we have one)
Never mind concentrating on Dalvik output, they would first have to make a start in this area.
This wouldn't be "adding some more Java classes like they did to wrap the NDK app activity". Despite the impression Marco Cantu has previously given that Embarcadero created a Java wrapper around their native code, they didn't and don't do that.
NativeActivity is part of the platform - using it just requires a declaration in the manifest.
You will have to decide for yourself whether it is more comforting to believe that the Delphi Product Manager does not know how his product was developed or that he does know and chose to misrepresent it to his customers.
I do not claim to know which explanation (or some other) is the right one, but these are the two most likely I think.
Nice post, although it probably belongs in the iOS and android group now. Or you could ask ***** to create a oxegene specific sub group :-)
ReplyDeleteIt seemed to make sense to me to at least finish of this series to the same audience as previous. I have thought about posting future articles to the Delphi for Android/iOS groups, but it occurs to me that this group is actually less appropriate for such posts.
ReplyDeleteA group specifically for people already using FireMonkey for Android/iOS is less likely to be interested in alternatives to Delphi. Such posts are more likely to be of interest to people who like Delphi but are not convinced by the mobile offering and considering the merits (or otherwise) of Pascal alternatives.
No ?
Maybe, but you are specifically targeting android - if you were targeting windows then I'd agree but you're not, just struck me that the main Delphi group was perhaps the wrong place for it :-)
ReplyDeleteOxygene used to be (and for some people still is) part of Delphi (albeit only "Echoes" - the .NET platform variant)
ReplyDeleteIt strikes me that it is possible to argue the merits of sharing or not sharing to suit. :)
But fret ye not - no more Android posts to disrupt the peace of the Delphi idyll. :)
idyll? is that anew term for crazed anger? :-P
ReplyDeleteYou may very well think that. I couldn't possibly comment.
ReplyDeleteBut since you bring it up, I do think that there is a segment of the Delphi community that are in denial.
It beggars belief that they can defend FireMonkey as just needing time to settle down and get some serious bug-fixing done on the one hand (entirely ignoring the architectural problems that cannot simply be "fixed" since they are an intrinsic part of what makes FireMonkey even possible), and then turn around and complain about long-standing bugs going unfixed and new bugs being introduced on the other.
Is there a development tools specific variant of Stockholm Syndrome ? :)
I think there are alot of people who have much invested in delphi working. I kinda like the smoking ape, but then I have been told I am a masochist :-)
ReplyDeleteIt remains to be seen if the issues with it can be resolved, I am leaning towards the same opinion that you have - that the faults with FM are intrinsic and its never going to work. On the other hand, I would really like to see it work - the concept is IMHO a good one - the implementation leaves much to be desired. There are elements involved here at my work that are of the opinion that the speed issue with FM is all down to the amount memory being moved about and the impact of that - I am starting to think they are right and this can't be resolved.
The biggest problem I see with FireMonkey is inherent to it's (initial) appeal: It's a transitional technology. It specifically aims to get you from A to B with a minimum of fuss.
ReplyDeleteThe problem being that to do this it first wraps you up in a protective bubble. You were never truly at "A" at all, and when you get to "B" you're never really there either.
You are on a train. A technologically advanced, very attractive looking train with a nice observation deck upstairs, but you can't get off. All you can do is sit in the station where-ever it takes you. There may be some limited excursions on offer, but you can't just go off exploring on your own. And other than those packaged excursions, if you want to engage with the local culture you can only do so either from the observation deck or courtesy of whatever samples the station manager is able to bring you.
As such, I'm afraid I have to disagree and say that whilst the technical achievement might be impressive on an intellectual level, the concept is intrinsically and fatally flawed from the outset.
Unless you enjoy train rides. :)
Imagine where we might be today if Embarcadero had teamed up with RemObjects - left the language development to the incredibly talented guys at RO and deployed the resource at Embarcadero to creating a cross-platform RTL using Oxygene (specifically not a cross-platform UI framework)....
Thats a little unfair, you can get out of the box in both iOS and Android - its just not very pretty :-)
ReplyDeleteI can't comment on Oxegene, I don't have it to try - I do write (these days) in C++ (horrible,horrible), Java (Android Studio - meh, OK apart from the case sensitivity, which is stooooooopid if you ask me), C# (VS and, in the past, Mono) plus some cross platform work with Lazarus (via CodeTyphon). I will say that none compare to Delphi 5, I will also say that my boss was unimpressed with Oxygene (why I do not know).
I will say that I have looked at Oxygene in the past and rather liked the language look (apart from putting VAR in the middle of code), especially the multithreading with futures and what not. Dunno, can't really compare. I don't FM is that bad, like I said, concept wise its a good idea - but as you say, there are several layers of abstraction surrounding the platform services which I don't like - I would rather have slightly different implementations for each platform that work and then ifdef my code than fight my way through the fog that is the lack of documentation in XE5.
".. you can get out of the box in both iOS and Android"...
ReplyDeleteReally ? Show me a FireMonkey based Android AppWidget or Service. ;)
Getting out of the FireMonkey box you find yourself in the iOS box. The shortcoming on iOS are less obvious because iOS itself is more of a walled garden than Android. Walls made of Cocoa or walls made of Monkeys, doesn't make much difference. ;)
If FireMonkey had come for Android first, with all the shortcomings inherent in the architecture, I'm not at all sure it would have been taken seriously enough to survive to see an iOS version. I suspect this may even have been one reason for delivering iOS first.
Platform architecture aside, FM also perpetuates the folly of embedding business logic and data in the UI - even more deeply than with the VCL. It's a shockingly primitive approach when you get past the initial scene based rendering technology.
As for the language features:
Inlining "var" in Oxygene is entirely optional. Use it if you like (when it's convenient/useful). Don't if you don't. :)
Case sensitivity is also less of an issue using Oxygene for Java. It is more intelligent in knowing what a given symbol means in context and does not rely solely on case
Rectangle = public class
..
end;
var rectangle: rectangle;
method Foo;
var
r: rectangle;
...
All works exactly as you would expect. "rectangle" used where a type identifier is expected will find the "Rectangle" type. You will get a warning that the case is incorrect with the ability to fix it directly and automatically from the compiler warning itself.
Ah well, you have me there. There is no way to write a service in FMX - its limited by the NDK, targeting native ARM was a total mistake IMHO,I reckon they'll end up implementing a load of java support classes to get around all this, but then the NDK was never intended to support this kind of thing.
ReplyDeleteThey should bin it and concentrate on Dalvik output, but is there time? I will see what comes up in coderage, if I get a chance I will be asking a few hard questions I think!
TBH,I think if we were to jump from Delphi/Rad Studio we'd just get properly into Android Studio for android work and use our own compiler for pascal work (yes we have one)
ReplyDeleteNever mind concentrating on Dalvik output, they would first have to make a start in this area.
ReplyDeleteThis wouldn't be "adding some more Java classes like they did to wrap the NDK app activity". Despite the impression Marco Cantu has previously given that Embarcadero created a Java wrapper around their native code, they didn't and don't do that.
NativeActivity is part of the platform - using it just requires a declaration in the manifest.
You will have to decide for yourself whether it is more comforting to believe that the Delphi Product Manager does not know how his product was developed or that he does know and chose to misrepresent it to his customers.
I do not claim to know which explanation (or some other) is the right one, but these are the two most likely I think.
ah yes, but poor Marco has joined the phb clan and so has had his brain removed :-)
ReplyDelete