Embarcadero have blogged about the first Android app “in the wild” (actually, being on the Play store I think it’s the first domesticated app – wild ones surely get side-loaded ? :)). Rather embarrassingly they already have a comment from someone unable to use this “true native Android” application on their actual Android device.
Of course, this isn’t unique to Delphi. There are plenty of apps out there with minimum Android version requirements and particular hardware requirements, but these tend to be driven by particular needs of the applications.
The iOS version was presented at the Auckland World Tour event by the developer, Brian Hamilton, who is a dairy farmer here in NZ. So, having seen the application in question in this instance I can safely say this isn’t one of those applications which pushes the hardware or OS envelope. The minimum requirements fallen foul of by this very simple app look to be those imposed by the Delphi technology (i.e. the FireMonkey runtime), not the needs of the application itself.
This app seemingly isn’t even compatible with my ASUS TF101, although it will run on my even older Galaxy SII (Android 4.1 and 4.2 respectively)
I believe the stumbling block here is the lack of NEON support on my ASUS (or any other Tegra2 device as I understand it) although I haven’t yet run cpuidentifier to find out for sure.
For those interested, Brian Long provided a comprehensive list of the minimum demands of a Delphi Android application. He endorses the recommendation that you get a cheap Android device to test on… if you do, just be careful that it meets the minimum requirements for the FireMonkey runtime – such cheap devices are the ones perhaps most likely to be incompatible with FireMonkey.
Whatever you test on, once you get to the store to avoid frustration for your potential customers/users it might be advisable to state these requirements and provide a link to an app with which potential customers can check their hardware for FireMonkey compatibility, just as Brian Hamilton in fact did.
(Sidebar: I find it interesting that the URL for the iWD app indicates that the App ID is com.embarcadero.iWD …. not such a “wild” app after all perhaps ? ;))
The default package identifier in XE5 is “com.embarcadero.XXXX” where XXXX is the name of your app – Brian (Hamilton) clearly did not change the prefix to something of his own choosing. Eclipse and so on warns you of this but it’s still a common snafu.
Things I have found today using XE5; my iOS app is being used by users in a non-profit on various iPhone 4S and iPhone 5. Three months in…no support calls or problems at all and nothing but positive feedback which I don’t think has ever happened on any Windows-based projects. It’s based on Firemonkey. I’ve also written two using iCL from TMS. I took the Firemonkey one and after a couple of changes where I’d used iOS-dependent code – literally about five lines of code – it compiled and targeted Android, runs fine and looks almost identical. The non-profit are solely using iPhones – several hundred of them – so the Android stuff was largely academic but I intend to resell the app to other non-profits so I do have a purpose in mind. When the app starting running in the simulator and then on my Android tablet (a Kodak tablet running Jelly Bean) I literally whooped for joy like a newbie. Firemonkey may be many things but it does almost mean single code base multiple targets. I do expect to have to tweak a lot between the various platforms but, on the whole, for me, it’s a strategy that has a future.
I tried the same thing a while back using Lazarus and also some Java-based stuff and it was a nightmare.
I don’t give a stuff about which compiler/tool/licencing option I use as long as I can make money off it and satisfy the requirements of the customer – which is kind of the same thing (writing programs for money..in a way a bit of a coding mercenary).
For me XE4 was manna from heaven. XE5 is too new to tell but at the end of the day I write a lot of code which gets put in front of a lot of people so it pretty much has to work without fluff or nonsense or “my compiler is cooler than your compiler” crap.
I’d discuss using the apps under iOS7 but, well, you know…NDAs and all that jazz… 😉
Good for you. Of course, you need to sell a lot of apps to make money if your tool is Delphi. 😉
Delphi’s problems do not stem from “my compiler is cooler than your compiler crap” it’s about fitness for purpose. If your purpose is to sell apps without bothering too much about whether those apps are a “proper fit” on their platforms, perhaps because your users don’t care or are in a vertical market where core function is more important than a comfortable fit in a wider ecosystem of apps, then more power to you.
But if you think you are building on a sustainable platform you are deluding yourself. You are forever beholden to Embarcadero for support on every new iteration of the platforms you support and if your users start to ask for things that Embarcadero’s FireMonkey framework cannot deliver then you are utterly stranded.
On iOS this is less likely because apps on iOS are deliberately kept pretty much to themselves; whether you are confined by an iOS walled garden or a FireMonkey one doesn’t make much difference. A walled garden is a walled garden, so as long as FireMonkey’s plastic flowers look convincing enough and the perfume smells enough like roses, who would know the difference ?
But things are very different on Android. Pretty much the only apps that keep themselves to themselves are games, precisely the type of “app” – the only one – that Google themselves suggest the NDK is suitable for. Not that most Delphi developers getting excited about Android seem to know very much about any of this if their comments, observations and total lack of awareness of the issues they will face is anything to go by.
Embarcadero knew what exactly they were doing when they targeted iOS first. By putting that out the door first they could attract developers to the platform where FireMonkey made at least some sense (or could be made to), and then by the time Android comes around those developers are committed to the FireMonkey runtime with a $ investment to justify.
Without any further comment, compare this with other “weather” apps for Android:
https://play.google.com/store/search?q=weather&c=apps
Not really a fair comparison. The Play store entry for iWD doesn’t do a very good job of explaining what it does, which is to provide access to weather data captured by an internet enabled “Weather Station” device. i.e. to tell you exactly what the conditions are at your home or office or where-ever you have your weather station set up.
Useful for a farmer as I am sure you might appreciate.
It’s not a general weather reporting/forecasting app.
I both agree and disagree. First off, there’s the old “80/20” rule that says 80% of businesses need the same collection of generic functions in their apps. The other 20% need something more customized.
Of those 20%, 80% of them need the types of things that Delphi can offer. The other 20% will need something written in Objective-C (for iOS) or Eclipse/Java (for Android).
There are plenty of solutions around that allow you to address the first batch of apps without ever dealing with Delphi. Your limitations are far more constrained than what Delphi imposes, and there’s way less flexibility. However, as I said, 80% of basic business needs can be satisfied with these solutions. You can charge $1500-$2500 as a “set-up” fee and $100/mo or so. Not a bad return for a few hours of work.
If they need something more custom, the “set-up” fee goes up by a factor of 5 or 10. If they need it, they won’t have any problem paying for it.
If they need a high-performance game and think they’ll be able to hire someone to build it for $1500, or even “you program it and I’ll split the profits with you” basis, good luck to ’em.
Delphi is a tool, like a shovel. You can complain all you want about how poor cheap a flat-edge shovel is at digging in hard soil, or you can just pay a few bucks more for a shovel that’s better suited for the job.
It has never been a “one-size-fits-all” solution, and it never will be.
I don’t get why you continue to blather on about all of its limitations when there’s so freaking much that can be done with what’s THERE! I mean, there will ALWAYS be scenarios you can construct that will justify certain complaints. So what?
I had a friend in college who said he refused to ever buy a calculator with a liquid crystal display because the red LEDs on older calculators provided a way to illuminate your paper in the dark so you could work if the lights went out. He was serious! My only question was, “Can’t you afford a flashlight?”
Is anybody seriously expecting to make real money on apps in the AppStore, either Apple’s or Android’s? As a programmer, that’s not where the money is — it’s in developing apps for people who have money to spend on them, and for whom they can construct a legitimate business case where said apps will give them an advantage in the marketplace. If Delphi works in those scenarios, who care what limitations it has for gamers?
Unless you’re Superman, you need to choose your battles based on the weapons you have at your disposal. There are plenty of battles that Delphi solves, and that it will continue to solve in the iOS and Android marketplaces, even if they don’t fit the majority of people’s needs. There’s more than enough work that can be found that it works WELL for that it’s simply not worth complaining about everything it WON’T do. So why waste your time?
Indeed, and that’s all very well as long as you go in with your eyes open and fully aware of where you are headed – i.e. down a potential blind alley.
The problem is that a large number of Delphi developers seem entirely oblivious to the issues that mobile developers face and are all too eager to swallow the bullshit that Embarcadero are shovelling about Delphi being the be-all and end-all and the answer to mobile developers prayers.
There is another way to apply the “80/20 rule” – as long as your tool can do 80% of everything it could do you may not miss the 20% that it can’t. But in that case where the 20% falls is important. If the 20% that you cannot do is something that you absolutely have to be able to do for your app to be successful then the other 80% might as well be 0% for your purposes. And if you don’t fully understand where the 80/20 divide falls before you start then you risk wasting a lot of time and money finding out the hard way.
Your own comments make my point very well.
The limitations I am “blathering” about are not ones that apply only to game developers. In fact, quite the opposite. Someone writing a game for Android should do very well with Delphi, assuming that FireMonkey performs adequately.
But when your users or potential users say “We’d like to be able to use your camera app to take pictures from another app that we use. Every other camera app we have provides this option – when we ask to take a picture we can choose from any camera app on our device, but not yours. When will you add this feature ?”
Answer (as far as I know): You can’t because that involves implementing a Java class derived from Activity and publishing an Intent Filter which exposes that class as the entry point for particular services. Something you cannot do with the NDK and which the “Java Bridge” does not support (more correctly called the “Java Peephole” – it’s not really a bridge at all, or at best one with a One Way system in place).
Even on iOS I think you can only consumer the ShareSheet just as on Android you can only consume Intents since the same one-way street between the FireMonkey runtime and the host platform applies – you can access Cocoa classes but you cannot create new ones or subclass them and adding application services to the share sheet involves sub-classing the UIActivity Cocoa framework class.
Unless you know better ? In which case I’d love to see a demonstration.
You can write the best damned camera app the world has ever seen and I’m sure you might be able to with Delphi, but if your users can’t get at it through the mechanisms that their mobile devices allow, it will fail.
“you can access Cocoa classes but you cannot create new ones or subclass them”
The Objective-C Bridge dos allow you to create classes that inherit from existing Objective-C classes, which also implies that you can create new ones (which inherit from NSObject). This is more feasible than with the Java Bridge scenario, which cannot do this, probably because at least Objective-C and Delphi code is in the same arena – native machine code – and possibly also because of the message-driven method call metaphor used in Objective-C.
TFMXViewController, for example, in FMX.Platform.iOS.pas implements a class inherited from UIViewController. There are several other examples: TFMXWindow, inherits from UIWindow, TApplicationDelegate (UIApplicationDelegate), ….
Aha, I stand corrected. So I create a Cocoa UIViewController sub-class by declaring:
Yes ? This is how it’s done in Oxygene, for example. 😉
I’m not sure that the use of “native machine code” is a contributing factor given that it doesn’t facilitate the same thing for the Java Bridge/peep-hole. Which would suggest that you can add an Application Service to the iOS Share Sheet by sub-classing UIActivity on Cocoa using FireMonkey but you cannot do the equivalent on Android. Would that be correct ?
No, it’s not quite like that. Objective-C classes are pulled into Delphi as interfaces. And the bridge is functionality that bridges the two languages so is involved in extending an Objective-C class.
You can see how it works by looking at the definition of the cited classes, if you like.
However I take the emoticon to imply you know this anyway.
If by “look at the definition” I presume you mean the source. Since source isn’t provided in the trial you are basically saying “If you want to investigate how Embarcadero’s product works before deciding whether it is right you, please buy it first, then decide.”
Has Embarcadero started offering a No Quibble, Money Back Satisfaction Guarantee ?
As I said, you can always find an exception that you can use to justify your complaints. The problems I run into most of the time are people who are asking for stuff they have no business asking for, rather than stuff that I can’t build with the tools. Like, if the software requires a GPS sensor, they’ll complain that it doesn’t run on devices without GPS sensors on them — never mind that you can still use an external GPS with it. (Or, in the present case, the company’s support people will tell you it won’t run on devices without built-in GPS even though you can use an external GPS but they won’t tell you that, although that’s another story entirely.)
Rather than just complaining about stuff, why not try making a business case to justify how much money you’re actually losing on something, and quantify it so that the Powers That Be at EMBT can see what it’s costing for them to ignore your complaints.
To me, the process of “engineering” is little more than continuously running into brick walls and having to figure out a way around, over, below, or through them. Limitations in the compiler, libraries, run-time environment, etc., are all just part of the ecosystem that we have to deal with. You know that! It’s never going to change. You can find limitations in every other language, platform, and library in the entire universe of programming tools. So what? People hire us to solve THEIR problems. Along the way, we run into our own problems that need to be solved because the path we’ve chosen is rarely as straight and level as we’d liked or hoped. That’s life as a software developer! What’s the point of complaining about it all the time?
For crying out loud, it’s not a “complaint”, it simply a warning bell. Something that anybody believing the marketing crap from Embarcadero really should be aware of before deciding whether it has any validity or not or whether the solution they are offering really is right for them.
The “complaint” is that there are supposedly intelligent, technically literate people who cling to some fantastical notion that any limitation can simply be “engineered around” and refuse to acknowledge very real issues and dismiss anyone that raises them as being “blathering complainers”.
It’s good of you to be so public-spirited – but I don’t get the impression that the newsgroups are full of bleating sheep saying that Delphi is utterly wonderful and all our problems are over. Rather the opposite, in fact.
Most people, I would suggest, are aware that the Delphi solution is not perfect and has limitations. But, at the same time, it does open up a large number of possibilities which were not previously there.
I regret the pricing hikes – if nothing else, Embarcadero are gifted at snatching defeat from the jaws of victory – but as somebody round here commented recently “I have no problem paying more for getting more”.
Newsgroups? I remember those. 😉
I stopped visiting those some time ago. The precipitating factor if I recall correctly was when a dissenting voice was summarily silenced for no reason other than that there was a previous, unrelated history. I forget the details.
And yes, I have no problem paying more for getting more. But here, let me help you remove that tongue from your cheek…. I do have a problem being asked to pay more and not getting more. But perhaps you can point to something in XE5 Pro that justifies a $550 upgrade ? I can’t see anything. The upgrade is in FireDAC and the Mobile Add-On which are not included for Pro. Pro is reduced to being merely the “unlock-code” required to gain access to those things (at further, additional charge).
And I certainly take issue with paying more and getting LESS, as occurred with XE3 for example, when they removed the iOS support in preparation to re-package it in the Mobile Add-On.
You are quite right about the pricing, and I regret my tongue in cheek addition. The pricing is wrong, full stop. I don’t know what they’re thinking. And XE3, as I’ve said before, was an appalling PR misstep.
Embarcadero are doing everything they can, it seems, to get everybody onto Enterprise SA as the minimum. Since that’s where I’ve been for some time, I’ve been shielded thus far from the worst of the pricing fiascos.
“Summarily silenced”? Really? There still seem to be plenty of dissenting voices there…
I still cling to my main contention: Delphi for Mobile is a more viable contender for making sellable apps than you think. Particularly in the Enterprise. Firemonkey is way better than it was. The number of supported devices is large, if some way short of 100%. Being able to re-use data modules and non-visual code is a huge win for many, including me.
>To me, the process of “engineering” is little more than continuously
>running into brick walls and having to figure out a way around,
>over, below, or through them. Limitations in the compiler, libraries,
>run-time environment, etc., are all just part of the ecosystem that
>we have to deal with. You know that! It’s never going to change….
That sounds like Stockholm Syndrome. 🙂 It can change… you just have to stop using the crappy compiler, libraries and run-time environment!
Wow, I just learned something new that hasn’t come up in Delphi marketing materials. No ability to share your app?
What I find interesting is that I believe Qt is also using NDK and they seem to have come up with a way to use Intents… are you sure that Delphi lacks this?
https://git.reviewboard.kde.org/r/108165/
I wasn’t 100% sure no, but nobody from Embarcadero had responded to any opportunity to correct this misapprehension. Having just completed my first Intent Filter endowed app I think you may be able to get some way with Intents with the NDK after all, yes – at least to some extent.
But without any way to define new Activity classes, any and all Intent Filters would I think have to be manifested on the one Activity that is in the app – the main NativeActivity activity. Making the calls necessary for the app to behave correctly and respond to a calling action is going to be quite messy I think (again, no example has been forthcoming).
I will be very short. Years back we invested quite a lot of time into an Windows Mobile application for surveying on the streets. It was made with Delphi for .NET and compact framework 1.0. We did this because we had a lot of code to reuse and we did not have time nor money to rewrite it in C#.
Well today we still have old PDAs with our application and Windows Mobile 6.5. When they stop working we have to rewrite the application from scratch. And it is a fairly complex application and again we do not have time or money to do that.
I will not bite that bullet again, ever. Trust me it is going to happen again. If you ask me today there are only two viable solutions:
1. HTML5 + CSS + JS + Phonegap (replaces that 80/20)
2. XCode / Android SDK if you want to go trully native.
My 2 cents
>Delphi is a tool, like a shovel. You can complain all you want about how
>poor cheap a flat-edge shovel is at digging in hard soil, or you can just
>pay a few bucks more for a shovel that’s better suited for the job.
What if the problem is you paid a premium price for the shovel, then the first time you tried using it the handle snapped in half? One of the biggest complaints around Delphi is premium prices compared to other dev tools while quality control, documentation and features are below average.
>It has never been a “one-size-fits-all” solution, and it never will be.
It was marketed that way. In ads targeting Visual Basic and Access, it was always pushed as the only choice that enabled you to write any kind of standalone program compared to those choices. And the vast majority of (remaining) Delphi users tend to use Delphi almost exclusively, which is an anomaly compared to industry norms today where only 2% report spending more than 50% of their development time in one language.
>I don’t get why you continue to blather on about all of its limitations >when
>there’s so freaking much that can be done with what’s THERE!
Do tell. If you can expound on this, you’ll accomplish something that Embarcadero’s own web page for Delphi fails to do. But again, what is there is marred by poor documentation, unfixed bugs, painful IDE, half-implemented features, poor compatibility with modern standards (we finally get a REST library in 2013?!?), etc. It’s like chastising Jolyon for complaining about the chocolate cake he dropped in the dirt because he’s not listing its positive qualities! 🙂
Now that I think about it, there’s a term that EXACTLY describes your post! It’s “the Curate’s egg”!
http://en.wikipedia.org/wiki/Curate%27s_egg
“In its original context, the term refers to something which is obviously and essentially bad but which is wilfully described euphemistically as being only partly so, its supposed good features being credited with undue redeeming power.”
The Curate’s Egg would be an excellent title for a Delphi blog. 🙂
> I mean, there will ALWAYS be scenarios you can construct that will
>justify certain complaints. So what?
As if one has to construct fanciful scenarios to find any faults with Delphi….
A year ago someone reported that Delphi’s regex performance was in some benchmarks 1000X slower than interpreted Python, which uses the same PCRE C library! The forum users found the cause (really bad code that does a slew of unnecessary Unicode conversions), wrote a patch to fix it, and then opened a bug report that included the cause and the fix. A year later no fix has ever been issued for existing releases and since the bug is still listed as open presumably it affects XE5 as well. That’s not a constructed scenario, that’s one example out of many that could be provided of bugs that stay open for years and in some cases cripple the performance of features. That this was such low-hanging fruit and still wasn’t fixed is impossible to excuse.
>Is anybody seriously expecting to make real money on apps in the
>AppStore, either Apple’s or Android’s? As a programmer, that’s not
>where the money is
Really? Try telling Rovio that. I know more than one person making a living off of mobile apps.
>it’s in developing apps for people who have money to spend on them,
>and for whom they can construct a legitimate business case where said
>apps will give them an advantage in the marketplace.
And who can now hire developers based in India for either 1/3 the price you charge (assuming you’re not in India), or pay the same price and get 3 programmers thrown on the job for your one.
>There are plenty of battles that Delphi solves, and that it will continue
>to solve in the iOS and Android marketplaces, even if they don’t fit the
>majority of people’s needs.
That’s damning it with faint praise, isn’t it? I’m sure there’s got to be somebody, somewhere, who could benefit from it even if there aren’t that many of them?
>There’s more than enough work that can be found that it works WELL
>for that it’s simply not worth complaining about everything it WON’T do.
1) There’s more than enough Delphi work to be found? Where is this mythical land?
2) Again, you seem to believe Jolyon is complaining that it won’t heat up his processor enough to let him toast marshmallows on it, or some other trivialities.
>So why waste your time?
I guess one could ask why you’re here reading this; the answers are probably intertwined.
Free Pascal’s non-managed Android support does not have those requirements that Delphi’s Android support has. One can use it even to compile command line based Android apps and in fact there is a FPC IDE app that even includes a FPC binary for on device compilation (see https://play.google.com/store/apps/details?id=com.n0n3m4.droidpascal ).
Though to be honest we currently don’t have NEON support at all 🙁
Also the support for Android in Lazarus’ LCL is still rather experimental…
Regards,
Sven
I think FreePascal has more of a future with android than Delphi does.
Deltics, why don’t you start using Lazarus and FPC instead of messing around with Oxygen and Delphi?
If you want to see Object Pascal survive and thrive we really need to support Lazarus and Free Pascal and stop making Emborcadaro CEOs and executives rich.
I have converted almost all of my Delphi apps to Lazarus and could not be happier, many of the apps are actually faster on Free Pascal than in Delphi, and not just a little bit faster, a lot faster.
Oxygene doesn’t enrich Embarcadero executives and it is just as much ObjectPascal as Lazarus.
I want to be fair here – there’s enough stuff to legitimately bash EMBT about. 😉 I’m the someone who first reported Google Play store saying my device was incompatible. However, as I followed up, it should be compatible with Delphi for Android. It’s a Samsung Galaxy Player 5, essentially the guts of an old Galaxy S with the phone ripped out and stereo speaker and more codecs added on to turn it into the Android equivalent of the iPod Touch. The CPU is Samsung’s “Hummingbird”/Exynos 3 Single, which Samsung, Wikipedia, and CPU Identifier all say supports NEON. It’s running Android 2.3.5 as well, so it should have everything hardware and software wise.
It’s possible the app creator specified some other requirement (intentionally or not) that’s causing it to be considered incompatible. More people are posting today that their older devices are compatible but their newer ones aren’t! Really weird. It would be nice if EMBT got to the bottom of this, otherwise drawing attention to this app will make the product look bad rather than good. 🙁
I would fall into the category of “older device OK, newer device not”. My Galaxy S2 is compatible although it predates my ASUS TF101 which is not (and definitely is not because it uses the Tegra2 chipset which does not have NEON support).
The number of devices supported by FireMonkey just got even smaller, now that they also require iOS 6 rather than 5.1 as in XE4.
Is the ugliness of this app representative of what is possible with XE5?