[DUG] Opinion wanted - is the upgrade from XE5 to XE6 worthwhile
Jolyon Smith
jsmith at deltics.co.nz
Fri Jul 11 13:59:27 NZST 2014
Xamarin relies on Mono, with potential licensing and runtime implications
for commercial developers.
Xamarin does have a fully capable free edition and an individual edition,
but if you have 6+ employees then you don't qualify for these (not 6+
Xamarin licenses/users, just employees). At which point, as Leigh
mentions, Xamarin starts to get eye wateringly expensive. When looking at
Xamarin pricing remember to multiple each user by the number of platforms
that user will support!
As for XE6, I doubt that mobile development per se will get any "better" in
Delphi XE, in the sense that it will ever fundamentally change the
approach. You will always be stuck with a runtime framework which will eat
up a significant portion of any benefit gained from compilation to hardware
code, comes with it's own minimum hardware requirements, regardless of your
application needs/complexity. This framework delivers platform independent
UI's but denies you access to the full capabilities of the underlying
platforms.
The approach actively encourages a "one size fits all" approach to mobile
device UI's, flying in the face of the fact that the different platforms do
have differences, some of which influence the choice of platform for the
users involved. Some iOS users don't want no stinking Android look and
feel, and vice/versa. And nobody is much impressed when an app has it's
own entirely unique UI, even if it's consistent across all devices. I
never could understand why an Android user is supposed to care that the app
they use on their device looks exactly the same on someone else's iPhone.
imho these advantages speak to bean counters and project managers, not
users or customers.
Back to the future of mobile dev on Delphi, there may be bug fixes and
additional capabilities, but things such as the inability to create widgets
or deploy to Intel based devices etc cannot be addressed by adding more and
more stuff into FireMonkey. The problems there are baked in to that
hardware code approach. e.g. no support for Intel x86 based Android
devices.
It is also highly unlikely that you will ever again see a .NET solution
from Embarcadero, so if Windows mobile platforms (other than Surface Pro)
are or could be important to you (or perhaps more importantly, to your
customers - potential or actual) then XE is a dead end. Similarly the VCL
is essentially in a freeze-dried state.
RemObjects now has a C# offering in the form of Hydrogene. Just as with
Oxygene, it supports Java (and therefore but not only Android) as well as
.NET, iOS and OS X. Also just as with Oxygene, it favours genuine platform
native implementations over portable abstractions, but source can be
written in a cross-platform manner where desirable and appropriate. To an
extent.
With RemObjects you can also mix C# code with ObjectPascal (in the form of
RemObjects Oxygene).
RemObjects C# is far and away the cheapest option at $699 for all platforms
(.NET, Java, Cocoa) when considering fully capable editions of the
available multi-platform options. Even if you add in ObjectPascal, it
remains the cheapest option in terms of licensing cost.
The fact that your development is conducted against the platform native
API's also means that if you or your developers ever need to resort to
asking for assistance, then the entire community of developers for those
platforms will be of use. An expert in Android development might only
speak a Java dialect of the Android SDK's, but the core vocabulary and
syntax of those SDK's is the same, you just need to speak their answers
with the RemObjects C#/Pascal accent.
But if your question involved a FireMonkey or Xamarin.Forms widget, for
example, then your pool of resources is limited to those who know
FireMonkey or Xamarin.
Developing at the platform level(s) also means you will be better prepared
to switch to entirely native development (i.e. Eclipse, Xcode and
Objective-C) should the need or desire arise in the future.
I would say that's my 2 cents, but I think it's a bit more than that. :)
As I think people may already know, I myself opted for RemObjects C# and
ObjectPascal. I have Delphi 1 thru XE5, but this is used only for what you
might now call "legacy" Win32/64 VCL development.
On 11 July 2014 12:04, Leigh Wanstead <leigh.wanstead at gmail.com> wrote:
> Hi Stephen,
>
> C# actually is Xamarin android, iOS :-)
>
> I think Xe6 price is cheap compare to Xamarin solution :-)
>
> But Xamarin allows you to write xamarin.forms for android, iOs and windows
> 8 phone in a single code base with native look for each platform. :-)
>
> The key word compare to Xe6 is native control for each platform :-)
>
> Regards
> Leigh
>
>
> On 11 July 2014 06:04, <stephen at bertram.co.nz> wrote:
>
>> Hi All
>>
>> I have XE5, but am really only using it in Win64 mode. To date I have
>> not done any mobile development or Firemonkey apart from a few small apps
>> to find out if it does what it is supposed to. At the moment I'm in Europe
>> for a few months enjoying myself and not thinking about coding, but when I
>> get back I will be into a few projects and deciding on my development
>> environment of choice. To this end I would like to hear from anyone who
>> has upgraded to see if there is any advantage for me.
>>
>> Are the XE6 bug fixes significant?
>> Is the Android and OSX/iOS deployment better?
>>
>> And the key question (I can hear the screams from here) - How does XE6
>> rate against C# and Objective-C?
>>
>> I look forward to the discussion :-)
>>
>> Stephen Bertram
>>
>> _______________________________________________
>> 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/20140711/c654bbf8/attachment-0001.html
More information about the Delphi
mailing list