7

I have developed a few Android apps with Android SDK using Java and now that XE5 is out and i am a very experienced Delphi developer i tried a few samples off android apps and my impression is that android apps designed with XE5 runs very slowly, they start very slowly, almost 4 secs with a black screen, that ruins the whole experience.

I know XE5 Android apps run in native code, one more reason for this not happening, they should be extremely fast

Is there anything i can do about it?

I am using a Samsung Galaxy S2 to test, so it's not about the testing equipment.

RRUZ
  • 134,889
  • 20
  • 356
  • 483
Mike
  • 73
  • 1
  • 1
  • 3
  • 3
    Wait until you ask users to download the app. See how large it is!! – David Heffernan Oct 09 '13 at 16:14
  • Are you talking about while developing/debugging, or when actually running release apps? I have a Galaxy S3 (Android 4.1.2) and a Nexus 7 (Android 4.3), and most things compiled for release load in just a fraction of a second (there's a noticeable black screen for a moment, but it's a very brief time). Debugging performance, OTOH, is pretty poor compared to Basic for Android or the brief time I've spent in Oxygene (although that's been very brief). Delphi does have the advantage of being a single codebase for both Android and iOS in its favor, though. – Ken White Oct 10 '13 at 01:56
  • 2
    Single codebase for sure. But native nowhere. – David Heffernan Oct 10 '13 at 07:15
  • 1
    @David: Where did I say "native"? It's a weights/measures thing. If native code is important to you, write your app twice (Java/XCode). If a single codebase for ease of development is more important, use Delphi. It depends on your own priorities. Whinging on here about not being native or app size is just noise, just like it is complaining that Delphi is not as efficient as writing in assembly. If you have to do Windows development, you weight for yourself whether the ease of use of Delphi is more important than writing asm. – Ken White Oct 10 '13 at 12:47
  • @KenWhite And if being native to the platform is important, don't use Delphi. And if having an app size that allows for reasonable over the air download, don't use Delphi. If you want single source codebase for iOS and Android, then Delphi is a viable candidate. It depends on your own priorities. – David Heffernan Oct 10 '13 at 12:50
  • @David: Every bit of which I **just said** in my prior comment, except the size (about which you have already complained). "If native code is important, use Java/XCode. If a single codebase...is more important, use Delphi." seems to cover it, as does "It depends on your own priorities." (quoted from my last comment, not yours). What did repeating everything that's already been said again fulfill for you? – Ken White Oct 10 '13 at 12:57
  • @Ken I agree with all that and added a whine about app size. My comment was not addressed to you and I don't understand your reaction. Why take it personally. Chill out man! – David Heffernan Oct 10 '13 at 13:01
  • @David: Not taking anything personally. Just don't understand the need to repeat everything I had already said immediately after I said it. It seems to me that simply whinging on and on is the equivalent of a language war, except I don't understand why you're doing it considering you use Delphi. (Are you even using it for Android/iOS development at all? I don't recall having seen you mention it anywhere.) And your comment was addressed to me: "Single codebase for sure. But native nowhere." is clearly addressed to me; it follows the only comment about single code base here (mine), right above. – Ken White Oct 10 '13 at 14:03
  • @KenWhite You think I should say "Delphi is great" because I use it? – David Heffernan Oct 10 '13 at 14:10
  • @David: Of course not. I'd expect you were familiar enough with it to understand what they've done in a short time to take it from Win32 native to several different platforms with virtually the same code base, and appreciate the effort instead of just complaining constantly (again, with no indication that you're even using it or doing Android/iOS dev work). It's reminiscent of the VB bashers in the recent past, IMO. There is a major gain in being XPlatform with one code base, and IMO the trade offs are worth it. – Ken White Oct 10 '13 at 14:57
  • @KenWhite I am impressed with their compiler work. I am singularly unimpressed with FireMonkey. It's quality is dreadful. Am I allowed to criticise it? – David Heffernan Oct 10 '13 at 14:59
  • @David: Of course you are. In the context of FMX itself, I wouldn't even disagree. My disagreement is with your attitude that all of the XPlatform support stinks (which you keep going on about here). For single source, Win32/64/OSX/iOS/Android, it's the only option I'm aware of at all, and that's worth some of the tradeoffs in size and lack of real native support (to me, anyway). – Ken White Oct 10 '13 at 16:28
  • @KenWhite Everyone has to make their own minds up. Single source may be important to some. App size may be important too. So long as you have the information, you can decide what trade off is right for you. – David Heffernan Oct 10 '13 at 16:29
  • @David: Which I've agreed with twice before when you said it. :-) See my first comment to you above ("It's a weights/measures thing.") – Ken White Oct 10 '13 at 16:32
  • @KenWhite So, we are in agreement. Good. – David Heffernan Oct 10 '13 at 16:33

1 Answers1

8

They are a bit slow to load due to the size of the native library that is loaded into memory to run.

Make sure you are running a release build on a new, capable device and it's not so bad.

But you'll always have a large native library, as things currently stand.

One possible course of action is to distract the user by use of a splash screen. This, however, is not straightforward. However it is feasible. It will be documented somewhere or other in a week or so.

blong
  • 2,145
  • 13
  • 23
  • 2
    This is a deal breaker, users don't want an app that starts in 4secs, even google says this: "Generally, 100 to 200ms is the threshold beyond which users will perceive slowness in an application" so i guess i will wait for a decent Delphi for Android development and stick with Eclipse and Java – Mike Oct 09 '13 at 13:37
  • If you like Pascal, but don't like the Delphi solution, do try out a trial edition of Oxygene for Java from RemObjects. That directly targets the Dalvik VM and works exactly like Java, however the language is Object Pascal, and the IDE is Visual Studio. If interested, there's an 18 month old getting started tutorial for it at http://blong.com/Articles/OxygeneForJavaIntro/OxygeneForAndroid.htm – blong Oct 09 '13 at 13:41
  • Thanks blong i will check it out, i really like Object Pascal :) – Mike Oct 09 '13 at 13:46
  • We use FireMonkey for Windows/Mac, but we develop natively for iOS/Android. – Marcus Adams Oct 09 '13 at 14:50
  • Is there a sample "Hello, World!" compiled delphi sample app on the play store, or something else simple that I could download to try? I'm intrigued, maybe enough to purchase the XE5 mobile pack thing, but not if it's going to be too bloated and slow to be marketable. – Chris Thornton Oct 09 '13 at 17:44
  • 2
    Chris Thornton, here is an apk that i compiled from a XE5 sample, https://www.dropbox.com/s/rkshm1u7gx7bijr/com.embarcadero.SampleListViewMultiDetailAppearanceProject-1.apk – Mike Oct 09 '13 at 17:58
  • Thanks @Mike. 6MB wow. I see the blackscreen delay, and it's actually 4-5 seconds for me, likely due to the "Lookout" (security) scan on my GS3. – Chris Thornton Oct 14 '13 at 19:25
  • So here I was thinking that it would be great if Android could include the runtime library, then a little voice in my head told me that I'm asking for "VBRunTime DejaVu all over again". So I guess this is probably useful for niche apps, or trial balloons to see how your app would look/act on Android or IOS, before investing in full-blown native development on that platform. I expect that the eventual list of "Popular Commercial (ANDROID) Apps Developed In Delphi" is going to be a short list. :-( – Chris Thornton Oct 14 '13 at 19:30