[DUG] EMBARCADERO MY GRIPE

Wed Jul 29 11:36:44 NZST 2015

Hi Jolyon,

You can select to use share runtime in release build too in xamarin. I
don't use it. It is just like delphi build app. One exe contains
everything. :-)

Regards
Leigh

On 29 July 2015 at 11:31, Leigh Wanstead <leigh.wanstead at gmail.com> wrote:

> Hi Jolyon,
>
> In debug build, the xamarin app does not embed mono runtime engine. The
> runtime engine installed as a separate apk. I guess that is what you want.
>
> Google can select .net to replace java dalvik. This way no need to embed
> mono in each app. But they don't. That is the war between oracle now by
> using java interface api.
> https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.
>
> Regards
> Leigh
>
> On 29 July 2015 at 11:08, Jolyon Smith <jsmith at deltics.co.nz> wrote:
>
>> Yes Leigh - the mono runtime that Xamarin relies on supports it at the
>> technology level, but the OS X platform is not available at the INDIE tier
>> of Xamarin subscription.
>>
>> And the idea of a platform levelling runtime required to be embedded
>> within each application is specifically why I think Xamarin and FireMonkey
>> are fundamentally flawed.  You don't build Android and iOS apps with Delphi
>> or Xamarin, you build FireMonkey and Xamarin apps that happen to run on
>> Android and iOS.  It's a subtle but (to me) important difference.
>>
>> Apart from anything else, it leaves you beholden to and often waiting for
>> the tools vendor to provide and maintain support for developments in the
>> platforms themselves.
>>
>>
>> On 29 July 2015 at 10:01, Leigh Wanstead <leigh.wanstead at gmail.com>
>> wrote:
>>
>>> Hi Jolyon,
>>>
>>> I think that mono support OS X which you can write c# code to run on OS
>>> X.
>>>
>>> Regards
>>> Leigh
>>>
>>> On 29 July 2015 at 09:56, Jolyon Smith <jsmith at deltics.co.nz> wrote:
>>>
>>>> Yes, there is no denying that it would be a hard sell to get elements
>>>> introduced into an enterprise or even ISV setting.
>>>>
>>>> But for the enthusiast/hobbyist/independent ObjectPascal (in
>>>> particular) developer it has much to offer against the likes of Delphi or
>>>> even FPC (which ime is frustratingly lacking in the polish you may be used
>>>> to from commercial dev tools and falls *far* short of the "just works"
>>>> goal when it comes to mobile dev... I suppose if you enjoy spending more
>>>> time getting your compiler to even work than you do developing apps, then
>>>> it may appeal).
>>>>
>>>> Even if you are keen on (or willing to suffer C#) Elements has some
>>>> advantages even compared to the comparably affordable version of Xamarin,
>>>> not least being complete platform support (Indie Xamarin does not support
>>>> OS X or System.SqlClient, for example).
>>>>
>>>> And using Elements I am at least also learning the platform SDK's, so
>>>> if I ever am asked to do Android or iOS development "properly", everything
>>>> I am learning in the meantime can be applied directly (I am no stranger to
>>>> Java / Eclipse or Objective-C / X Code, I just prefer ObjectPascal).
>>>>
>>>>
>>>> On 29 July 2015 at 08:13, Jeremy Coulter <jscoulter at gmail.com> wrote:
>>>>
>>>>> I guess for me, not ever seeing a role advertised that requires
>>>>> RemObjects experience, I would be confined to tinkering with the free
>>>>> version of the "Silver" tool.
>>>>> And given its not main-stream, it would be hard to get it into our
>>>>> development environment.
>>>>> Thats not saying it itsnt a good tool, just the commercial reality.
>>>>> However, like all of you, I am getting a little concerned about EMB.
>>>>> direction. For me personally, having to re-install my controls every six
>>>>> months or so is just not economic. Instead of releasing new versions ever 6
>>>>> months or so, do one a year with six month updates that doesnt require me
>>>>> to re-install all my controls.
>>>>>
>>>>> Jeremy
>>>>>
>>>>> On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith <jsmith at deltics.co.nz>
>>>>> wrote:
>>>>>
>>>>>> RemObjects # of users - sorry, I have no idea.
>>>>>>
>>>>>> Community support - there are two prongs to this...
>>>>>>
>>>>>> First, the RemObjects forums are quite active with contributions both
>>>>>> from users and RemObjects staff thmselves.  To give an example of the type
>>>>>> of support you get, on one occasion during my early days with the product I
>>>>>> encountered a problem using a particular aspect of the Android SDK which
>>>>>> was traced to an esoteric bug in the compiler.  This was identified in a
>>>>>> few days and by the end of that week a build had been provided to me
>>>>>> personally to test, before the fix was incorporated in a subsequent beta
>>>>>> and later release build.
>>>>>>
>>>>>> As a subscriber you have access to the current and previous releases
>>>>>> and betas and you also have a "private downloads" area where specific
>>>>>> builds may be provided to you.  Betas are updated on a more or less monthly
>>>>>> basis with full releases usually coming quarterly, along with regular
>>>>>> updates on the development plans (a "roadmap" if you like" via the blog, as
>>>>>> well as formal updates to those plans with each release (they tell you what
>>>>>> the new release delivers and what they are working on next).
>>>>>>
>>>>>> http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096
>>>>>>
>>>>>> I should add that I am enjopying only *BASIC* support.  Premium
>>>>>> support is a cost-extra option, should you feel the need for it.
>>>>>>
>>>>>>
>>>>>> Second, "Community Support" is also on offer from beyond the strictly
>>>>>> delineated boundary of "RemObjects Users" itself. by virtue of the fact
>>>>>> that you are developing directly against the platform SDK's.  I have
>>>>>> learned all my Android and iOS development from the Java and Objective-C
>>>>>> examples online and by perusing questions and answers on Stack Overflow
>>>>>> couched in terms of those platform native languages and API's.  Applying
>>>>>> that knowledge to RemObjects elements is a trivial exercise in syntax
>>>>>> conversion.
>>>>>>
>>>>>>
>>>>>> On the point of Java and "one language everywhere".... something to
>>>>>> bear in mind here is that when you compile RemObjects Elements code -
>>>>>> whether ObjectPascal (Oxygene), C# or Swift - for Android, what the
>>>>>> compiler emits is Java byte-code.  It is indistinguishable from the output
>>>>>> of a Java compiler!  The front end language syntax may be different, but
>>>>>> the output is essentially Java.  This applies equally to consuming other
>>>>>> Java code.  Classes etc from Java are simply consumed directly in your code
>>>>>> by adding the relevant JAR to your project references.
>>>>>>
>>>>>> So in a way, RemObjects Elements is an active participant in that
>>>>>> "Java everywhere" phenomenon - when compiling for a Java platform.  In the
>>>>>> Oxygene compiler they have cleaned up the syntax of some of the aspects of
>>>>>> Java, whilst retaining this compatibility.  For example. Java has no formal
>>>>>> specification for the concept of a "property".  But you can still declare
>>>>>> properties in Oxygene for Java - the compiler emits corresponding getXXX
>>>>>> and setXXX methods as you would expect (even if you have not explicitly
>>>>>> declared these accessor methods).  Equally, if you consume a Java class
>>>>>> (e.g. from the Android SDK) which implements get/set methods, then these
>>>>>> can be accessed as if they were properties:
>>>>>>
>>>>>>    Java methods:    v = o.getName(); / o.setName(v);
>>>>>>    Oxygene:            v := o.Name; / o.Name := v
>>>>>>
>>>>>> Similarly if provide your class implementing a read/write "Name"
>>>>>> property to a Java developer (in a jar file) then they will see a class
>>>>>> with getName and setName methods, just as they would normally expect.
>>>>>>
>>>>>> Equally when compiling for .net then Elements is an active
>>>>>> participant in that ecosystem/platform.  And ditto w.r.t iOS / OS X when
>>>>>> compiling for those platforms.
>>>>>>
>>>>>>
>>>>>> As I think I said, impressive and innovative technology.  :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 29 July 2015 at 00:25, John Bird <johnkbird at paradise.net.nz>
>>>>>> wrote:
>>>>>>
>>>>>>>   I don’t know RemObjects C# or Oxygene.   I read the site and
>>>>>>> their viewpoint on using native API’s is a worthwhile debate.    I would
>>>>>>> have these queries:
>>>>>>>
>>>>>>> 1 – Where does it rate on the number of users?   Community support,
>>>>>>> code snippets etc is as important as everything else.
>>>>>>>
>>>>>>> 2 – It is the opposite of “one language fits everywhere”   yet the
>>>>>>> language currently scoring top on the Tiobe index of programming languages
>>>>>>> does just that – Java.
>>>>>>>
>>>>>>> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
>>>>>>>
>>>>>>>
>>>>>>> I noticed Delphi is up another few places, to 13.   Pascal is rated
>>>>>>> separately too at 20.
>>>>>>>
>>>>>>> On the comments about the IDE, at work have used D5 , D2007, XE2 XE5
>>>>>>> XE7 XE8 and each version was a definite improvement.
>>>>>>>
>>>>>>>  *From:* Jolyon Smith <jsmith at deltics.co.nz>
>>>>>>> *Sent:* Tuesday, July 28, 2015 5:03 PM
>>>>>>> *To:* NZ Borland Developers Group - Delphi List
>>>>>>> <delphi at listserver.123.net.nz>
>>>>>>> *Subject:* Re: [DUG] EMBARCADERO MY GRIPE
>>>>>>>
>>>>>>>  I'll say it one more time... RemObjects manage to provide very
>>>>>>> good support for good quality products with extensive, impressive and
>>>>>>> innovative technology that does indeed "just work" (as in effortlessly, not
>>>>>>> "barely" LOL) at a very reasonable price.  $49 Turbo Pascal it certainly
>>>>>>> isn't, but lined up against the likes of Delphi and Xamarin and
>>>>>>> particularly after adjusting for inflation (for comparison with the $49 TP)
>>>>>>> it isn't far off.
>>>>>>>
>>>>>>> Cheap(er) = lower quality is *not* a rule, and certainly not a
>>>>>>> Universal Constant.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/20150729/750f4436/attachment-0001.html 