If it's the first/only Android development tool you install (or if you don't care about any existing tools) then I am sure it is straight forward. But if an installer is going to change existing components of some other product/component then it should tell you what changes are required/involved.
Also I should have mentioned that the installer failed to detect the Android SDK initially (again, no such problem with Elements) so I had to tell it where the SDK was installed, at which point the installer appeared to be intending to install it's own copy of the SDK *AND* update the existing one. The identified, existing SDK was listed in *addition* to the proposed new installation. First impressions last, as they say. On 3 August 2015 at 11:23, Leigh Wanstead <[email protected]> wrote: > Good morning Jolyon, > > That is strange. > > I recall around four or five years ago I installed xamarin android the > experience was quite straight forward. It was easier than eclipse to do > development. > > You need to run android sdk manager to get everything up to date of > course. Xamarin android rely on google android sdk. > > Regards > Leigh > > On 3 August 2015 at 10:58, Jolyon Smith <[email protected]> wrote: > >> Well I tried installing Xamarin in order to rebuild my simple app using >> that, to do a precise like-for-like comparison both in terms of performance >> and development experience. >> >> But Xamarin insisted that I didn't have the necessary components of the >> Android SDK or JDK, despite pointing it at my current installations. The >> installations that are supporting my current Android development perfectly >> adequately. >> >> The Xamarin installer insisted that it was necessary to update these >> installations but wouldn't tell me exactly what it was going to do to them >> and since I didn't wish to risk breaking my current development stack I've >> had to postpone this exercise until I can spare the time to stand up a >> sandbox for the Xamarin environment. >> >> >> By comparison with Elements, when you install that if you already have >> these SDK's it simply uses them. If you don't, it directs you to download >> and install them. Any impact on the environment is then no different than >> the impact on a platform native Android development stack. i.e. you can >> only target API levels and framework libraries etc that you have installed, >> which you use the Android SDK Manager to manage. >> >> If Xamarin has specific requirements that it requires in this area then >> it really should at least tell you what those are rather than just saying >> "Not good enough, I'm going to change things" without saying how. >> >> Not a good first impression. >> >> >> On 3 August 2015 at 09:57, Leigh Wanstead <[email protected]> >> wrote: >> >>> Good morning Jolyon, >>> >>> I think that what you want is a benchmark to measure gui performance. In >>> our case app written in java or c# >>> >>> Here is the url >>> http://www.phonearena.com/news/TouchWiz-speed-test-Does-Samsungs-interface-really-lag_id66407 >>> >>> I tried that tool gamebench and it does not test code written in xamarin >>> android. >>> >>> Regards >>> Leigh >>> >>> On 30 July 2015 at 12:51, Leigh Wanstead <[email protected]> >>> wrote: >>> >>>> Hi Jolyon, >>>> >>>> To be honest, I do not have the time to develop app in java and c# just >>>> for benchmark purpose. I can only rely on google. :-) All I can say is the >>>> app I developed in Xamarin android is fast enough. To get a server call >>>> from Sydney, Australia to North Shore city Auckland, nz takes around 70ms >>>> is good enough for me. Without network call, working on local database on >>>> the samsung tab 2 tablet, the app's gui response is instant. >>>> >>>> Regards >>>> Leigh >>>> >>>> >>>> On 30 July 2015 at 12:26, Jolyon Smith <[email protected]> wrote: >>>> >>>>> A DSP filter ? Again, focussing on execution efficiency of a highly >>>>> specialised algorithm, not "real world" application performance. And >>>>> there >>>>> is no reason why you could not incorporate C code in an application where >>>>> appropriate, even if the bulk of your application does not require or >>>>> benefit from it. >>>>> >>>>> You keep coming up with numbers for what appear to me to be highly >>>>> artificial benchmarks. These are interesting from a compiler >>>>> implementation perspective, but not so relevant to real world applications >>>>> in relation to which you seem to be limited to "guess", "feel", "think". >>>>> >>>>> If the advantage were as clear cut as you seem to think then there >>>>> would be no benchmarks in which the exact opposite were established, yet >>>>> there are. All we can say then is that the benchmarks are not the whole >>>>> story. >>>>> >>>>> After all (dragging this back peripherally to Delphi), FireMonkey is >>>>> also a native code solution, but a google of "FireMonkey performance" does >>>>> not yield a litany of praise for the advantage of native code (other than >>>>> from Embarcadero's marketing department). ;) >>>>> >>>>> >>>>> Unless you develop an application in both Xamarin AND in Java and then >>>>> compare them to each other, you really have no idea whether what you >>>>> "feel" >>>>> is representative or not. The bottom line is that if your application >>>>> performance is acceptable, then great. That's all you really need be >>>>> concerned with. But this does not on it's own, nor even in conjunction >>>>> with unrelated benchmarks, lead to the incontrovertible conclusion that >>>>> it is the best it could possibly be. >>>>> >>>>> imho. ymmv. >>>>> >>>>> >>>>> On 30 July 2015 at 11:52, Leigh Wanstead <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Jolyon, >>>>>> >>>>>> Android ART is not end of the story. Compare to native c code, >>>>>> android art is slower. >>>>>> >>>>>> Here is the benchmark >>>>>> >>>>>> http://www.learnopengles.com/a-performance-comparison-between-java-and-c-on-the-nexus-5/ >>>>>> >>>>>> It is still around double slower than native c code for android art. >>>>>> >>>>>> You mentioned about bridge issue, I guess it is not a big deal. It is >>>>>> just like network call. Network call is expensive. Any api call to >>>>>> network >>>>>> just increase a little amount of overhead and can be ignored :-) But I am >>>>>> surprised that xamarin async call is half seconds faster than java >>>>>> android >>>>>> in the benchmark I mentioned. :-) >>>>>> >>>>>> I guess the extra time overhead to update title text/ set font size >>>>>> is ignored compared to do the real work. I do not feel slower in my >>>>>> application using xamarin android related to extra overhead api call. I >>>>>> think it is faster than builtin java code in android framework. >>>>>> >>>>>> Regards >>>>>> Leigh >>>>>> >>>>>> On 30 July 2015 at 11:36, Jolyon Smith <[email protected]> wrote: >>>>>> >>>>>>> Real world performance of code is more complicated than whether it >>>>>>> is compiled native or not, especially when you are talking about a >>>>>>> virtual >>>>>>> machine running within or on top of a foreign environment. >>>>>>> Xamarin.Android >>>>>>> code may well be native code, but how efficient that code is comes down >>>>>>> to >>>>>>> the original compiler and then also the JIT compiler. >>>>>>> >>>>>>> In addition, most Android applications will spend a lot of time >>>>>>> invoking services of the Android platform.itself, so the performance of >>>>>>> the >>>>>>> code calling those services may have only a very slight bearing on the >>>>>>> overall performance of the application. Far more significant is the >>>>>>> efficiency of calls made between the application code and the platform >>>>>>> services. For any non-platform native approach (Xamarin, FireMonkey) >>>>>>> there >>>>>>> is necessarily a "bridge" between the application code and the >>>>>>> platform, so >>>>>>> any performance advantage of the native code on one side that bridge >>>>>>> has to >>>>>>> offset the overhead of that bridge before it can offer any real >>>>>>> advantage. >>>>>>> >>>>>>> And with ART, the platform native application code is now also >>>>>>> native code so any advantage there is now - theoretically - entirely >>>>>>> lost, >>>>>>> leaving only the overhead of the runtime/platform bridge. >>>>>>> >>>>>>> Xamarin's benchmark tests execution efficiency of their generated >>>>>>> code in isolation. This is a meaningless benchmark since it entirely >>>>>>> ignores the real world impact of the overhead necessarily incurred by >>>>>>> having to constantly bridge from their execution environment to the >>>>>>> platform services on the device. Maybe Xamarin is faster there too, >>>>>>> but if >>>>>>> so why not publish some benchmarks demonstrating that to be the case, >>>>>>> rather than benchmarks which have no relevance ? Again: Consider the >>>>>>> source. >>>>>>> >>>>>>> Similarly mobile apps tend to spend a lot of time making network >>>>>>> calls. As you yourself observed, that can make a big difference in >>>>>>> perceived performance which has nothing what-so-ever to do with the >>>>>>> execution efficiency of the code *making* the network call. >>>>>>> >>>>>>> More importantly, all software has bugs - the more software you >>>>>>> involve in a solution, the greater the chance of encountering a bug that >>>>>>> will adversely affect your application and the harder it could be to >>>>>>> identify which component is responsible and obtain a resolution from >>>>>>> whichever vendor is responsible for that particular component in your >>>>>>> stack. e.g. such as the codegen error in .net framework 4.6 which can >>>>>>> introduce bugs even in existing applications. >>>>>>> >>>>>>> Consider the stacks: >>>>>>> >>>>>>> Xamarin: Xamarin / Mono compiler > Xamarin + Mono frameworks > >>>>>>> Mono runtime > Android >>>>>>> Delphi: Delphi compiler > FireMonkey framework > FireMonkey >>>>>>> RTL > Android >>>>>>> Elements: Elements compiler > Android >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 30 July 2015 at 11:11, Leigh Wanstead <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Jolyon, >>>>>>>> >>>>>>>> The fastest code on android is native code which is compiled by c >>>>>>>> code. Xamarin Android is based on runtime library which I guess is >>>>>>>> compiled >>>>>>>> in C too. Microsoft's net framework is compile .net code into native >>>>>>>> code >>>>>>>> before run the byte code on the real device. >>>>>>>> >>>>>>>> Regards >>>>>>>> Leigh >>>>>>>> >>>>>>>> On 30 July 2015 at 11:07, Leigh Wanstead <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Jolyon, >>>>>>>>> >>>>>>>>> If network round trip time has little or nothing to do with >>>>>>>>> framework, how you explain that url get different time from different >>>>>>>>> framework? I will assume that they will get similar time spent to get >>>>>>>>> data >>>>>>>>> on all framework. >>>>>>>>> >>>>>>>>> Dalvik platform is slow which is agree by google. Dalvik is slower >>>>>>>>> than Sun's jdk on mobile platform I read somewhere on internet. The >>>>>>>>> consideration for dalvik is not speed, but app size. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Leigh >>>>>>>>> >>>>>>>>> On 30 July 2015 at 09:06, Jolyon Smith <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> But Leigh, network round trip times have little or nothing to do >>>>>>>>>> with Mono / Dalvik / ART. >>>>>>>>>> >>>>>>>>>> I shall leave the last word on Xamarin to someone else... >>>>>>>>>> http://www.whitneyland.com/2015/07/xamarin-review-2015.html >>>>>>>>>> >>>>>>>>>> I would also recommend reading the earlier post from the same >>>>>>>>>> author. >>>>>>>>>> >>>>>>>>>> Worth noting in these round-ups is the point about the lack of >>>>>>>>>> community assistance when it comes to finding Xamarin solutions to >>>>>>>>>> common >>>>>>>>>> platform issues (as opposed to the bugs and issues in Xamarin >>>>>>>>>> itself). As >>>>>>>>>> mentioned before, RemObjects Elements avoids this problem due to the >>>>>>>>>> fact >>>>>>>>>> that the solutions for Java / Objective-C from the "native" >>>>>>>>>> communities for >>>>>>>>>> those platforms, can be applied *directly* in Elements projects >>>>>>>>>> in a way that is not often possible with Xamarin. >>>>>>>>>> >>>>>>>>>> On 29 July 2015 at 15:57, Leigh Wanstead < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Jolyon, >>>>>>>>>>> >>>>>>>>>>> It seems that we are going through the benchmark way :-) >>>>>>>>>>> >>>>>>>>>>> I tried to run the app in the url you mentioned and it crashed. >>>>>>>>>>> >>>>>>>>>>> How about you look at this url? >>>>>>>>>>> http://magenic.com/Blog/Post/4/Mobile-Development-Platform-Performance >>>>>>>>>>> >>>>>>>>>>> My work is getting data from server which is similar to test 3. >>>>>>>>>>> java version shows 2.369s and xamarin version shows 1.738s in >>>>>>>>>>> that url. That is around half seconds difference. >>>>>>>>>>> >>>>>>>>>>> I sometimes got around less than 70ms round trip time in my own >>>>>>>>>>> test to get data from server in sydney, Australian in north shore, >>>>>>>>>>> Auckland, nz if the server is not busy. That is amazing fast using >>>>>>>>>>> Xamarin >>>>>>>>>>> android. >>>>>>>>>>> >>>>>>>>>>> Most customers are in Australia. I guess that they might get >>>>>>>>>>> around 50ms round trip time. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Leigh >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 29 July 2015 at 14:42, Jolyon Smith <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> ... and if only I had a million dollars I would be rich. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As for Xamarin performance, consider the source. By which I >>>>>>>>>>>> don't mean the code, I mean who is making what claims. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://stackoverflow.com/questions/17134522/does-anyone-have-benchmarks-code-results-comparing-performance-of-android-ap >>>>>>>>>>>> >>>>>>>>>>>> Any advantage is only seen in an Intel Android VM. On ARM (by >>>>>>>>>>>> far the most prevalent in terms of actual Android hardware), >>>>>>>>>>>> Dalvik beat >>>>>>>>>>>> Xamarin almost every time, until Xamarin.Android 4.7.11. >>>>>>>>>>>> >>>>>>>>>>>> What is odd about this is that these results are from 2013, >>>>>>>>>>>> over a year after Xamarin posted their claims about >>>>>>>>>>>> *astonishingly* superior performance vs Dalvik. It is >>>>>>>>>>>> interesting that Xamarin do not disclose what environment their >>>>>>>>>>>> benchmarks >>>>>>>>>>>> were run in. Also interesting that they do not compare themselves >>>>>>>>>>>> to ART >>>>>>>>>>>> which is the more relevant comparison going forward. >>>>>>>>>>>> >>>>>>>>>>>> In any event, I don't think there is any chance that Google >>>>>>>>>>>> will drop ART any time soon (they already dropped Dalvik) in >>>>>>>>>>>> favour of a >>>>>>>>>>>> Mono based implementation of Android. ;) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 29 July 2015 at 13:51, Leigh Wanstead < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Jolyon, >>>>>>>>>>>>> >>>>>>>>>>>>> I mentioned to you before in the thread. If google choose to >>>>>>>>>>>>> use mono framework in android, xamarin apk size can reach several >>>>>>>>>>>>> kb too. >>>>>>>>>>>>> The reason for me to use Xamarin is the app developed by Xamarin >>>>>>>>>>>>> using mono >>>>>>>>>>>>> framework is faster than dalvik before ART time. The load time >>>>>>>>>>>>> for the app >>>>>>>>>>>>> is not my main concern. I care about the speed running the app >>>>>>>>>>>>> for whole >>>>>>>>>>>>> lifecycle. Here is the url >>>>>>>>>>>>> https://blog.xamarin.com/android-in-c-sharp/ >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Leigh >>>>>>>>>>>>> >>>>>>>>>>>>> On 29 July 2015 at 13:40, Jolyon Smith <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> What a fabulous attitude. It's thanks to that sort of >>>>>>>>>>>>>> thinking that we now "need" machines with quad core 2.5GHz >>>>>>>>>>>>>> processors and >>>>>>>>>>>>>> 8GB of RAM just to run frikkin MS Word. >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>> >> >> >> _______________________________________________ >> 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
