I have sat here over the last 2 hours trying to get my old source running cross platform on my new Android tablet, compiled with Delphi XE6, in vain. Some issues at fault are that the Delphi XE5 units and libraries were so completely immature that they have lots of linkage problems to XE6, even though Xe6 is really just a minor upgrade from XE5. XE4, 5, and 6 were each released just 6-months apart, which is unheard of for any company serious about its products.
Whereas I appreciate the opportunity to try them out sooner rather than later, I also wish I didn’t blow $1,500 on software that just plain doesn’t friggen work.
One source of resentment is that all my legacy code must be painstakingly refactored to allow for 0-based strings, lack of ansistring support, and Embarcadero’s ridiculous design decision to move all objects to automatic reference counting. Everything must change… all the little functions that work with streams must be changed and verified, every function you ever wrote for string manipulation must be verified… not only every single object must be verified and refactored, but every single use case of every single object must be verified and/or refactored and code must be IFDEFed all over the place deal to with subtle incompatibilities. Given the amount of changes that I’d have to make to get some things working, I didn’t expect things to work right away. But…
after boring myself in the drudgery and frustration when my app failed to even launch, I decided to switch gears and just check out some of the Embarcadero-supplied demos.
I recently just got a new tablet that is the cream of the crop in the Android market, and I figured I’d like to see what it could do. Certainly if any tablet could run this Firemonkey stuff, it would be the nVidia Shield Tablet… a quad core powerhouse with a 192core Tegra K1 GPU capable of blowing all other tablets out of the water in the benchmarks.
The problem is that Firemonkey on mobile is so unstable that even your basic Hello World app doesn’t load right half the time, and if it does load, clicking a button while exhaling generates a “Segmentation Fault (11)” error. I recommend inhaling, holding your breath and then exhaling only after the app is completely shut down for reliable operation. Hopefully you won’t run out of oxygen and pass out before your app has concluded doing what it needs to do… but don’t worry too much, because your app won’t run long anyway.
I tried all the samples that Embarcadero supplied on their SVN server (which I have noticed has been updated a lot lately)… yet none of the examples I’ve tried are working for me! I’m not sure what kind of Balkan slave labor they have working on this shit… but it just isn’t right. Maybe they were built for XE5 (some of them didn’t even compile) — I don’t know, and I kinda don’t really care right now. I’ve seen enough to know that Embarcadero is trying to sell us the amniotic fluid, gibblets, and pre-birth excrement that inevitably precedes childbirth while telling us that this steaming pile of diarrhea is actually a newborn child. “Cash only please.”
The Embarcadero sales people recently contacted me about renewing my “support contract” with them. I replied rather rudely that their software barely worked, and I felt exploited by being forced to pay them money to fix bugs that shouldn’t have existed in the first place and wondered when they were going to get around to fixing some bugs that are still hanging around like embarrassing exposed genitals after 15 years and routinely remind me of how unprofessional this company really is.
They have made no effort whatsoever to retain my loyalty as a customer since.
I’m not sure how these people sleep at night.
For FireMonkey to run properly on Android devices NEON support is required. It seems that Tegra 2 devices are not supported.
http://docwiki.embarcadero.com/RADStudio/XE6/en/Android_Devices_Supported_for_Application_Development
Well, my clients and customers, unfortunately, don’t know or care what NEON is, and I can’t safely feel okay releasing an app to Google that isn’t going to target as many customers as possible.
NEON support was actually added in the Tegra 3 processor which preceded the Tegra 4 and the Tegra K1. The K1 is pretty serious.
This is exactly why I had enough and started on Smart Mobile Studio. I was forced to use C# on our in-house time app, and thought — I can actually do better than this myself. Hence Smart Pascal was born in company with other programmers experiencing the same.
I know you dont care for JS, so im not trying to get you to switch, but to be perfectly honest — you may want to check out C# until Embarcadero wakes up and smells the roses. I usually wait 1 year before I touch a new version of Delphi (after release date)..
I found that working with phonegap and SMS did the trick for most apps. But SMS is not really compatible with old, pointer based code – and streams doesnt exist in JS (unless you write your own)– so you are sadly stuck with delphi.
I just ordered a new C# book and awaits the day when Delphi + FM has grown up. Then and only then will I go back to buying Delphi. I have stopped at XE3 and move no further unless someone gives me XE6 for free.
I use and love C# as well as Delphi. I have, unfortunately 4.3 Million lines of Delphi Code to deal with and I appreciate that it is lower-level than C#. I’m thinking that I may start a project to cross-compile Delphi to C++ then feed the C++ code to another compiler, like G++. I already have a bunch of reverse engineering code I wrote for a documentation/UML generator I wrote a longggg time ago… so it might not be all that hard to get it to emit C++ code… since Delphi is what I use when I want a bearable low-level experience, I really want Delphi to produce the FASTEST code possible… and I think I’ve decided that the main reason that Delphi isn’t as cast as C++ is primarily due to the lack of the “volatile” keyword (in delphi, any non-local variable is considered volatile… always). In C/C++ the volatile keyword helps the compiler figure out which parts can be optimized. It assumes that everything can be optimized unless marked volatile and therefore the vast majority of calls and variables can be aggressively optimized and there are teams of PhDs out there who contribute practically nothing to the computing world other than their C++ compiler optimization algorithms… so I figure, if I want fast code, I might as well take advantage of what’s already there.
I also write Unity apps in C#. Unity3D is pretty damn cool. C# is the brainchild of the same guy who brought us Delphi… it is absolutely brilliant. The only thing I don’t like about C# is that it is a bit removed from the metal and typically requires a bunch of runtime BS. Although I could invest some time into looking at AOT compilers and writing unsafe code that would make it faster, obviously when I deploy a Unity3D app to IOS I don’t have to install some .Net framework BS with it.
I know 🙂
Started on a GNU CPP compiler myself.
http://quartexpascal.wordpress.com/
Have started to write the RTL (not VCL compatible) and codegen, but still a lot of work left. But ofcourse that includes an IDE as well.
Quartex looks interesting. I’ll check it out. Are you looking for contributors?
I did this app with XE6 some days ago and didn’t experience the sigseg (I have a Nexus tablet and phone). Maybe you want to try it with the Shield (it can be a specific issue), via Play Store or recompiling the source: http://steema.com/wp/blog/2014/07/31/delphi-inspect-simple-free-tool-to-view-firemonkey-and-rtl-system-parameters/
regards
david
Interesting app link, but Nexus isn’t a Shield. Shield’s higher performance specs might be the issue.
from our experience, it appears that if you develop your software for ios, android and windows separately, with their native tools, you still save time compared to xe6.