I have just developed a new Android Air application using Adobe Flashbuilder and I am having the issue that when it is installed on a device it is 10mb in size which is huge. I dont understand why this is as when I look at the size of the entire App Folder in Flashbuilder it only ammounts to 1.6mb.
Is there something that I should have done within Flashbuilder in order to compress the size? Can anyone please help with this as I really want to release this app but dont want to at this install size.
10 MB is really not that much.
But it's probably because you're using a third party library and that's not inside your folder but it needs to be compiled within your app.
Related
I am new to Flutter and dart language. After developing some example apps seeing from the tutorial I have come to know that the simple Tab-Layout App is taking 7MB for APK after release and after installing the APP the size is 27MB. My question is as follows:
What is the difference between the APK Size and Installed APP Size?
When developing an App whether its Native or Flutter, what should we keep in mind that APK size should not be huge or the size of the APP after installing should not be huge?
Keeping in mind of the all pros and cons of Native and Flutter, what is the best approach to develop an Android APP?
Installed App has something like the DOUBLE in space of the standard APK, this is cause by how Android "installs" all Apps. If you open a folder in "/data/app/..." you can see that for each PackageName/App it is stored the standard APK file (the one you release) and there are at least two folders: for libraries and one for optimized code (not accessible/readable from us without Root). These folders contain other extracted and optimized files starting from your APK.
Flutter Apps cannot be smaller than 6-7Mb because it brings all Flutter Core inside them. To "shrink" your App you can follow common rules to shrink any normal Native App.
The best approach? All depends on your skill, how much available time you have to complete the App, how much times the Customer change his minds about the position of some graphic interface, etc... Flutter main website page has written "Flutter is Google’s mobile app SDK for crafting high-quality native interfaces" so the main purpose of it is to quickly create Interfaces. This is good when a Customer interrupts our work every 10 minutes because he wants to change something in the graphic aspect and we cannot manually change many XML and then rebuild a version each time, so Flutter could improve this step a lot. Flutter is even good at initial stage when we are not sure where we will set components/widgets at final stage, so we can move all the stuff in few seconds to check the graphical result. Performance of Flutter Apps are quite good, but not good as a Native App obrliviously. Using Flutter could be the good way when you already know that the final APK will be bigger than 25MB, because in this case 25MB or 25+7MB is not that's difference but the speed (in GUI development) provided from Flutter are something not estimable.
I code Adobe AIR games with Flash Builder IDE. When exporting release version, the Android one offers two options: one with embedded active runtime and other with shared AIR.
Which is the best option should we choose? In case we select shared AIR, is any risk for our games? I mean, is this true that all Android device always have AIR now? (For us a smaller APK is always better, right? :D)
Normally which option do you choose?
It is not true that all Android devices have AIR installed. Likely it's far from it (though unfortunately I have no empirical data to give you - other than Adobe's blog which in Spring of 2014 claimed 50 million+ installs)
So while you will hit a very sizable % of potential users (using shared AIR runtime), there is no guarantee that the end user will have the correct (or any) version of AIR installed on their Android device.
So if you want to target the broadest audience possible (at the expense of filesize), you would want to export with the run time embedded.
Of course, some users will be put off by your app if it's too big (especially the gamer crowd) so you have to balance that with having to inconvenience some users with downloading AIR first.
Only you can decide what is best and you should consider the following:
Who is my target audience? (gamers are more likely to have AIR already installed), casual users are way less likely to bother with AIR or know anything about it or updating it
How big is my app without the runtime? If you're app is 200mb by itself, then adding the runtime doesn't really make much difference. But if your app is only 2mb, then you're getting a 4-5x bloat.
You do want embedded since this is a guaranty that your game will work correctly. If you choose shared then your app won't install on system with an older AIR runtime version and user might no know how to update it so they won't be able to try your app. Embed and you avoid all these potential problems.
I'm developing a hybrid app using worklight, and so far I just have couple of screens in my app. But when I run this app in my Android phone, if I check the apk file it's size is showing as 4.4 MB! I'm not even 20% through my app development and still it is so heavy.
Is this an issue with worklight or there is a way in worklight to keep your app lightweight?
Thanks for the heads-up. We are aware of this and are making way on reducing our application file size in a future release.
I'm not in front of my work machine at the moment, so I can't test tips before giving you them, buuuttt... in your native\assets folder there should be a icudt46l.zip file.
If you do not intend on using the JSONStore feature, try deleting this file and re-building your app. This should reduce the filesize considerably, but again I can't guarantee what happens during runtime (nothing bad should happen...).
I am building a book application in Flash Professional CS5.5 to be released on tablet devices and I am trying to understand the best structure for loading the application. For iOS devices I know I can include the default.png, but how can accomplish a similar task for Android? The book application is also going to be large as it includes a lot of assets and animations, is there a good way to show that this is loading on both platforms?
One thing I was trying was a loading screen where the main application was actually a loading system that would import the compiled SWF book, but further research shows that it won't work for iOS devices.
Thanks for any tips or pointers.
Well, in the end, I'm developing the main app itself for iOS and exporting that with the Default.png. Then the Android version is a smaller splashscreen/preloader app which will load the SWF version of the iOS app. Is this the correct way of doing it? Probably not, but it's what I've come up with after reading way too many articles that brush the concept.
I have developed a small adobe flash application (a parent .exe file which loads several child swf files). I can play it in almost any computer. My question is: Can I install and run the application in Aakash or Ubislate 7+ ?, any help would be highly appreciated. Thanks.
actually no, the android file system uses .APK files that are installed and work with a different structure. but if you worked with Java to create the app, you can port it to android, only changing the UI part of you're application.