_Sup for Android_ - Part 3
Monday, December 1, 2014 :: Tagged under: engineering pablolife. â° 4 minutes.
Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! đ
And the final part!! Part 1 covered architecture, and Part 2 covered libraries. Letâs finish this pup up!
Testing
I confess we donât have enough automated testing on our client. The idea is much like jwz describes in his Coders At Work interview:
Seibel: In retrospect, do you think you suffered at all because of that? Would development have been easier or faster if you guys had been more disciplined about testing?
Zawinski: I donât think so. I think it would have just slowed us down. Thereâs a lot to be said for just getting it right the first time. In the early days we were so focused on speed. We had to ship the thing even if it wasnât perfect. We can ship it later and it would be higher quality but someone else might have eaten our lunch by then.
Thereâs bound to be stuff where this would have gone faster if weâd had unit tests or smaller modules or whatever. That all sounds great in principle. Given a leisurely development pace, thatâs certainly the way to go. But when youâre looking at, âWeâve got to go from zero to done in six weeks,â well, I canât do that unless I cut something out. And what Iâm going to cut out is the stuff thatâs not absolutely critical. And unit tests are not critical. If thereâs no unit test the customer isnât going to complain about that. Thatâs an upstream issue.
I hope I donât sound like Iâm saying, âTesting is for chumps.â Itâs not. Itâs a matter of priorities. Are you trying to write good software or are you trying to be done by next week? You canât do both. One of the jokes we made at Netscape a lot was, âWeâre absolutely 100 percent committed to quality. Weâre going to ship the highest-quality product we can on March 31st.â
Truth is, I did have to go from 0 to done in 6 weeks for 1.0, then I had to do it again for 2.0. I got some basics in there, but I would call this the least battle-tested part of this blog post.
First off, we use Spoon as our runner. Itâs convenient at the very least for installing the build on a bunch of devices. We use Espresso to send commands to the device to run the tests.
The kind of TDD practitioner who just wants it hooked into their veins (who will only write code after a failing test, and MUST re-test several times a commit) will want to check out Robolectric.
The APK limit: The "Escort Mission" of Android Dev
Designers of strategy or war games almost inevitably, when realizing they canât make a single-player campaign entirely of "kill all the bad things" missions, resort to at least a few escort missions, where they give you a weak AI teammate that you have to ensure doesnât die. Everyone hates Escort Missions.
Well, Android has a special development constraint you wonât hit anywhere else: youâre limited in the number of methods that are allowed to have defined in your app. You may, as I did, break the build because you took a block of code and generalized it into a new method. After that moment, youâll always hesitate to include libraries, and when you do, youâll inevitably worry âGod, I hope this library doesnât define too many methods.â This is building an app defensively. This is a development equivalent of the Escort Mission.
Thereâs not much I can tell you that you probably couldnât derive on your own. This repo was handy in figuring out which libraries bloat. I had to replace Joda-Time with the standard Android Date to buy a few thousand methods. Guava had to go. Remember when I said using Dagger would hinder your ability to use ProGuard? This is an instance where youâll feel it -- the Guava team encourages ProGuard to avoid problems related to its size.
Mercifully, Google listened to the prevailing wisdom and is splitting up Play Services on their newer SDKs. Lollipop devices donât have this limit. Jack & Jill probably also help with this. So be confident that in, oh, 3â5ish years the ecosystem will have permeated these changes, so you no longer have to program like a barbarian and can use your programming languageâs "reusable function" feature. Until then, decide which library or method you love least, and cull it.
Resources
When getting to know a new ecosystem, itâs always handy to see whoâs in that space and what theyâre saying. Iâve written about almost all the Square libraries out there, so be sure to give their blog a follow.
Cyril Mottier comes up in a lot of places, check out his work. I found this post on reducing APK size, in particular, to be simple, straightforward, and taught me a lot about the platform I didnât know.
Chiu-Ki Chan has some great talks online demystifying and demonstrating techniques on many Android components, so give her a look.
Lastly, the official Android resources, like the Android Developers Blog and the Android Developers YouTube page will keep you up on whatâs fresh.
Thanks for the read! Disagreed? Violent agreement!? Feel free to join my mailing list, drop me a line at , or leave a comment below! I'd love to hear from you đ