I thought I should at least take a look at the amazing Android support in XE5 so I decided to work through the tutorial that was brought to my attention recently. The first order of business of course, is getting installed.
After making a cup of tea, reading a book, doing some housework and making a start on Part 4 of my series of Oxygene for Android camera articles while XE5 installed (not an exaggeration), the first order of business was sorting out the botched install.
This might have been caused by the fact that during the installation I opted to use my existing installation of the Android SDK and only install the NDK, which I didn’t already have (I’ve not needed it for Android development, until now). The installer explicitly gave me this option, and it seemed to make sense since my SDK install was working perfectly well for me. But upon completion of the install neither of the paths to the SDK or the NDK were configured in the Delphi IDE.
I might have expected the SDK folder to be missing, since I didn’t ask the installer to, well, install it. But the NDK was installed by the XE5 installer so this really should have been setup for me, no?
Given that things were already clearly not going to work “out of the box” I decided to take the opportunity to have my NDK setup consistent with my SDK and moved the installed folder to sit alongside the existing SDK.
\\psf\home\GoogleDrive\android-sdk
\\psf\home\GoogleDrive\android-ndk
After specifying these base SDK and NDK paths things still weren’t quite settled. The configuration wizard then complained about the platforms folder (one of the plethora of sub-paths that need to be set for some reason), which I had to manually correct. No biggy.
At last the IDE seemed happy.
Try… Finally
Before jumping in to the tutorial itself, I thought I would try and get an answer to one of the questions that have been steadfastly ignored: Where and how to set permissions and hardware feature dependencies.
I found that application permissions are set in Project Options and the reason they aren’t mentioned in the tutorial is that the ones required by that tutorial (and more!) are all on by default. Which is great if you are writing an app that needs coarse and fine location, to use the camera, read phone state, read and write to the calendar (!?) and read and write storage. If not, you’ll have to remember to turn these off to avoid potential customers wondering why your app needs these things when it clearly doesn’t.
There are pages and pages of permissions to wade through, checking the state of individual checkboxes on each one. There is no concise summary of the permissions you have enabled, just this productivity killing checkbox list overkill of which the Delphi IDE developers seem to have become so enamored in recent releases.
I don’t know whether this checkbox list is platform independent or whether changes to permissions in one platform are automatically applied to the corresponding permissions on other target platforms as he permissions list for the iOS platform was entirely empty, presumably because I had not yet setup an iOS environment for XE5.
Project Options relating to dependency on hardware features do not seem to exist.
Looking for the file I knew was involved (the AndroidManifest) I found one in the build output folder of my project. I deduced that editing this file is no good since it is overwritten by the build process.
Then I noticed the AndroidManifest-template file in the project folder. It’s not listed in the Project Explorer that I could see. But having stumbled across it I divined that I could edit this file to add a hardware dependency which then found it’s way into the AndroidManifest XML as part of the build process.
This was almost identical to the process required in Oxygene except with Oxygene you are simply directly editing the Manifest, not a template fed into a build process. And with Delphi there is no code completion support when editing the template file, perhaps in part because the formatting required for the template results in it not being valid XML. But whatever the reason, the “high productivity” support in this IDE are not to be found in this area and far from being an improvement over Oxygene, or other development tools, it’s not even as good as any half decent XML editor would provide (being an invalid XML file, even using a proper XML editor wouldn’t have helped I don’t think).
But, I have all the permissions I need (and some that I don’t) so it’s time to build this amazing app.
Ah. Problem.
Trying to build succeeded only in getting a cacophony of complaints from the linker:
This all seems to start with a file that cannot be found, specifically:
\\psf\home\GoogleDrive\android-ndk\platforms\android-14\arch-arm\usr\lib\crtend_so.o
Which is very odd, because it is quite plainly where it should be:
From a bit of Googling I gather that this appears to have been quite a common problem at least with older revisions of the NDK, though none of the proposed solutions made much sense since none of them related to the Delphi use of the NDK – obviously. The ones that did make sense didn’t help.
However, the issue in my case was quite simple.
Delphi doesn’t appear to support UNC paths for SDK/NDK locations.
Don’t Use UNC Path For SDK/NDK Locations
The UNC path in this case allows me to conveniently share an installation of the SDK/NDK maintained on my host Mac between all my VM’s (and, by virtue of using a cloud synced folder – in this case Google Drive – also shared with other synced computers)
But using a UNC path in Delphi doesn’t work.
I found this only by trial and error. Oxygene must have some more sophisticated file handling technology not available to the Embarcadero developers because this causes no problem for that tool. Perhaps some important information about not using UNC paths was in the “Getting Started for Android” video presented on the Delphi XE5 start page ?
At this point I didn’t know since the IDE provided no way for me to view that video due to the lack of Flash or HTML5 video support in the embedded browser.
I do all my web browsing on the Mac host so I don’t bother maintaining an up-to-date browser in my VM that I don’t need.
Wouldn’t it be a good idea to provide an accessible link to the video in question to cover this sort of situation ? Then users wouldn’t have had to go digging through the HTML source for the start page to find it. But go digging I did and found the link to the youtube video. Luckily my internet connection was up, so I was able to watch the video but it turns out that there was no mention of UNC path problems anyway. Hey ho.
It was indeed fortunate that my intuited solution turned out to be correct or this could have taken up more time than it already had.
Although the UNC path is convenient since it is certain to be the same in all my VM’s, each VM also has a drive mapped to the \\psf\home volume so I just changed the paths to use the drive mapped path appropriate for this VM and the problem was solved.
I could build.
But I couldn’t run of course, since FireMonkey isn’t supported on my device and I had better things to do than deal with the cumbersome emulator support.
It’s so much easier when you can use an Android development tool with all Android resources natively, such as debugging in an x86 VM or running on any Android device that meets the needs of your application without the demands of a hefty runtime to also support.
It makes developing apps so much faster. 😉
For me though, this was the practical end of my first look at Delphi for Android.
I was able to obtain one further interesting fact at this point however.
HOW Big ?!
Another question that has been determinedly ignored is that of the size of the executables produced by Delphi for mobile devices. For Android at least I can now find this out for myself.
An “Empty App” project in Delphi XE5 compiles to a debug build of an SO file that is 48 MB in size. The Java stub that is wrapped around this to form the APK “envelope” might add a little more.
Update: Having now set up an emulator and deployed a debug build to that, I find that far from growing, the actual APK seems to shrink and on the (emulated) device is reported as 24.4 MB.
You might want to go back and read that again. It’s not a typo. 24.4 MEGABYTES
For what is not even a Hello World app.
By contrast the debug build of my camera app in Oxygene compiles to an apk of a whopping 48 KB. That also is not a typo: 48 KILOBYTES.
An app that does something useful which is 3 orders of magnitude smaller than an app that does literally nothing.
Does anyone else remember when Delphi could hold it’s head up high and rightly claim that it had no runtime dependencies other than the OS itself ? VBRUNx00.DLL was a source of great amusement. With FireMonkey not only is there a whopping great runtime engine, but you aren’t even able to share it (the standby defence of the beleaguered VB developer back in the day) between multiple FireMonkey applications on the same device.
Every FireMonkey app essentially comes with an embedded FMRUNx00.DLL
Oh how the mighty are fallen.
Size DOES Matter
Although time has marched on and such file sizes are not really significant for desktop applications, in the mobile device world size is important.
Both Google and Apple stores have limits on maximum executable file size.
In the case of Google you are limited to 50MB plus additional download packages which can be up to 4GB. But your executable must be under the 50MB limit.
In the case of Apple, your application executable is limited to 60 MB. In addition, if it is over 50MB users/customers will only be able to download it over wi-fi. If they are on a mobile data connection and your app is bigger than 50MB they are likely to just choose someone else’s, smaller app.
Of course, 24 MB is the debug build. A release build is smaller. Much smaller. The unsigned APK is just still 21.49 MB in size. So only 2 orders of magnitude bigger than the debug build of a functioning camera app.
21.49 MB 5 MB for an app that doesn’t do anything is perhaps a bit better, but how quickly does that grow as you add capability ?
Update: There is clearly something odd going on. Since I posed my original findings, based on looking at build products, I received comments suggesting different figures. I repeated my simple builds, deploying the resulting APK’s to an emulated device and found starkly different sizes were reported by the emulated device than the size of the build products would have suggested. The debug build was half the size, but the release build was now not much smaller than the debug build. I am also told that others have started to voice concerns about application size in the Embarcadero forums, so there is an issue. Reliably quantifying it is proving elusive. Which is itself something of an issue.
In the meantime, this makes the size of an actual, released app, as reported by the Google Play store perhaps our only reliable indicator so far.
The iWD app that Embarcadero are showing off in the Play store initially weighed in at 10 MB. After a handful of bug fixes and tweaks it has now grown to 12 MB.
Store app size limits are increased from time to time, but not very often and not – historically – by much. Only time will tell whether FireMonkey apps will reach a level of functionality where their size becomes problematic in this respect.
But that is only one factor. Another is that some devices have limited storage which cannot be expanded. Some of them are even quite popular. I know, shocking isn’t it ?
Another is that if you are hoping to win impulse customers purchasing your app, even only relatively hefty downloads is a potential obstacle.
First Impressions
First impressions last, as they say.
This has to be one of the worst first impressions experiences with Delphi since… well… ever.
Ya, I won’t be getting xe5, going to stick with Lazarus.
Normally i’m very optimistic, but recently i’ve becoming a Delphi pesimist. Thank god there’s lazarus and c#. I think embarcadero is overestimating their customers. so sad.
underestimate was the word i was looking for. sorry
Either works: They overestimate our gullibility and underestimate our intelligence. 😉
“Delphi doesn’t appear to support UNC paths for SDK/NDK locations.”
Haha, I was thinking “oh-oh” to myself when I saw your UNC paths first in your post, then was surprised when you didn’t mention any problems with these =D
The few short weeks I’ve spent with Visual Studio and Oxygene have already spoiled me I guess. I must remember to switch back to 1990’s expectations when working with the Delphi IDE. 😉
Having said that, the Delphi syntax highlighting configuration still knocks the Visual Studio equivalent into a cocked hat. 🙂
IOUtils have UNC part broken. I provided a fix for it in QC 107399 short before XE3 release. Well, the fix is stil not applied. We live in internet world, all LANs are deprecated 🙂
thank you again for showing all the problematic you find.
Your “reports” are always very valuable to us.
We are going to stick with XE4 which is used in our cases for quick desktop test programs and from time to time for connecting to db which are the only things we need from Delphi..
Delphi has always had runtime dependencies, they just happen to be linked directly into the binary by default. In fact most languages have runtime dependencies, the difference being that these dependancies happen to be deployed with the OS’s. Visual C++, .Net, Java are all good examples.
IMO it isn’t specifically that Delphi requires a Runtime thats a big problem, its the size of the runtime and the lack of OS support to register single copies of runtimes (at least for iOS and Android). If either or even both of these issues could be addressed, it would (at least for me) be an negligible issue.
Interesting. Do you have a particular timeframe in which you expect Embarcadero to have achieved this envisaged/wished for dramatic reduction in FireMonkey runtime size and/or secured the co-operation of Google and Apple ? 😉
I did say if they “could”, not that they would or will. I don’t hold out much hope that that will be addressed in any manner (at least not in the near future, unless maybe if there are massive complaints). Interestingly there have been a number of people “talking” about the size issues recently, even questions to EMBT staff from user group members.
I don’t believe Google and Apple would ever do that. Whoever, that doesn’t mean that in a perfect EMBT World that it wouldn’t help Firemonkey Developers. That does however take us back to the argument of the choice by EMBT to use the Firemonkey framework in the first place 😀 haha
The problem is that no matter how many people complain or how loudly, there is a limit to how far you can squeeze a framework that has to do everything that the FireMonkey approach is forced to take on.
AFAIK it won’t be possible for iOS, since this OS does not allow dynamic linking.
I would also not be surprised you won’t have the possibility for Android either.
Both try to sandbox all applications, to avoid security issues.
Perhaps a background service? Not easy….
>Which is great if you are writing an app that needs coarse and fine
>location, to use the camera, read phone state, read and write to the
>calendar (!?) and read and write storage. If not, you’ll have to remember
>to turn these off to avoid potential customers wondering why your app
>needs these things when it clearly doesn’t.
You probably solved the riddle of why my Android media player can’t run that Delphi weather station program. Not having a phone, my device can’t read the phone state. 🙂 I’d figured it was probably something to do with application-specific permissions, and this “everything on” approach would probably account for it if the developer did indeed forget to change anything from the defaults (and since it seems it was rushed out the door that’s very likely).
In a review of a release of the Gentoo Linux distro, the English-as-a-second-language author wrote “What Gentoo is lacking is – love.” This made me laugh at first as I realized he meant “polish”, but on second thought I realized “love” really does fit. There were so many areas of that release where things felt neglected: a link to the settings configuration tool was left off the menu system (not fun for those of us trying Linux seriously for the first time), some broken help links, etc.
That’s what Delphi feels like today. It’s lacking – love. There’s just so many areas where a little polish would go so far. It feels like the stereotype of open source programs of old: functional but feature-incomplete, often clones of other software/lack of innovation, little documentation, gruff developers with non-existent support only working on what interests them rather than what the users want, with users being viewed as a nuisance.
It can be quite the culture shock trying another development tool for the first time and being given the “white glove” experience, where it feels like everything is about catering to your needs and so many little touches add up to the impression that they really understand you and your needs (and in fact anticipate them).
I’ve heard a lot of talk about mobile “bringing back Delphi users”. I think the people making this argument are underestimating the lack of appeal in moving from a tool filled with polish to one with all of Delphi’s rough edges and flimsy parts. No one at Embarcadero seems to have heard of the expression “You never get a second chance to make a first impression”.
That may be it indeed.
But you can’t really expect developers to get to grips with such platform related issues when using a tool that has been sold to them specifically on the basis that they won’t need to understand platform issues or differences. As long as you have managed to cobble together an app that works on one device, you can just recompile it to run on any other (supported) device.
It is just that easy, right ? 😉
Does that mean that you never used the VCL and all your Delphi Windows apps are/were written with Windows API calls? 🙂
I haven’t thought that they are selling Delphi that way as I understand that I need to understand platform differences for things like UI conventions/guidelines and using platform specific functionality when necessary. Just because I’m happy using Delphi doesn’t mean I don’t read books on Android and iOS development.
I don’t think using Delphi means that I won’t need to understand platform differences but it makes sense for me to only worry about that when I need to.
You may understand that, but that is not how the product is being sold.
I don’t know why your .apk file ends at 48 Mb. Mine (which is far more than a simple “Hello, World” program, but still rather simple) ends at 5.5 Mb. Quite a bit of difference, eh? It has two forms, several buttons and input fields, and code to persist the entered values between sessions, as well as some HTTP support.
I should have read on :-). Your release build is about the same size as mine. But my Debug build is also around 5.5 Mb in size. How come your is so much bigger (and I am talking about the program, not anything else 🙂 )
I don’t know. I was looking at the so file in the build products of my project, not an apk on a device.
Could there be an explanation in there somewhere ? I can have a look later and see if I did (or rather failed to do) something stupid.
My Debug .so is 28 Mb, and my Release .so is 17.5 Mb.
I just set up an emulated device and it’s odd. The SO is definitely 48MB but the deployed debug APK is only 24.4 MB I’ve updated the post and will check the size of the “release” build as well.
Ok, this is getting bizarre. Using the default “Release” configuration deploys that same empty application with an APK of 21.49 MB. I made sure to uninstall the previous debug build from the emulated device first.
Very weird.
Some of the confusion might be cleared up by realising that the .apk file compresses some of its content. So in my case, a 17MB .so is packaged up with the Java dex code and any assets into a 5.5MB .apk file. When installed onto the device, the OS extracts the .so back out so it can be executed appropriately, so the reported size swells again.
So there is a difference betwen the app size as per your device report, the .apk size and the .so size.
Your comments about an APK size of 21.49MB etc, I can’t clear up, as I’ve not seen APK files anywhere approaching that size.
Yep, I figured something along those lines might be going on which is why I decided to setup an emulator and see what an actual (albeit emulated) device reported as the application size. Could it be that the emulator is also doing something a bit weird ?
I shall repeat the exercise using my phone and see what an actual, physical device reports.
There was talk on the forum about switching something from debug to release and things not actually being switched and having to do it manually. Sorry I don’t remember the details, but you might want to check that just because it’s been switched to “Release” configuration that it’s actually giving you a release build. That seemed to be the complaint (albeit for a desktop program).
The thing that clinches it for me is that Delphi has a fully integrated visual designer, whereas with Oxygene (as far as I can see), you have to muck around in .xml files to design your forms. The whole point of RAD is that you don’t have to do this kind of work (which is also why I’m not that interested or impressed by WPF for C# and still prefer Windows Forms).
True. Although form designers do exist for Android (I haven’t tried any yet – they may be useless). Just as with iOS I can use Xcode Interface Builder with Oxygene (and have done). It may not be “fully integrated” but with Xcode running on the host Mac with Oxygene in my Windows VM, it’s not that much different than the days of the floating form designer that we enjoyed (and some still prefer) up to Delphi 7, and that was still considered “RAD”. 🙂
But if/when a super-duper Android form designer does come along, I can just start using it if I find it preferable to XML (highly likely!). 🙂
But the point of RAD is not actually to have a visual form designer. That’s the point of WYSIWYG. The point of RAD is high productivity, not how pretty the form designer is.
Well, mucking about with .xml files instead of a visual designer certainly slows me down (or it would, if I ever decided to use an IDE that didn’t include a visual designer), thus eliminating the “Rapid” part of RAD.
Therefore – for me – an essential part of RAD *is* an integrated visual designer… 🙂
I think you missed the part where you have visual form designer options even when the underlying file format is XML. I just havent explored those yet so cant really comment. 🙂
But yes. XML editor vs form designer to create 1 simple form. No contest.
To create, and to maintain, the different form designs when the design is inextricably connected to the code it drives vs XML which is bound to code automatically at runtime… different altogether and there I think an XML editor will edge out the FireMonkey forms designer if not beat it into a cocked hat. Using productivity as a measure.
Fun ? Pleasure ? Enjoyment ? Different measures entirely, and there I will give the thumbs up to the form designer as well. 🙂
Spend some time creating the UI assets required to support different devices and different form factors using the FireMonkey framework and get back to me with how much time it costs you. 😉
That may be. My experience with mobile computing is still at the beginner’s stage. But my first application had no problems auto-adjusting to various screen sizes (phone vs. tablet) and Portrait/Landscape mode, just with the use of panels and anchors, so at this stage in my development, I don’t see it as a problem-to-be.
I may, however, be proven wrong about that, as I gain more experience :-).
The issue isn’t adjusting to different sized devices, as in re-flowing, re-sizing etc. It’w when a larger screen supports a completely different layout that makes better use of the greater screen real estate available, but driving the same functionality.
It is interesting to note that – as I understand it – experienced Android developers tend to prefer working directly with the XML. Go figure. Maybe they are just masochists. They are using Java after all. 🙂
> I think you missed the part where you have visual form designer
> options even when the underlying file format is XML.
No – I didn’t miss it. But unless the visual designer is fully integrated into the IDE, it only helps some of the way. If I can’t double-click on a button and get into my code editor at the event code for OnClick of the button, then it isn’t integrated (enough) for my taste.
Your choice. Others would say that the only code behind an OnClick event should be a simple invocation of an appropriate controller and not worth having direct access to. But I understand what you mean. 🙂
Incidentally, I wasn’t sure whether I had replied to one of the comments you wanted deleting and which one you’d prefer I left. It’s perhaps a bit redundant I know, but I’ve left both as they were and just deleted the post where you asked me to delete one of them. If you follow.
I hope it doesn’t crash the internet. 🙂
My “integrated” was not in contrast to “floating”, but should be read as “fully supported and integral part of the IDE”.
Also, a visual designer – to me – is much more efficient and quick-to-use than mucking about in .xml files. After all, RAD stands for “RAPID Application Development” (my emphasis), and if something makes it quicker to develop applications, it is certainly a part of RAD.
A visual designer is there a huge part of what I understand a RAD IDE, and any IDE that doesn’t have one is not – IMO – a true RAD IDE.
Sure they exists. Google has now official RAD free as in beer studio:
http://developer.android.com/sdk/installing/studio.html
Its still in development but you can play with it. That aside I am not a fan of visual designers. I like to have total control over the layout, it happens way to often that designers do things their own way and I don’t like that. But I have to add that Delphi VCL designer is one of the best ones I tried, so I can’t complain there.
For HTML / JS / CSS development I just use my favorite text editor.
Hello Iztok:
>> For HTML / JS / CSS development I just use my favorite text editor.
Out of curiosity, could you tell us which text editor is your favorite?
Concerning the size – because of the overwhelming number of successful firemonkey apps 😉 Apple recently decided to increase the download limit while using a mobile connection. http://news.cnet.com/8301-13579_3-57603562-37/apple-quietly-doubles-cellular-app-download-limit-to-100mb/?part=rss&subj=news&tag=title
I’m sure this will also be done by Google.
The over-the-air download limit is a separate limit that applies to the entire application bundle, executable + data. The limit on executable size is separate. Previously the over-the-air limit was 50 MB even though the max executable size was 60 MB, which was always a little bit odd.
Did they also increase the maximum executable size ? (I haven’t yet looked myself)
I understand 5/5 your negative attitude against EMBARCADERO’ s philosophy. First because i think i gave to much money to support their work and it’s seem no investissement return for delphi communuty is planned. Second, because i’ve been a Mac Plus developper (Think Pascal and Think C) in the early beginning of Apple: i know how companies like Apple has built their “toolbox” with open contributions from developpers and, now, has closed the door as they close the box.
Jolyon, there rcently was a post by EMBT marketing lead: blogs.embarcadero.com/vsevolodleonov/2013/09/19/are-you-asking-about-app-size-by-delphi-for-android/
In russian forum that triggered discussion on two topics
1) How professional it is for “Chief Evangelist” to deride users concerns (even be them irrational and silly) rather than disagreeing in a less expressive yet more polite manner, at least in his official corporate blog.
2) How reliable would be seen a promoter, who obviously is not fluent in English, or it seems to me he is not (Ask you wife to write a short text in Ukrainian or Russian, then mechanically substitute English words without rebuilding the structure of sentences themselves).
You may be considered both native-speaker and part of Anglo-Saxon business tradition, May you evaluate this concerns ? Are they real or did we overthought it ? Question is not about the actual message of mr. Leonov but about what effect this message should cause upon EMBT public image in westerners’ eyes.
Thank you.
Delphi IOUilt unit, TPath class, has borken support of UNC paths. I put QC 107399 on this. I wonder if that si the reason…
Hi!
Load the FlashLight sample app. Then open the project source and comment out line 14.
//System.StartUpCopy,
Then add
{$D1}
above {$R *.res}. This will shorten compile time. I’m not sure what this compiler directive does. Perhaps it’s all wrong.
Then you change to Release and build the app. You will end up with an apk that is about 6.5 MB (still huge I know). Now the app loads quicker to.
I think Embarcadero needs to optimize both apk size and load times. At least we need a way to start with an image (splash) that gives the user the feeling that the app loads quick. I haven’t digged a lot into System.StartUpCopy but if it’s needed at all, we should have the option to call the Initialization part of it at a later time.This unit slows loading down.
I’ve been using Delphi since 1995. I’ve seen the bloating add upp. But if your building corporate apps you have a upper hand with XE5 since you can build for many platsforms with DB support all with one devtool. That’s not a lot of other devtools that can do that.
I’d say that XE5 is not for building hard core über nice apps that makes the top ten in Google Play. It’s for all the other times when you need to go mobile, but don’t have the time to learn all different OS versions from scratch.
Nice article by the way, thanks.
Best regards,
/PB