Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Externalize resources #15

Open
SantiagoRivera92 opened this issue Mar 21, 2013 · 2 comments
Open

Externalize resources #15

SantiagoRivera92 opened this issue Mar 21, 2013 · 2 comments

Comments

@SantiagoRivera92
Copy link

The raw resources (Pkmn sounds) are heavy (Heavy as in "More than half the app size corresponds to those resources").

We could just have them available for download on the server, so we can store them on the external storage. Something like this:

  • App starts
  • We check if the sounds are in the SD card. If they are, soundsDownloaded = true and we go on. If they arent, soundsDownloaded = false. We ask the user if he wants to download the sounds (reminding them that the sounds are heavy and that they should totally download them with Wi-Fi). If they want, we start an AsyncTask that downloads those sounds. When we finish downloading them all, we set soundsDownloaded = true.
  • We only reproduce sounds if soundsDownloaded is true.
  • On startup, we have to check if all the 649 sounds are on their folder. If there's at least one missing, soundsDownloaded = false and we ask the user to download the missing ones.

This way, the app is a LOT lighter, and the only "drawback" is that we ask them to download them if they want. Also, they could possibly change and customize the mp3 files if they want.

@Mikewando
Copy link
Contributor

Yeah they're just in there as a proof-of-concept and haven't been released with any builds. They could also be a lot smaller if we could use Opus instead of MP3 because it has a lot less per-file overhead (which makes a big difference when your files are so short), but I don't think Android has support for Opus.

Anyway I don't think we really need to be so binary about whether or not we play sounds; just try to play it and fail gracefully if the sound is missing. I did briefly toy with having a separate package the user could install to provide these, but I don't really like that solution as it ends up just meaning they download a huge package which then dumps all of its contents, so it takes up twice as much space until they uninstall the package.

I ultimately would love to have the app be as small as possible on install (no sounds, no animated sprites, no shiny sprites, no previous gen sprites) and then allow for users to enable as many of those as they want. I've also thought about having them be downloaded on an as-needed basis and cached, then the user can determine how big or small they want their cache.

Of course one problem with all of this is where do we host the extra stuff? I think the answer to that would help narrow down the possible implementations.

@SantiagoRivera92
Copy link
Author

Well, I've used a Image Caché before. It worked like this:

I Ask for an image with its URL, and pass the ImageView I want to set up.
If I have the image on memory cache, imageView.setImageBitmap(bmp);
Else if I have the image on a specified folder, add it to the memory cache, then imageView.setImageBitmap(bmp);
Else I download the image asynchronously, then put it on a specified folder, then add it to the memory cache, then imageView.setImageBitmap(bmp);

The memory cache was implemented by using a HashMap<String, WeakReference<Bitmap>>, but I think the performance of just requesting the images from their folders and then recycling them when they are not needed anymore would work well and not consume so much memory.

This was referenced May 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants