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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[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 >>> >> >> >> _______________________________________________ >> 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
