Investigate App Bundles

[kuhrusty]

The Google Play Store really wants you to use Android App Bundles. I thought that might be a good way to keep the bloated, almost-never-changing content (card images & audio files) as separate downloads, so that upgrades to the app itself would be tiny, but it looks like that's not how App Bundles work: instead, an APK gets generated which contains all the content every time anyway.

(Oh, one way they might help is if the different Drawable densities--drawable-mdpi, drawable-hdpi, drawable-xhdpi, etc--are split up, so on an hdpi device, your dynamically generated APK doesn't include the xhdpi card images. That's good.)

Two things which make me uneasy about switching to App Bundles is A) it sounds like they add complexity... maybe a lot of complexity, and B) they require you to surrender your app signing key to Google. Gosh! Weird how that couldn't have been implemented any other way!

(Ooh hoo hoo, we may have to use App Bundles; the current APK is 102MB, and the Store limit is 100MB. Nutballs! Using App Bundles lets your final assembled APK be 150MB.)

[kuhrusty]

Ugh, yeah, the Play Store upload fails because the APK is too big.

Looks like another option is APK Expansion Files, which is another topic I have limited interest in learning about. Blowing three goddamn hours trying to change the font on an alert dialog has crippled my enthusiasm for learning Google's methods for working around Google's arbitrary limits.

[sgbeal]

FWIW, i feel for you. i'm a bit surprised you're entertaining the idea of a Play store entry at all.

[kuhrusty]

Well, I think it'll make it easier for people to find & install (and get automatic updates); having to install it from GitHub is a little weird. (And, after months of harassment, I finally got permission from GOBLINKO.) But, yeah, being a teeeeeny bit over Google's arbitrary size limit, and having to figure out which of their workarounds is going to cause less grief, is irritating.

[kuhrusty]

Ugh, looks like there's a third approach to consider: Multiple APKs.

[sgbeal]

The multi-APK approach sounds, for this particular app, like it would only allow you split up the various image densities. It would also make debugging APK-specific problems a real bi... witchsmeller... because you'll need a different VM configuration (or device) to check each one.

[kuhrusty]

The multi-APK approach sounds, for this particular app, like it would only allow you split up the various image densities. It would also make debugging APK-specific problems a real bi... witchsmeller... because you'll need a different VM configuration (or device) to check each one.

Yyyeeeahhh. I think splitting up the stupid image densities (don't they have computers for shit like that?) would be enough to get below the 100MB limit:

$ du -ks app/src/main/res/drawable*
848     app/src/main/res/drawable
31324   app/src/main/res/drawable-hdpi
9684    app/src/main/res/drawable-ldpi
15728   app/src/main/res/drawable-mdpi
2636    app/src/main/res/drawable-nodpi
49700   app/src/main/res/drawable-xhdpi

So, even the APK for xhdpi, the highest density I've got images for, would cut out 31MB + 9MB + 15MB by losing hdpi + ldpi + mdpi. (I knew the scans of the cards, issue #9, were bad; I didn't realize they were that bad.) Anyway, whichever is the easiest way to do that is the way I want to go. Some of the stuff I'm reading on App Bundles makes me nervous, because the way it handles files on Android 4.4 devices is completely different (and App Bundles "require a little more effort and possibly refactoring your app"--ugh).

[kuhrusty]

Ha, tempted to build a version which has only the xhdpi images, because I'm pretty sure they'll be scaled down at runtime on lower-density devices if the pre-scaled versions aren't available in the APK. That would solve the whole stupid arbitrary-100MB-limit problem.

[kuhrusty]

Man, all the audio files only come to under 6MB. I thought they were part of the problem; they're nothing!

[sgbeal]

Have you considered using Inkscape to trace the cards to SVG? i suspect they might be smaller once the APK compressing is applied. i'll try that out when i'm back on the computer (can't do it on this tablet).

Edit: maybe not smaller, but a single graphic for all densities.

[sgbeal]

Errr... nevermind.

(left, your scan, right SVG conversion)

To get good SVG we'd need to essentially recreate the cards by hand using the appropriate fonts and whatnot. i have an SVG containing all(?) of the glyphs (i stripped them out of the rulebook one day when i was exceedingly bored), but it would still require quite an effort to do.

Even so: if you'll provide SVG templates for the "backgrounds" of the cards - borders and the encounter area at the bottom - and provide a suitable font, i will commit to porting the text and glyphs to them. i lack the artistry to create the background part, but could manage the rest.

A related option would be to not use identical copies of the cards, but recreate "basic" versions of the cards, with the same colors but devoid of any background graphics or fancy edges. i could commit to assisting in that if it sounds like a workable approach to you.

[sgbeal]

What i mean by "basic" versions is something like this:

(left: your scan, right: a quick mock-up in Inkscape)

If you've got a font for these cards (or fonts (plural), it seems), and you find this approach acceptable, i can start putting these together. Maybe we can find a portable SVG filter which will give us the roughened edges.

Holy cow there's a lot of these cards.

[kuhrusty]

Yeah, that was the intent behind issue #9: instead of having scans of the cards, read the text + some markup from skills.json or whatever, and render the text + colored boxes for stance etc. over some background (which could be a scan of any card with the text removed).

That's a lot of work, though--not just the code (which would be fun), but the data entry. Compared to that, scanning the cards + running them through a GIMP script to generate the different sizes was easy!

[sgbeal]

If you want to generate images programmatically, rather than pre-assemble a set of SVGs, if you'll commit to the code then i'll commit to entering the text, encounter counts, and whatnot. i could probably have that done, as a CSV, in half a day or so.

[sgbeal]

Alternately, if you don't mind using SVG mockups instead of original scans, i'll commit to the SVG cards if you can provide the font(s).

[kuhrusty]

Well... if we go the issue #9 route (which would be better than using scans of the cards), let me see if I can get the code working before you do the data entry (partly because I'm not exactly sure what the data should look like). And, I'd want to do the skill cards before the danger cards, because they take up almost exactly twice as much space as the danger cards... that's a lot more text, though!

As far as getting this thing under 100MB soon, though, let me finish experimenting with removing all the non-xhdpi card scans. That seems bogus, but then so does including all the other resolutions in the first place.

[sgbeal]

Just let me know. i don't at all mind ripping the card text. In the meantime, i'm gonna get back to this long-ass session of The 7h Continent...

[sgbeal]

Also... maybe consider converting the images to jpg?

[kuhrusty]

On my cheapo tablet (which is allegedly ~189ppi, so probably mdpi), there is a very minor but perceptible difference in the skill card images depending on whether they came straight from the APK vs. being scaled down from xhdpi on the fly. (They already look a little rough anyway, as they're enlarged & blurred to smooth out the halftone screens, but, rough enough to be worth blowing the 100MB limit? Probably not, ha ha.)

Also... maybe consider converting the images to jpg?

Ya know... that probably would've done it too. They're PNGs with "maximum compression," but there's no way "maximum" can beat "lossy"; let me experiment with that a bit. (No idea why I went with PNGs in the first place.)

[kuhrusty]

(No idea why I went with PNGs in the first place.)

I'm a goddamn doofus, that's why.

$ pngtopnm skill_warding.png | pnmtojpeg --quality=90 --optimize > skill_warding.90.jpg
$ pngtopnm skill_warding.png | pnmtojpeg --quality=95 --optimize > skill_warding.95.jpg
$ ls -l skill_warding.*
-rw-rw-r-- 1 rusty rusty  63365 Jun 20 04:22 skill_warding.90.jpg
-rw-rw-r-- 1 rusty rusty  85854 Jun 20 04:22 skill_warding.95.jpg
-rw-rw-r-- 1 rusty rusty 260542 Dec 31 00:01 skill_warding.png

The difference in quality between the 260KB PNG and the 63KB JPEG is nearly imperceptible, much less visible than the difference between the APK with ldpi/mdpi/hdpi/xhdpi vs. xhdpi-only. The same is true even with the ldpi-scale images. So, I'm going to run a script to convert all the PNG card scans to JPEG at 90% quality and call it a day. (Or whatever it is at 4AM.)

[sgbeal]

1) 4AM is lunch time.

2) My offer still stands if you decide you want to programmatically create the cards. Just let me know.

[sgbeal]

PS:

pngtopnm skill_warding.png | pnmtojpeg ...

Seems like overkill compared to:

convert -quality 95 foo.png foo.jpg

But... tomato, potato.

[kuhrusty]

convert -quality 95 foo.png foo.jpg

You know, I could not remember the name of the ImageMagick commands. Now, if they'd named it something intuitive like "pngtopnm" ...

[kuhrusty]

Also... maybe consider converting the images to jpg?

That drops the APK to 38MB. I AM SHAMED

[sgbeal]

convert is admittedly a silly, far too generic name, but it's my go-to graphics conversion tool (i use it daily to resize photos).

But... does that mean... that we (the royal we) don't get to re-engineer the whole app now? :'( (And, by extension, that we (the other royal we) don't get to watch the first we do it?)

[sgbeal]

Just FYI: deep down (okay, not so deep down... right on the surface, actually) i'm laughing my ass off at the nature of this problem and the instinctive geek reaction to search for a far-more-trouble-than-it's-worth solution.

[sgbeal]

Ooooooh: don't forget at this change may allow the app to have higher-res cards :). (Obviously, they'd need to be re-scanned unless you have the original 200+dpi scans stashed away somewhere. Certainly you do, though. Certainly. Deleting them would have been silly.)

[kuhrusty]

Ooooooh: don't forget at this change may allow the app to have higher-res cards :).

I don't want card scans at all; I want issue #9 done!!