#XE5 I fell loading my app is slower than other apps. Black screen for a while so it shows up. Is that because I am running a debug version?
#XE5 I fell loading my app is slower than other apps. Black screen for a while so it shows up. Is that because I am running a debug version?
Any chance for optimize the apk? Size is huge!!
Any chance for optimize the apk? Size is huge!!
QC it. I've seen the same.
ReplyDeleteWhat device, btw?
ReplyDeleteLars Fosdal It's surely already in QC. Try and locate it and upvote it etc.
ReplyDeleteLG Optimus G... Please, what does QC means?
ReplyDeleteBTW, you'll not shrink it down too much. And you can't really blame FireMonkey. I built an iOS app with a few screens using no FMX at all, just using iOS APIs. Not the most straightforward prospect, I'll grant you, but that's incidental.
ReplyDeleteIt shows a web browser, does some GPS and polls some device info. Again, no FMX units at all, and the most I pull from the RTL (bar the Objective-C bridge and the iOS API wrappers) is SysUtils & TypInfo (not sure what volume is pulled in by the bridge units).
The release build is 6.5MB...
Magno Lima QC = Quality Central - Embo's bug-logging system.
ReplyDeleteAccess online at http://qc.embarcadero.com/wc/qcmain.aspx or via the QC client, which you should be able to launch from Delphi's Tools menu.
Just remember, the client is a Delphi DB app so you have to press the navigator + button to add a new record.
Thank you very much Brian for explaining! Some terms are not much clear to me yet.
ReplyDeleteI hope they could enhance the compilation process in near future...Have a small feature app with a big size is not confortable...
Brian Long ouch. I mean on PC size does not matter, but on mobile, each MB is important(either you'r speed is slow or your monthly free volume might be used up way too fast)
ReplyDeleteBrian Long - A simple tabs/nav demo with only a few lines added beyond the skeleton app, lists as 33Mb in size, when you look at it in the Android Apps list, and select show cached apps: http://goo.gl/m2zbJk
ReplyDeleteI suspect two issues:
1. FireMonkey has too many inter-unit dependencies. In particular - I am starting to wonder if it actually manages to separate the code for the two platforms in such a way that classes not relevant for the current platform, actually is excluded.
2. The linker isn't quite clever enough.
Oh, and it was built in release mode, and run without debugging.
ReplyDeleteHeh, in my haste to add in information yesterday I totally mistook this for an issue with iOS apps, probably because I was working on an iOS app at the time.
ReplyDeleteThe same issue applies with Android, natch. I do have a Delphi port of one of the NDK sample apps. Again, no FM Application Platform inflating the issue.
This gives a release.apk of 2.4MB, thought the .so was still 6.90 MB. On device the app is reported as occupying 3.74MB
Brian Long
ReplyDeleteThere is a proposal (just for Android) for using a shared runtime similar to Adobe's AIR
Get the fat out from XE5 Android apps - FireMonkey Runtime for Android
https://forums.embarcadero.com/thread.jspa?threadID=93045&tstart=0
http://qc.embarcadero.com/wc/qcmain.aspx?d=119119
Hi!
ReplyDeleteTo reduce load time and perhaps dpk size I comment out line 4 in the .dpr file.
// System.StartUpCopy,
I'm not sure what breaks but all my apps run fine without it. And they load a lot quicker.
Dev Stonez Hmm, I wonder how readily that will come about. I'm thinking 'not very'. Useful in the case of someone installing multiple FMX apps. But that's mostly the developers, no? Not users quite so much.
ReplyDeletePontus Bredin It cuts out certain automatic assets-scanning and copying to various places (the idea being to have files end up in similarly relative location to when running on iOS, though I'm not sure whether that pans out or not). These operations are handy if you deploy code in the assets, or other items you want pulled to the file system straight away, but I think the general case is that nothing is shipped as assets in RTM, so I guess it's ok. I'll have to check it out again at some point.
ReplyDeleteDev Stonez - How long before that would end up in version hell?
ReplyDeleteLars Fosdal How did Xamarin fare on that score with their MonoDroid^H^H^H^H^H^H^H^H^H Xamarin for Android runtime?
ReplyDeleteBrian Long - Honestly, I don't know. I never ventured down that path.
ReplyDeleteBrian Long Think about bpl Delphi runtime libraries used to make modular/reusable Delphi libs with small app/executables ... This will be good for vendors as well (ex: David Berneda #TeeChart library ?) IMHO the single, MOST important feature to be "enabled" for Android might be the possibility to compile with runtime packages (.so wrapped .apks) also including a dependency check/install if not available.
ReplyDeleteEmbarcadero Technologies should take care about the #Delphi for #Android Runtime library (as Adobe is doing it with AIR currently) ...
Lars Fosdal As responded to Brian Long as well, this should be Embarcadero Technologies concern , but I see no hell emerging here (eventually just a new runtime version per year with XExxx release) ... And for versioning I'll advertise to use #semver ( #OSGi like ) semantic versioning with range matching support http://semver.org/
ReplyDeleteI'd prefer a more granular FireMonkey and a better linker.
ReplyDeleteLars Fosdal With proper dependency/library management based on semantic versioning you may get great and modular/pluggable systems (ex: #OSGi, Eclipse NetBeans NodeJS ) ... why not learn from the others ?
ReplyDeleteI don't think a steadily growing number of semantic versions of the libs is a good idea. As for Eclipse as an example - package conflicts are so much fun.
ReplyDeleteThe versioning problems usually comes when your app (as an API consumer) depends on improper and/or every version without properly using semantic version ranges ... thus not following major.minor.service semantic versioning principles ... Additionally the library writers should follow the same principles when the advance the API.
ReplyDeleteSo, if a public API/exports from a library does not change for it may stick to 1.0.1 (or whatever version might be) for years ...
Ex: Requiring FMX.Lib 13.1.0 is still compatible with FMX.Lib 13.1.4 or FMX.Lib 13.5.1 ... so you should depend on it as [13.1.0, 14.0.0) in #OSGi terms or ~13.1.0 in #NodeJS #NPM terms.
Regarding Eclipse "dependency/packages hell" ... this is sorted out by P2 resolver and with Genuitec's Pulse / SDC or EclipseSource #yoxos the plugins are solved/shared properly ... Take a dive into http://semver.org to see how simple the things should be ... and #OSGi definitely demonstrate that this is possible !
The versioning in #OSGi #Java land is solved using #JVM ClassLoader capabilities, until #Java9 #jigsaw modularity project will be released (pro/cons discussions here) ... but in #Delphi land there is just some poor support based on DPK package dependency declaration :( ... Maybe #nativeosgi may help http://nativeosgi.org/
Very nice to hear the comments, I will also try comment System.StartUpCopy and see the behavior...
ReplyDeleteInteresting, after remove System.StartUpCopy my app fails to load SQLite database. Removing the comment if worked back fine.
ReplyDeleteYes, your SQLite DB file is likely packaged as an asset and copied by said unit out to the file system. Removing that line stops it going to the file system.
ReplyDeleteIt´s true, deploy /asset, so no chance for me :)
ReplyDelete