[DUG] EMBARCADERO MY GRIPE

Wed Jul 29 14:03:27 NZST 2015

Full agreement.  I am also glad to get confirmation it’s not just my browser(s) playing up.  Thanks for that.

From: delphi-bounces at listserver.123.net.nz [mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Jeremy Coulter
Sent: Wednesday, 29 July 2015 1:55 p.m.
To: NZ Borland Developers Group - Delphi List <delphi at listserver.123.net.nz>
Subject: Re: [DUG] EMBARCADERO MY GRIPE

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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> 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:  <mailto:jsmith at deltics.co.nz> Jolyon Smith 

Sent: Tuesday, July 28, 2015 5:03 PM

To:  <mailto:delphi at listserver.123.net.nz> NZ Borland Developers Group - Delphi List 

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 <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto:delphi-request at listserver.123.net.nz>  with Subject: unsubscribe

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz <mailto: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 <mailto: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/c8028435/attachment-0001.html 