I'm developing an HTML5 application having lots of animations and logic running behind it.
Large number of images and audio files are used in the application to achieve better UI and UX.
I think when I complete this app, It'll be of more than 250 mb in size.
For the web, it wont be any issue since I divided each every modules to several of html pages.
But what if I need to package it with phoneGap for Android Tab and iPad.
Is it possible package an app with large size?
Is there any other method to package it with smaller size?
Any help would be appreciated.
Thanks in advance.
I have a Cordova app here that is well over 1GB. As long as you stay within other limits like the 2GB maximum for the app store, size shouldn't be a problem.
You will need to build locally of course - PhoneGap Build has a hard file size limit, and cloud build services are generally impractical for anything that large.
If possible, set up your app so that it can easily be packaged without most of the media for debugging - the full version takes forever to build and deploy.
Related
A work app I am working on is currently being generated at over 300mb, when in reality it should be around 70mb. I'm aware of the changes Android made whereby native libraries were not being compressed but the size of the APK being generated seems extreme to me. Setting extractNativeLibs="true" seems to have no effect either as i've tried this. below link is a screenshot to show what's obviously causing the issue but I'm stuck on what else I could try to compress the file further?enter image description here
The native libraries you're pulling are huge, compressed or not. Just the library libtwilio is taking 85 MB, then it's present for 4 different device architectures so I'm not surprised the total size is around 300MB.
You should be using the App Bundle so that the libraries of only one architecture is sent to each device of your users. This will considerably reduce the size of the APK that your users are downloading (the size of the App Bundle will still be big, but that only affects what you upload to the Play Console).
Note that even with App Bundle, you'll still be around 100 MB per split APK, so make sure that you really need this library. If it's not a core feature of your app, you can also consider extracting as a dynamic feature so it's only downloaded by your app when the user needs the feature. That would further reduce the size of the initial download.
I have a few projects with flash that i'd like to turn into apps for mobiles, I started reading adobe air and i've noticed that it uses back some things like inframe action script, something that I have not done since as2.
Is there a way to load scripts and classes like a normal flash file?
If I have a noncomplicated swf, is there a way to migrate it easily into adobe air for android and iOs?.
I've been struggling to find examples of adobe air projects, does anyone have a tip for this?
It is easy. I have converted 30 games to run on iOS and Android. The biggest problem was that they were in AS2 and had to be converted to AS3 first. If your uncomplicated swf projects are in AS3, and developed using Flash Pro, then just change the publishing output from swf for a web page to iOS pr Android. Android would be easier to start because you don't need to get an Apple developer account, create a certificate and provisioning file. With Android you can create a certificate right in Flash Pro. You test publish on your pc or mac first. When you are ready to test on a device you create an ipa (iOS) or .apk (Android).
Yes, there are a lot of screen sizes out there. But you know how you can create Flash in a web page so that it will resize with the page and keep its aspect ratio? Well its the same on mobile - it will resize to fit whatever mobile screen it displays on. Most likely your game is in landscape orientation. Just keep it that way and test it on whatever device you have (an iPad would be good because that aspect ratio or 1024 x 768). Actually, we kept the stage to 736 x 552 and that fit on any screen out there. On tall (wide) screens like the iPhone 5 & 6 you will have space on the sides, but so what.
Just give it a shot and you'll see how easy it is to write an app for both platforms at the same time. And you don't even have to own a Mac (you only need one to upload your completed app to the store, but you can rent time on one and log into it for 10 minutes to do that.)
There's no "how to" when porting a Flash project to Ios or Android. It's the same technology so it's compatible in theory. You can simply compile and publish and you'll get a Ios and Android app in most cases. Now there's 3 major problems that probably 100% of Flash projects will face when publishing for mobile and in probably 99% of cases those problems might imply recreating the whole thing from scratch.
First problem: Sizing and Density. So many phones/tablets sizes and density, chances are your Flash project doesn't have a single line of code dealing with that and as a result your app won't display correctly across any mobile devices. You'll have to put together a big piece of code to handle that and make sure it doesn't break anything in the original project. Good Luck with that.
Second Problem: Performance and memory management, I'm yet to see a Flash project that doesn't systematically waste CPU and memory constantly. That's no problem for a Flash project except when publishing for mobile: can we still waste CPU power? NO, can we still waste memory: NO. You'll have to go through your entire Flash project and optimize everything to not waste CPU and memory. Once again Good Luck with that.
Third Problem: assets. Did you use a bunch of MovieClip here and there? Well no more on mobile unless you want your app to lag and drain the battery down and make the user experience as bad as possible. All assets have to be optimized for mobile, the right asset, the right type, the right size or else ... lag and bad experience. Here again Good Luck with that.
And this is just a small run down of the problems you'll be facing. You will spend probably hundreds of hours trying to port that Flash project to mobile and at the end it will still be running bad anyway. Chances are you should just start over.
EDIT:
Simple Guidelines:
render mode: usually "gpu" (very efficient with bitmap) but "cpu" is also possible (you get more CPU power but less bitmap display efficiency) and also "direct" if you want to use Stage3D (more complicated).
Display: usually bitmap and only rarely vector. Don't oversize them and don't undersize them either. Reuse as much as possible (saves memory and battery)
Handling sizes and density: scaling your content is the easy way but not the less efficient one, as long as your bitmaps are of good quality you should be able to get a good resolution in most density and size. Because there's so many different sizes out there you'll decide if you want your content to fit any size or to display as much as possible while filling the side gaps. AIR/Flash has no built-in system for handling that so you'll have to create your own or to find something open source out there that can do that. Basically you have a content that is n x n and it needs to display on a mobile screen that is n x n, you calculate the scale factor and scale your content and center it.
perf, memory, battery: reuse object as much as possible. If there's a bitmap that you'll use often don't get rid of it just reuse it. If you reuse you don't need more CPU, don't need more memory and don't need more battery.
how to get perf: displaying something and running code, that's the 2 things that will slow down the app so optimize both and test often. Maybe reducing the quality of some bitmap will boost your perf. maybe optimizing your code in some places will get you a few more fps, etc. This is a per project try and test.
The apk file size for my app is quite big. Is it possible to reduce the file size by using better compression level or different compression engine such as lzma (https://software.intel.com/en-us/android/articles/native-library-compression-sdk-for-android-apps)?
To simply answer your question:
Yes, use lzma.
Okay, now some other recommendations.
Build in release mode. This is very important, as the app size when built in debug mode can be a lot bigger than when built in release mode.
Compress your images. Often when making an app you don't really look at the size of images, and they usually tend to be the main issue concerning size. Simply opening them in, let's say paint.net, and saving them again with lower quality can help a lot.
Compress your audio files. Load them up in audacity and export them as MP3 with lower quality.
These are some small recommendations of mine. If you need your apk to be smaller still, I'd suggest trying google
You may want to have a look at Crosswalk Lite, Which is a slim version of Crosswalk, with less features, but keeping the great performance.
The project still doesn't have a stable version ( Still in Canary channel ) to be used for production like normal Crosswalk.
I think Crosswalk Lite will be a great solution for problems like Yours, maybe in the near future.
I am building an android application with Adobe Flash cs6 and Adobe AIR for the first time. Initially it looked good but later I faced a lot of problems. What I have till now is more of movieclip and less as3 coding. My app scales automatically according to different screen sizes. However since there are more movieclips my app somewhat lags in Kindle Fire. My question:
1. Do I need to convert my movie clips to Bitmaps or something? How is that done?
2. While converting to bitmap, do I need to specify width and height of the movieclips? Doesnt it get scaled automatically acc. to screen size?
Well, I am new to actionscript, AIR and stuff... so any help would be appreciated.
All display objects have 'cacheAsBitmap' and 'cacheAsBitmapMatrix' propertiues that help with performance, but only for certain class of objects (primarily those not frequently changed).
More info: Caching display objects
Also, make sure you have HW acceleration turned on for maximum benefit, especially on mobile: HW acceleration
I was doing a little project thing for my school...
I made a simple calculator app...with simple mathematics operations...
And when the apk file is created and installed, it was consuming the memory space of more than 700 kb in the phone.
While in the android market(play store), there are just similar apps which are of low sizes and are taking memory space of less than 500. I was creating app in eclipse...
Will somebody plz help me out with this that how they do make apps of simple lower size.??
The smallest APK I created is ~35kB. Size increases dramatically with the included assets. Check the size of your /res, /assets and, if you have it, /raw folders. The APK size will be larger than those three combined. Further, any included lib counts, and adds bulk, even (and especially) the compatibility library, if you use it.
If you're having lot of graphic assets, then you should probably look at using 9-patches. They save a lot of memory.
Please elaborate your question. When you say memory, are you referring to the RAM OR the actual storage memory ?
If you are referring to storage memory...
The storage memory depends on how big your application is. For e.g. IF you have too many images of large size, then app size will increase.
By the way, 700K is not really too much. You are OK.