[DUG] Auckland Event Details

Mon May 5 15:17:51 NZST 2014

Hi Xander,

You are right. :-)

The only issue with Xamarin is it is quite dear to use visual studio with a
xamarin plugin for android, ios for professional coding. Pay each year
around US$1,000 per platform for visual studio support per developer. If
you want to develop android, ios both in visual studio, the fee is around
US$2,000 with some discount. If you want to develop ios, you need to get a
virtual machine to run mac os or get a mac machine. And you have to pay
around US$100 each year to Apple for a developer license.

If you don't mind to develop in Xamarin studio, it is quite cheap.

Regards
Leigh

On 5 May 2014 14:59, Xander van der Merwe <xandervdm at gmail.com> wrote:

> Haven't followed RemObjects for a while, I know they showed great promise
> some years ago and -perhaps still do, but I would personally look very
> closely at www.xamarin.com for developing iOS and Android applications if
> I had succh a requirement and did not want to use the native tools for
> those respective platforms. Xamarin is now being "helped/supported" by MS
> to ensure their tools are good, which also helps and you can build those
> directly inside Visual Studio (if you are so inclined of course)
>
>
> Regards
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
> *Sent:* Monday, 5 May 2014 2:41 p.m.
> *To:* russell at belding.co.nz; NZ Borland Developers Group - Delphi List
>
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> @David:
>
> Your prescription that the approach must support single source is
> arbitrary.  Heck, not even Embarcadero achieved this goal completely
> satisfactorily, so by that criteria FireMonkey itself is a failure.
>
>
>
> RemObjects approach is the more robust one.
>
> Rather than trying to pretend that platform differences can be abstracted
> away or reduced to lowest common denominator (as if the various user
> communities of the various platforms were not themselves making their
> choices precisely because of those differences, in many cases), those
> differences should be embraced and the developers empowered to take full
> advantage of them in order to provide the best solutions possible for
> *each* platform, not limited to providing a solution that can be deployed
> on *all* platforms.
>
> What should Embarcadero have done ?
>
> Simple.  Instead of tossing Prism into the long grass, they should have
> brought Elements into the fold.  Kept Delphi + VCL as their Win32 solution
> with Elements as their .NET and mobile platforms offering.
>
> But, frankly, as an Elements user who has previously experienced
> Borland/Inprise/Codegear/Embarcadero's product management, development,
> marketing and pricing at first hand, I am actually *very* relieved that
> they didn't (and suspect that RemObjects themselves might have resisted any
> attempt to do so).  ;)
>
> The very fact that an outfit such as RemObjects have both the technical
> nouse and capacity to deliver something like Elements whilst Embarcadero,
> with far more resources at their disposal, are left buying up other
> people's technologies and trying to create a marketing message around them
> whilst rushing out poor quality releases (XE6 Hotfix 1 was out before the
> ink had dried on the XE6 release EULA!) to keep the money mill churning,
> should tell you everything you need to know about Delphi's future.
>
> If RemObjects can do it, and if Embarcadero are everything that their
> supporters crack them up to be, then Embarcadero should have been able to
> deliver their own "Elements", especially given that they would have been
> able to focus exclusively on a Pascal solution, if they so chose, without
> the added distraction of a C# front end.
>
>
>
>
>
> @Leigh....
>
>
>
> Yes, Oxygene/Hydrogene (hereafter: Elements) when targetting Java,
> produces Java byte code.  Just like the vast majority of Android code out
> there (with the exception of games - the one type of app that the
> NativeActivity support in Android was only ever intended for).  Oh, and the
> FireMonkey apps.
>
> One thing this means is that unlike FireMonkey, your target platform is
> not confined only to Android and the Java environment provided there.  For
> example, if you really wanted to, you could use Elements to create an
> Eclipse plug-in.
>
> Elements can produce Java code, hence Elements supports all Java based
> platforms using all of the capabilities that those Java platforms supports
> because - to all intents and purposes - when compiling for Java, Elements
> *is* Java.  Just with a different language front-end.
>
>
>
> As such, yes, it runs at Java speed, just like all the other Java code on
> those Java based devices, Android or otherwise.  But it does so without
> having to drag in a bloated runtime and a custom UI rendering engine (and
> that's incorporated into EVERY FireMonkey app, btw).  Your apps take full
> advantage of the device capabilities.
>
> That includes, for example, ART, which is the Android technology that
> allows Java based Android apps to be installed as pre-compiled, native code
> binaries.  Just like FireMonkey apps, but without the embedded bloatware,
> and with the ability to run on any Android device (that support ART, or
> indeed of course all the ones that don''t).
>
>
> But equally, when compiling for Cocoa, Elements is an LLVM compiler.  All
> of the same advantages apply - you have complete, platform native access to
> the platform with all of the benefits that accrue.  Whether that is Cocoa
> (OS X) or CocoaTouch (iOS).
>
> Similarly, Elements for .NET... any .NET based platform is available to
> you, be that Windows.NET, Windows RT or Windows Phone.
>
>
> How is the .NET support in FireMonkey these days, by the way ?   ;)
>
>
>
> On 5 May 2014 12:59, russell <russell at belding.co.nz> wrote:
>
> Always interesting to read strong opinions … even when presented as facts
> and focusing on a few topics.
>
> The analysis looks plausible. I cannot assess it well as I write for a
> niche community  and RAD Studio serves me fairly well.
>
>
>
> Russell
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jolyon Smith
> *Sent:* Monday, 5 May 2014 11:13 a.m.
>
>
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> What makes less sense is the way that they added support for those
> platforms.  You are right to highlight the manner in which they have
> managed to tick boxes.  Unfortunately it is *purely* an exercise in
> ticking boxes.  Far less useful as a solid basis for continuing to be able
> to *keep* those boxes ticked.
>
> Delphi was always a niche product.  Despite the marketing, their
> cross-platform solution is *not* Delphi for "iOS/OS X/Android" (and it
> painfully clearly is not Delphi for .NET, let alone WinRT or WinPhone).  It
> is "Delphi for FireMonkey", with the ability to deploy to any platform that
> FireMonkey manages to cajole a semblance of support for within the
> constraints of what the approach allows.
>
>
>
> i.e. you cannot build true Android solutions using FireMonkey because the
> way that FireMonkey works rules out certain capabilities of that platform.
>  Similarly your FireMonkey Android apps will not benefit from ART.  Sure,
> your FireMonkey app is "native code", but is also bogged down by the
> non-platform native frameworks required to make even "Hello World"possible,
> so whilst true platform native apps gain all the benefits that that
> platform delivers, FireMonkey remains stuck in it's own world.
>
>
>
> i.e. FireMonkey created a niche within a niche.
>
>
>
>
>
> Having attracted the interest of Delphi developers to the platforms that
> FireMonkey ticks the boxes for, many of those developers will quickly
> realise the limits and look instead at the alternatives, at which point
> they realise just how far behind Delphi has fallen over the years while
> Embarcadero wasted their time on the Smoking Chimp.
>
> As for the renewed interest in developing the VCL, this can be seen as a
> return to core value, or it could be seen as a belated recognition that
> FireMonkey is not in fact the secure future for Delphi/Embarcadero that it
> was supposed to be, and worst of all, without any viable strategy for
> supporting the platform on which that core value rests - i.e. the latest
> and future versions of Windows - even that core value is now at risk.
>
>
>
>
> For myself, I now use a combination of RemObjects Elements and Xcode for
> most of my work.  Delphi is now very much a legacy platform.
>
>
>
> On 5 May 2014 10:46, David Brennan <dugdavid at dbsolutions.co.nz> wrote:
>
> It was a good seminar IMO. I understand why Embarcadero have decided to
> spend so much time adding support for OS-X, iOS and Android, at some point
> we may even take advantage of it. More importantly though I’m glad they
> seem to have realised that now they have ticked those boxes they need to
> return to address quality across the product.
>
>
>
> I just hope that XE7 will continue that trend so that the Delphi IDE and
> executables continue to improve in speed and robustness. I’m also hoping
> that XE7 will see a big push to make Code Insight bulletproof (or as bullet
> proof as such a thing can be, given that if you screw your syntax up
> completely midway through a big change it is always going to struggle, but
> it would be nice if it returned to fully operational once you tidy things
> up a bit!).
>
>
>
> Cheers,
>
> David.
>
>
>
>
>
> *From:* delphi-bounces at listserver.123.net.nz [mailto:
> delphi-bounces at listserver.123.net.nz] *On Behalf Of *Jeremy Coulter
> *Sent:* Monday, 5 May 2014 10:10 a.m.
> *To:* NZ Borland Developers Group - Delphi List
> *Subject:* Re: [DUG] Auckland Event Details
>
>
>
> Yeah let us know hen its done. We didnt attend the presentation for
> various reasons, although it would have be good, so am looking forward to
> hearing what Marco had to say.
>
>
>
> Jeremy
>
>
>
> On Mon, May 5, 2014 at 9:51 AM, Alister Christie <
> alister at salespartner.co.nz> wrote:
>
> I managed to spend a number of hours with Marco after the presentation,
> and have about an hour and a quarter recorded, which I will make available
> after Marco has reviewed it.  It was great talking with him, it seems that
> Embarcadero made a good choice appointing him Product Manager for Rad
> Studio.
>
>
>
> Alister
>
>
>  Alister Christie
>
> Computers for People
>
> Ph: 04 471 1849 Fax: 04 471 1266
>
> http://www.salespartner.co.nz
>
> Follow us on Twitter http://twitter.com/salespartner
>
> PO Box 13085
>
> Johnsonville
>
> Wellington
>
>
>
> On Wed, Apr 30, 2014 at 8:43 AM, Gary Benner <gary at benner.co.nz> wrote:
>
> HI All,
>
> Sorry this is a little late but just got back from a trip overseas.
>
> To endorse Alister's comment, great opportunity to meet Marco.
>
> cheers
>
> Gary
>
>
>
>
> Please see below details for the RAD XE6 Launch. Please will you forward
> this email invitation to members of the NZDUD to register/attend the event.
>
>
>
> Date and Venue:
>
> Friday, 02 May: Auckland
>
> Venue: Rydges Auckland - 59 Federal Street Cnr Kingston Street, Auckland
> 1010, New Zealand
>
> Time: 8.30am Registrations, 9:00am – 12:00pm
>
> http://forms.embarcadero.com/AP14Q2NZDeveloperDirectLIVE
>
>
>
> The event will be hosted by Damien Bootsma with special guest-speaker,
> Marco Cantu, RAD Studio Product Manager, global luminary & author of over a
> dozen books on Delphi. This event is not to be missed, so register NOW, as
> spaces are limited!
>
> Be amongst the first to see live previews of RAD Studio XE6 and all of the
> great new technology, with the latest enhancements to the VCL and more.
> Here's a glimpse of what is in store:
>
> Empowering your VCL codebase and developer productivity
>
>
>
> • Give Your VCL apps a new look-and-feel with improved VCL Styling
> • Introducing Win 7/8 taskbar buttons
>
> Database, integration and scalable services with RAD Studio XE6
>
>
>
> • Core Database Features Improvements
> • New FireDAC Database Explorer and more
> • Working with JSON and XML
> • Building scalable and secure DataSnap services
>
> Embrace and Extend Your Mobile and VCL applications
>
>
>
> • App Tethering
> • Not reinventing the wheel with new BAAS Client components
>
> "Turning on" to mobile and The FM Application Platform
>
>
>
> • Introducing Android support in C++Builder XE6
> • App Monetization with Advertising and In-App Purchases
>
> Evolution within a revolution: Summary and Q&A
>
> If you are an application developer, technologist or development team
> leader and interested in modernising your VCL apps & extending your
> applications to mobile devices for your customers, then this event is for
> you!
>
>
>
> Kind regards,
>
>
>
> Mike
>
>
>
> _______________________________________________
> 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/20140505/01261142/attachment-0001.html 