Does using libraries like OpenEars will drastically enlarge my app size? Or I can just extract the text to speech stuff, and get away with it...Probably removing all those langs? I don't have any idea.
I checked and OpenEars sample app is 33MB - which is big!
So my question is - can I implement text to speech in my app without compromising the size so much? I mean I can live with 2-3 MBs but 30...
Thank you!
OpenEars developer here. Just follow the instructions here to reduce your final app size, there's no need to ship all the voices or any features of the framework that you aren't making use of. Depending on which voices you're using and which feature, you might see an app size increase of between 6 megs and ~20 unless you're using a large number of the available voices. The sample app uses all of the framework features and two voices, and supports a few iOS versions, so its binary size reflects that.
My guess is you can't, audio will take up a lot of space.
Removing unneeded language will free some space but 2-3 mb for all the audio guess that isen't really possible.
Related
I am currently working on an iOS game and the image resources seem to be a little too much. I heard of webP and wanted to know more about it.
I did some researches on webP and know that this new format requires much less space than PNG and its encoding/decoding speed is fast. But I found no article discussing the GPU burden when using WebP pictures, compared to PNG ones.
Is there any article out there on this topic?
Or can I do the experiment myself? I am coding in VS using cocos2d-x. I don't know what to do if I want to simulate an iOS GPU and monitor its memory usage.
Many thanks!
You can assume that the textures generated remain the same, ie render at the same speed, using the same amount of memory.
If you want faster loading and rendering and less memory usage, use the .pvr.ccz format.
I am working on a web-application which has multiple videos sizing upto 22MBs.
The requirement is to cache these videos or store it in local-storage so as to avoid buffering of the videos every-time the end-user hits the website on iPad.
Is it valid to do such thing ?
I need a suggestion to check if this practice is good to use such large amount of memory for video caching in iPad ?
(The application is majorly accessed through the safari on iPad or iOS)
I'm not sure about best practices for video since I haven't done much with video, but if you're looking for information about how much data you can hold and how, check out http://milesmatthias.com/post/21323839252/the-current-state-of-client-side-storage for a summary of the different tactics and their size limits.
So I have a huge app. It is full of features, most of which require a couple images, and all of which have to be saved as part of the binary file. I worked really hard before the release to get under the 20MB threshold, to make the app more accessible to users. My release binaryt was 18.1MB.
So now, with the new iPad and its retina display, what should I do about updating all of my images for this new display. If I did include an updated copy, I would be way over the 20MB limit. Currently, I store some image files on my sever, and download/cache them as the user needs them, but im hesitant to do this with major features because I'm concerned some users may not always have internet access. And without some of those images, the app is useless.
Is there any way I can have an iPhone only install the iPhone graphics, and visa versa?
Apple has since raised the limit for all devices to 50 MB due to the release of the new iPad. This should hopefully allow you to fit all of the pictures in your app bundle.
One approach to minimize the size of your files is by compressing your PNG files. This will only minimize the size, and the images will continue to work correctly.
The links provided below will help you find a crusher you desire.
PNG Crush
PNG Compressor
ImageOptim
I'm thinking of developping a mobile OCR app to detect words from mobile pictures.
The purpose if only to detect what words are in the picture, the layout is not important.
Also it would be use on very short texts.
I'm currently thinking of adapting tesseract to iphone and android.
I wonder if anyone has had any related experience? What are the limits etc.
Thanks!
Google Goggles does that... It takes a snapshot, reduces the color depth, scans through various contrast ratios, and exposes letters/words. It then performs a google search on what it found.
checkout this article http://www.itwizard.ro/interfacing-cc-libraries-via-jni-example-tesseract-163.html and this example http://code.google.com/p/mezzofanti/
i run it on my G1 and it's OK for single words, but it is very slow if you have 2-3 lines.
maybe with new phones (dual-core ones) you might get several lines in some seconds
My application has a collection of around 1940 icons that are used throughout.
They're currently in ICO and new images provided to me come in ICO format too. I have noticed that they contain a 16x16 and 32x32 representation of each icon in one file.
Each file is roughly 4KB in filesize (as reported by finder, but ls reports that they vary from being ~1000 bytes to 5000 bytes)
A very small number of these icons only contain the 32x32 representation, and as a result are only around 700 bytes in size.
Currently I am bundling these icons with my application and they are inflating the size of the app a bit more than I would like.
Altogether, the images total just about 25.5MB. Xcode must do some kind of compression because the resulting app bundle is about 12.4MB. Compressing this further into a ZIP (as it would be when submitted to the App Store), results in a final file of 5.8MB.
I'm aware that the maximum limit for over the air App Store downloads has been raised to 20MB since the introduction of the iPad (I'm not sure if that extends to iPhone apps as well as iPad apps though, if not the limit would be 10MB).
My worry is that new icons are going to be added (sometimes up to 10 icons per week), and will continue to inflate the app bundle over time.
What is the best way to distribute these icons with my app?
Things I've tried and not had much success with:
Converting the icons from ICO to PNG:
I tried this in the hopes that the pngcrush utility would help out with the filesize. But it appears that it doesn't make much of a difference between a normal PNG and a crushed png (I believe it just optimises the image for display on the iPhone's GPU rather than compress it's size). Also in going from ICO to PNG actually increased the size of the icon file...
Zipping the images, and then uncompressing them on first run.
While this did reduce the overall image sizes, I found that the effort needed to unzip them, copy them to the documents folder and ensure that duplication doesn't happen on upgrades was too much hassle to be worth the benefit. Also, on original and 3G iPhones unzipping and copying around 25MB of images takes too long and creates a bad experience...
Things I've considered but not yet tried:
Instead of distributing the icons within the app bundle, host them online, and download each icon on demand (it depends on the user's data as to which icons will actually be displayed and when).
Issues with this is that bandwidth costs money, and image downloads will be bandwidth intensive. However, my app currently has a small userbase of around 5,500 users (of which I estimate around 1500 to be active based on Flurry stats), and I have a huge unused bandwidth allowance with my current hosting package.
So I'm open to thoughts on how to solve this tricky issue.
I did some research on MonoTouch for a client. MonoTouch has a minimum file size of 5.1mb because all the C# stuff. It doesn't seem to have affected apps store users willingness to download the MonoTouch based apps.
In my research I didn't see any evidence that end users pay much attention to app size when making purchasing decisions. A lot of apps are first downloaded to non-Mobiles via iTunes and the difference in download time between a 1mb and 5mb is barely noticeable. A lot of end users are only vaguely aware that apps even have a size.
My recommendation would be to try and prioritize the icons based on usage rate. Praeto's rule shows up in most data so you'll probably find that 20% of the icons get 80% of the use. Include that 20% most active icons in the app bundle and then download the rest.