[DUG] EMBARCADERO MY GRIPE

Wed Jul 29 13:54:50 NZST 2015

yip I couldnt connect yesterday either. Not the first time either!
I am all for sites having issues, but for 2 days? The "Support" part of the
annual fee Emb. are charging isnt exactly being full-filled is it ?!
It always seems to be down. Its gone past disappointing now IMHO.

On Wed, Jul 29, 2015 at 1:06 PM, Leigh Wanstead <leigh.wanstead at gmail.com>
wrote:

> Hi Jolyon,
>
> What you said is the nice thing for the code to be compiled under dalvik
> byte code format.
>
> But I think it does not matter any more. I looked at the app installed on
> my samsung s2 for the application size
>  i.e. google map 69mb, nz herald app 27mb, google chrome 98mb, gmail 28mb,
> cpu-z 12mb, skype 88mb
>
> I doubt any customer will care if app is less than 100mb. I don't care. :-)
>
> I am working on a xamarin app used by multiple Australian companies for
> several years now and the apk size is around 9mb. No one complained to me
> about the app is too big and they want several kb size apk. :-)
>
> Regards
> Leigh
>
> On 29 July 2015 at 12:12, Jolyon Smith <jsmith at deltics.co.nz> wrote:
>
>> Are you sure about that Leigh?
>>
>> According to Xamarin themselves, selecting Release build specifically
>> turns OFF any shared runtime capability.  You can then use smart linking to
>> only include references assemblies to keep the amount of duplicate baggage
>> in that applications copy of the runtime to a minimum.  But it is still a
>> copy of the runtime and as far as I can tell, the smallest possible (Hello
>> World) release app in Xamarin is still almost 3 MB (2.9MB to be precise).
>> Of which only 6 KB is the application.  The rest is baggage.  Those are
>> Xamarin's own numbers, btw.
>>
>> For comparison, consider my fully functional, useful (albeit very simple)
>> TXT-2-PARK app, which weighs in at a massive.... 20 KB
>>
>> That's not a typo... 20 KILO bytes
>>
>> https://play.google.com/store/apps/details?id=itchbox.txt2park.pro
>>
>> Which is just one reason why truly native apps provide the best UX on
>> mobile devices... a 20 KB app is going to be loaded and running far faster
>> (20KB = virtually "instant on"!) than an app which has to drag in and
>> bootstrap a runtime engine before it can even start to do the work that the
>> user wants of it, never mind the amount of waste involved in constantly
>> bridging between the runtime and the platform API's.
>>
>>
>> On 29 July 2015 at 11:36, Leigh Wanstead <leigh.wanstead at gmail.com>
>> wrote:
>>
>>> 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
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/f5ddd30c/attachment-0001.html 