{"id":1670,"date":"2013-09-19T11:32:59","date_gmt":"2013-09-18T23:32:59","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1670"},"modified":"2013-09-19T18:50:35","modified_gmt":"2013-09-19T06:50:35","slug":"first-impressions-of-xe5-for-android","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1670\/","title":{"rendered":"First Impressions Of XE5 for Android"},"content":{"rendered":"[Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span>

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.<\/p>\n

<\/p>\n

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<\/strong> an exaggeration), the first order of business was sorting out the botched install.<\/p>\n

This might have been caused by the fact that during the installation I opted to use my existing installation of the Android SDK<\/strong> 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.<\/p>\n

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<\/em> installed by the XE5 installer so this really should have been setup for me, no?<\/p>\n

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.
\n
\n\\\\psf\\home\\GoogleDrive\\android-sdk
\n\\\\psf\\home\\GoogleDrive\\android-ndk
\n<\/strong><\/p>\n

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.<\/p>\n

At last the IDE seemed happy.<\/p>\n

Try… Finally<\/h3>\n

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<\/strong>.<\/p>\n

I found that application permissions are set in Project Options<\/strong> 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<\/strong>. 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<\/em> to avoid potential customers wondering why your app needs these things when it clearly doesn’t.<\/p>\n

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.<\/p>\n

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. <\/p>\n

Project Options relating to dependency on hardware features do not seem to exist.<\/p>\n

Looking for the file I knew was involved (the AndroidManifest<\/strong>) 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.<\/p>\n

Then I noticed the AndroidManifest-template<\/strong> 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<\/strong> XML as part of the build process.<\/p>\n

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).<\/p>\n

But, I have all the permissions I need (and some that I don’t) so it’s time to build this amazing app.<\/p>\n

Ah. Problem.<\/p>\n

Trying to build succeeded only in getting a cacophony of complaints from the linker:<\/p>\n

\"OK!<\/a>
OK! I GET IT!<\/figcaption><\/figure>\n

This all seems to start with a file that cannot be found, specifically:<\/p>\n

\\\\psf\\home\\GoogleDrive\\android-ndk\\platforms\\android-14\\arch-arm\\usr\\lib\\crtend_so.o<\/strong><\/p>\n

Which is very odd, because it is quite plainly where it should be:<\/p>\n

\"Peek-a-boo\"<\/a>
Peek-a-boo<\/figcaption><\/figure>\n

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<\/strong> make sense didn’t help.<\/p>\n

However, the issue in my case was quite simple.<\/p>\n

Delphi doesn’t appear to support UNC paths for SDK\/NDK locations<\/strong>.<\/p>\n

Don’t Use UNC Path For SDK\/NDK Locations<\/h3>\n

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)<\/p>\n

But using a UNC path in Delphi doesn’t work.<\/p>\n

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 ?<\/p>\n

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.<\/p>\n

\"Computer<\/a>
Computer says “No”<\/figcaption><\/figure>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/strong> volume so I just changed the paths to use the drive mapped path appropriate for this VM and the problem was solved.<\/p>\n

I could build.<\/p>\n

But I couldn’t run<\/strong> of course, since FireMonkey isn’t supported on my device and I had better things to do than deal with the cumbersome emulator support<\/a>.<\/p>\n

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.<\/p>\n

It makes developing apps so much faster<\/em>. \ud83d\ude09<\/p>\n

For me though, this was the practical end of my first look at Delphi for Android.<\/p>\n

I was able to obtain one further interesting fact at this point however.<\/p>\n

HOW<\/strong> Big ?!<\/h3>\n

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.<\/p>\n

An “Empty App” project in Delphi XE5 compiles to a debug build of an SO file that is 48 MB<\/strong> in size. The Java stub that is wrapped around this to form the APK “envelope” might add a little more.<\/del><\/p>\n

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<\/strong>.<\/p>\n

You might want to go back and read that again. It’s not a typo. 24.4 MEGABYTES<\/strong><\/p>\n

For what is not even<\/em> a Hello World<\/strong> app.<\/p>\n

By contrast the debug build of my camera app in Oxygene compiles to an apk of a whopping 48 KB<\/strong>. That also is not a typo: 48 KILOBYTES<\/strong>.<\/p>\n

An app that does something useful which is 3 orders of magnitude smaller than an app that does literally nothing<\/em>.<\/p>\n

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.<\/p>\n

Every FireMonkey app essentially comes with an embedded FMRUNx00.DLL<\/strong><\/p>\n

Oh how the mighty are fallen.<\/p>\n

Size DOES<\/strong> Matter<\/h3>\n

Although time has marched on and such file sizes are not really significant for desktop applications, in the mobile device world size is<\/strong> important.<\/p>\n

Both Google and Apple stores have limits on maximum executable file size.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Of course, 24 MB<\/strong> is the debug build. A release build is smaller. Much smaller.<\/del> The unsigned APK is just<\/del> still 21.49 MB<\/strong> in size. So only 2 orders of magnitude<\/em> bigger than the debug build of a functioning camera app.<\/del><\/p>\n

21.49 MB<\/strong> 5 MB<\/del> for an app that doesn’t do anything is perhaps a bit better, but how quickly does that grow as you add capability ?<\/p>\n

Update:<\/strong> 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.<\/em><\/p>\n

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. <\/em><\/p>\n

The iWD app that Embarcadero are showing off in the Play store<\/a> initially weighed in at 10 MB<\/strong>. After a handful of bug fixes and tweaks it has now grown to 12<\/em> MB<\/strong>.<\/p>\n

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.<\/p>\n

But that is only one factor. Another is that some devices have limited storage which cannot be expanded<\/a>. Some of them are even quite popular<\/a>. I know, shocking isn’t it ?<\/p>\n

Another is that if you are hoping to win impulse customers purchasing your app, even only relatively <\/em>hefty downloads is a potential obstacle.<\/p>\n

First Impressions<\/h3>\n

First impressions last, as they say.<\/p>\n

This has to be one of the worst first impressions experiences with Delphi since… well… ever.<\/p>\n","protected":false},"excerpt":{"rendered":"

[Estimated Reading Time: <\/span> 8<\/span> minutes]<\/span><\/span> 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.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[212,4],"tags":[153,292,219,208],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-qW","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":1452,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1452\/","url_meta":{"origin":1670,"position":0},"title":"XE5 News: Coming in September, With Android Support","date":"09 Aug 2013","format":false,"excerpt":"The word is out. XE5 will be coming this September, as described in the announcement of a tour of Russia to promote the new release. Translation: Dear developers! Traditionally, in September we are launching a new version of RAD Studio, this year has been for us an exception, as we\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1601,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1601\/","url_meta":{"origin":1670,"position":1},"title":"iOS 6.x Now Required By FireMonkey in XE5","date":"14 Sep 2013","format":false,"excerpt":"In XE4 FireMonkey supported iOS 5.1. According to the platform requirements for XE5 this has now increased to iOS 6. This something to be aware of. Even if your application could run on older, simpler devices, the FireMonkey runtime has demands of it's own, over and above those of any\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1554,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1554\/","url_meta":{"origin":1670,"position":2},"title":"Not so Special Upgrade Pricing for XE5","date":"12 Sep 2013","format":false,"excerpt":"XE5 is officially out today, and the online store now has pricing for the new release. Being a scant 6 months since XE4 was released, with a $49 special upgrade price for XE3 Pro customers, I looked to see what special price might be on offer for XE5. $499 is\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1713,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1713\/","url_meta":{"origin":1670,"position":3},"title":"How to Call Java Code from an Oxygene Android Application","date":"20 Sep 2013","format":false,"excerpt":"Lachlan just posted a link to a post on Google+ (also available as a PDF) demonstrating how to call Java from Delphi XE5. I was shocked at both the amount and the nature of the code involved. It is long, convoluted and ugly stuff (nb. that isn't a criticism of\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1525,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1525\/","url_meta":{"origin":1670,"position":4},"title":"RAD Studio in Auckland \/ Android in a VM \/ Touchy Feely","date":"30 Aug 2013","format":false,"excerpt":"Well, not really RAD Studio as such, more like Mobile Studio (whether as part of RAD Studio Ent+ or the Mobile Add-On) since everything shown was oriented around the Android support and emphasising the fact that an application written for iOS can simply be recompiled and will run on Android.\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"Androidx86","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Androidx86-1024x608.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1974,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1974\/","url_meta":{"origin":1670,"position":5},"title":"Improved Quality in Delphi – Yeah Right","date":"28 Oct 2013","format":false,"excerpt":"Here in Aotearoa there is a beer company called \"Tui\", named in turn for a native bird. As well as a series of TV ads voiced by the great Tom Baker, Tui are famous here for their \"Yeah, right!\" billboard ads. I felt compelled to make one for Delphi. I\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/tui.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1670"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=1670"}],"version-history":[{"count":21,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1670\/revisions"}],"predecessor-version":[{"id":1696,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/1670\/revisions\/1696"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=1670"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=1670"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=1670"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}