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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> *Sent:* Tuesday, July 28, 2015 5:03 PM >>>>>>> *To:* NZ Borland Developers Group - Delphi List >>>>>>> <[email protected]> >>>>>>> *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: [email protected] >>>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>>>> Unsubscribe: send an email to [email protected] >>>>>>> with Subject: unsubscribe >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> NZ Borland Developers Group - Delphi mailing list >>>>>> Post: [email protected] >>>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>>> Unsubscribe: send an email to [email protected] >>>>>> with Subject: unsubscribe >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> NZ Borland Developers Group - Delphi mailing list >>>>> Post: [email protected] >>>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>>> Unsubscribe: send an email to [email protected] >>>>> with Subject: unsubscribe >>>>> >>>> >>>> >>>> _______________________________________________ >>>> NZ Borland Developers Group - Delphi mailing list >>>> Post: [email protected] >>>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>>> Unsubscribe: send an email to [email protected] >>>> with Subject: unsubscribe >>>> >>> >>> >>> _______________________________________________ >>> NZ Borland Developers Group - Delphi mailing list >>> Post: [email protected] >>> Admin: http://delphi.org.nz/mailman/listinfo/delphi >>> Unsubscribe: send an email to [email protected] with >>> Subject: unsubscribe >>> >> >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] with >> Subject: unsubscribe >> > >
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
