[DUG] Auckland Event Details

Mon May 5 20:01:35 NZST 2014

Hi Ian,

Glad the debate is interesting, just keep in mind that its only opinions,
from all of us ;-).

I enjoyed the presentation on Friday too. No big surprises or reveals but in
a way that was why I enjoyed it. Embarcadero have been working on adding big
new features with OS-X, iOS and Android for multiple releases now but IMO
big new features always need to be taken with a pinch of salt until they've
had a release or two to mature. XE6 seems to be about maturing everything
while adding a few nice features around the edges to keep up with how the
world of technology is evolving. 

Cheers,

David.

From: delphi-bounces at listserver.123.net.nz
[mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Ian Gmail
Sent: Monday, 5 May 2014 5:48 p.m.
To: delphi at listserver.123.net.nz
Subject: Re: [DUG] Auckland Event Details

Hi David, Jolyon, Leigh and other contributors

I was at the event on Friday, having been at all the releases recently. The
intention of this release was, something for everyone .. sort of a bit of a
lolly scramble really. I've just upgraded to XE5 and want to get to grips
with it before anything else.

What I'd really like to add is how valuable I'm finding the 'debate',
'information sharing you guys are so generously posting here. Its helping me
to position my next steps..

Thanks
Ian Drower

On 5/05/2014 5:18 p.m., David Brennan wrote:

Hi Jolyon,

What I said was: "Any solution needs to provide either a near perfect one
way migration path or long-term single sourcing between VCL apps and the new
platforms."

Embarcadero's current approach is the latter route. I can use exactly the
same source code between VCL and Firemonkey apps. The GUI layer certainly
needs to be different but I regard this as an unfortunate inevitability
whichever route Embarcadero went (as I said in my original reply, the only
alternative would be to update VCL to seamlessly cross compile onto other
platforms which everyone seems to have agreed was just too hard).

You are correct that I haven't tried to migrate any of our current
applications to Firemonkey and I have spent a relatively small amount of
time developing test apps in it. However large parts of our code, including
the most important and complex parts, can be compiled without VCL forms and
are used without the GUI in several different DLL styles (eg ISAPI, COM
DLLs, etc). There would of course still be plenty of work to be done in
incorporating this code into a Firemonkey app (new GUI, GUI links to our
business objects, mobile compatible data layer) but our core logic should in
theory be fine. The only hiccup I can see is the new object reference
counting used on the mobile platforms which may require some tweaking of how
we handle lifetimes of some objects to make sure they get freed properly
when desired. 

Even if some effort is required the key point is that after we have
performed this effort our core logic can be compiled to all platforms
(including Windows). That is my main goal out of any cross platform solution
and anything which does not deliver this automatically fails.

I do agree that lack of support for Windows Apps may become a concern. Last
I heard Microsoft were deliberately locking out native solutions which don't
use their exception handler. However this is only a real problem for us if
Windows RT takes off and currently it seems to be doing the opposite. 

Regards,

David.

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 4:27 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Auckland Event Details

@David:  What you say they shouldn't do (treat Delphi+VCL as legacy) is
exactly what they are doing, they just haven't come out and said as much.

Consider that their Windows 8 support consists of little more than GUI
styling.  FireMonkey does not work very well (in terms of making sense) in
this space and you might argue that this is OK because Windows won't be as
relevant in the mobile space (many would disagree) where FireMonkey is more
firmly planted.  But for the VCL to be struggling to remain current on the
desktop, should be a source of concern.

The best you can do with either approach is create something that looks the
part but which doesn't stack up once you peel back the GUI paint job.

So, that being the case, if FireMonkey is the "future"of Delphi on future
relevant platforms, where does that leave the VCL and longer term support
for the Windows desktop ?  Which, growth of other platforms notwithstanding,
will remain very relevant for a long time to come.

>From what you say I get the impression that you haven't yet actually tried
to migrate any code to the FireMonkey world.

Unless your legacy code was implemented in a fortuitously forward-thinking
manner, I suspect that a great deal of what you think might/should be
portable in your VCL code in particular may well turn out to depend on
things that aren't available to you in FireMonkey, or certainly not in a way
that you will be able to seamlessly and effortlessly migrate to.

@Xander:

Cost is one reason to discount Xamarin.  Elements cost me US$699 - that's
both Oxygene (ObjectPascal) and Hydrogene (C#) for .NET, Java and Cocoa.

Why would I need both languages ?

Well, I intend to learn C#, but I have shorter term project goals where
being able to leverage my productivity in ObjectPascal will be useful.  With
Elements I can mix and match as I develop my C# skills.  Because there are
no framework/runtime "walled gardens" in the way, work done in one is
directly usable in/with the other and - indeed - in the platform native
development environments to boot.

i.e. if it is easier to create a "Cocoa encapsulation"of some C API using C#
than to do so in ObjectPascal, then I can do so, but then I can use the
classes thus created directly on the ObjectPascal side, if I prefer to use
that for (e.g.) some GUI app that consumes that API.

And I can publish my encapsulation and Objective-C developers can use it in
their Xcode solutions.

The same applies in the Java space.  Also, in that case, I prefer Visual
Studio to Eclipse or any of the other Java development environments (plus
Java is even worse than C# as a squirrely brackets language).

Which is another point worth mentioning.... RemObjects implementation of
ObjectPascal and - to a lesser extent - C# improve significantly on Java, C#
and Objective-C in key areas, without losing compatibility at the code-gen
level.

@Leigh - why not use Java ?

I think my answers above should explain why I prefer not to use Java.  :)

For context:

I currently do most iOS / OS X development in Xcode and Objective-C.

I use Oxygene for Java (Android) being careful where possible to create
relevant code in my Android projects in a portable, platform independent
form with a view to re-using it in future Xcode/Oxygene/Hydrogene projects.

I anticipate using Hydrogene and/or Oxygene for .NET

On 5 May 2014 15:50, David Brennan <dugdavid at dbsolutions.co.nz> wrote:

Thanks for the reply. 

The single source requirement was based on my own requirements but I
strongly suspect I'm not alone in this. We have a million odd lines of code
and having to maintain two versions of that code to support iOS/Android
would automatically rule any solution out for us. 

Maintaining two versions of the GUI is also annoying but marginally more
palatable because a decent case can be made that the GUI requirements
between the different formats are sufficiently different to mandate making
new form designs anyway. Even so, I would still strongly prefer that being
my choice rather than foisted on me, and I would also prefer to be able to
use our current components on the new GUI (in our case primarily DevExpress
VCL). However I accept that it was close to impossible to port VCL to the
mobile platforms so a new GUI layer was inevitable.

Looking at overall approaches (and ignoring you specific recommendation with
Prism) I believe there are two aspects to what you are saying Embarcadero
should have done:

1.       Their GUI layer should be platform specific. Thus one would need to
develop a new version of a form for each target platform. I can see the
arguments both ways on this and suspect it comes down to how much effort a
developer wants to spend on each platform. For the foreseeable future any
iOS/Android apps we release are unlikely to be our core business so from my
point of view I prefer being able to develop a single tablet size version of
each form, add a few platform specific runtime customisations to the layout
and release to all platforms. But I recognise others may prefer the other
route. 

2.       Their language should cross compile into the most common
environment of each platform. That means Java for Android, Cocoa for
OSX/iOS, .NET/Win32/Win64 for Windows. That is a pretty impressive trick and
I am indeed impressed that RemObjects have managed to pull it off. The
question is whether Embarcadero could have achieved something similar while
maintaining single source backward compatibility for their existing customer
base. We would still need to be able to compile our current applications for
Windows with minimal changes. This means VCL still needs to compile too, as
do applications which directly access Windows APIs etc (although obviously
it would be acceptable to need to replace both VCL and Windows API calls
before single sourcing to another platform). I think it might have been
possible but Embarcadero decided to go the native instructions way instead.

Back to your specific suggestion, you say that Embarcadero should have made
Delphi + VCL a legacy solution and made Prism the new solution. In order for
this to work IMO either Embarcadero would need to provide a robust tool to
convert VCL projects to Prism projects OR you would need to be able to
single source code between Delphi and Prism. Otherwise the migration hurdle
is just too large - a development house would need to move ALL their code
and rebuild ALL their GUI in Prism at once to make the switch, small steps
over time would be impossible. Embarcadero would also have come under a lot
of pressure to enhance Prism so you could compile directly to Win32/Win64,
otherwise a portion of their customer base who demand to the metal code in
Windows would not make the switch.

This is all in my opinion, but it is in my opinion as the owner of a Delphi
software development house. Hence I think my situation is relevant. You
blithely say 'simple' leave Delphi + VCL as their Win32 solution with
Prism/Elements as the new platform. But I don't think it is 'simple', as I
explained in the previous paragraph. Any solution needs to provide either a
near perfect one way migration path or long-term single sourcing between VCL
apps and the new the platforms. 

In that context I can see why Embarcadero have gone the way they have and it
seems reasonable to me. My only beef with it is whether the implementation
they chose (Firemonkey) was the right one - I think they needed to be much
more ambitious with their initial design of Firemonkey, do everything
properly to make it a really top class component suite, and then spend three
years carefully developing it before releasing it. Instead they purchased it
then rushed it out the door, and have been spending a lot of time since then
trying to fix design flaws, something which is much harder to do once it is
already in use and backward compatibility is an issue.

Regards,

David.

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

_______________________________________________
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

_______________________________________________
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/76f7840e/attachment-0001.html 