I am adding some PDF files in my android application but these files are about 100 MB. This increase my application size a lot. is there any way i can reduce the size of my application and make it memory efficient?
Reduce the image size in your pdfs: this is more correlated to pdf
than Android I think. Use something like Acrobat Reader Pro, or
Photoshop to edit the images and make the .pdf.
Instead of embed the pdf file on apk, provide an external link for
the file hosted on somewhere (onedrive, google drive...), so the
file will be downloaded on the fly by user.
Compress the pdfs in some .zip file and embed this file on apk.
Then, when the user open the app for the first time, you extract the
pdfs on internal/SD storage. I'm not shure if this will be so
effective due compressions reasons that depend of the type of file
beem compressed.
Related
We are developing a PhoneGap application (iOS & Android). That needs to store some data in mobile database(SQLite) and some PDF/JPG files File system to make application working in offline mode.
We will download this data once the application has been installed. My question is, Which format we should use to store the PDF/JPG files in filesystem ? It is in Zip format? Any other compression ? Or No compression ?
Which one is recommended?
Do not use any compression, save the files as they are in file system. Make sure you have appropriate file size ready before download(for eg: 100kb png images is enough for mobile). Make sure you keep your data safe here is a good link how to here
I need 6 large images in my app. And I don't need the quality and alpha channel provided by PNG. Is there a way to embed JPEG files into the raw resource and unfold them into SD card at first launch of the program? It will save me 3-4 MB in my APK. Thanks!
It's very easy. Put your file in res/raw filder and use:
InputStream is = getResources().openRawResource(R.raw.image);
BitmapFactory.decodeStream(is);
You can simply open the stream and do whatever you want with the data.
I think I don't understand your question: It seems that you want to hive off image files at first run...
Anyway, I suggest to put the files in the assets folder and not in the resource. You can access the assets as a file system and copy them to any (permitted) location.
Have a look here:
Difference between /res and /assets directories
and here (look at assets):
http://developer.android.com/tools/projects/index.html
EDIT:
My answer suggests to use assets instead of the resources but, you can't modify your apk at runtime, look here:
how we can remove a file from the assets folder at runtime in android?
Nothing prevents you to put JPEG images in the resource folders, or in the assets folder if you don't need the R.drawable.MY_IMAGE thingy.
However, the images would still be included in your APK, and cannot be removed from your application package even after you copied them to the SD card.
The only way is to download the images separately from a web server on your application first launch.
The Google Play Store also provides some facility if your application needs big files, but that seems a bit of an overkill
When I complete the Android app I am developing I will want to distribute it so that about 300 image files are stored on the sdcard. Is there any way to do this within the usual automatic installation system? I don't want to hog the internal memory by including the files in res/raw.
I believe the app can now be built with an instruction to install on the sdcard so I suppose I could do that and include the files in res/raw but is there any limit on the number of files in res/raw?
If you didn't want to include the images you could utilize the APK Expansion Files mechanism:
http://developer.android.com/google/play/expansion-files.html
It will even save it to the sdcard.
Otherwise, you will either have to include the images or download them programmatically to the sdcard. As for the limits of the res/raw/assets folder I couldn't find any hard figures. The upper limit though would be the max size of the apk. You could always write a little script that would place 5k/10k/20k 1byte files and see for yourself on that upper bound. If the actual amount of files became an issue you could always zip them in the assets/raw and unzip them to external storage.
I have personally shipped an application for a client that had upwards of 500 images in the assets folder and it worked very well.
I'm using an expansion file (~500mb) that contains videos and more than 20.000 image files.
Which is the best way to manage this file?
For now, i'm loading the ZipFileResource object in my Application class when i check if this file is already downloaded.
One of the uses for this expansion file, is to provide images for a gigapixel view, but it takes a lot of time to load one image, and it should load about 30 images in 200ms.
Before i move this image files to an expansion file, there were in assets folder and worked well.
I'm planning unzip the expansion file at the external storage and remove the obb file, but i don't know if it's a good choice.
Can you tell me some advices?
Thanks in advance.
As far as I understood you, you'll download your mediafiles after you have installed the App. For this I would make it like that, download it and save it to the SD-Card (I would do this in an AsyncTask). Now you save every path of your picture or video into your DB. If you want to get the picture read it out the db and fill your ImageView or whatever. This way is really fast.
I hope I could help you.
safari
I tried to use Zip files as extension files once and I have found that they work very slowly.
OBB files works fast, just as with your regular file system.
I'm planning unzip the expansion file at the external storage and remove the obb file, but i don't know if it's a good choice.
It's bad choise. Google doesn't recommend:
To ensure proper behavior, you must not delete, move, or rename the expansion files.
I was trying to read epub file stored in sdcard using epub library.
The epub file size was 90 MB. When I run this application it gives an error "out of memory".
Does anybody have an idea/suggestion/solution how to solve this?
You might want to open up the file in an archive manager like 7-zip, and take a look at the individual file sizes. Some e-book readers (like Sony's) have size limits on the individual .xhtml files in the .epub archive - we've been splitting ours out into about 100KB uncompressed each.
If you do find that the xhtml files inside the .epub archive are too large, you can use a tool like Calibre to split the file into smaller bits.