Philosophical Hacker

Me: I really like my new job. Family: (incredulously) Really? Me: Yeah. The people are smart, passionate, and the company seems promising. Family: (sarcastically) Ok. So you’ll stick around for 6 months then? Two Wednesdays ago marked my 1 year anniversary at UniKey, and as the above dialog suggests, this is pretty weird for me. I’ve never been at a job for a year before, so this 1st ever anniversary in my career has given me the urge to reflect a bit on a couple of questions: »

If you saw a toilet seat in a movie theater, you’d probably think to yourself, “Wait a minute. You don’t use that in here. Many of us have a similar reaction when we think of using react native at an IoT startup: Wait a minute. React Native is fine for light-weight apps, but IoT companies need apps that make heavy use of the phone’s hardware, so don’t use it in this situation. »

I’ve got a “sweet tooth,” which, in my case, is just a euphemism for me saying that I’m addicted to sugar. I’m young now, but I know that this addiction won’t end well once my metabolism slows down, so I try go to the gym. Unfortunately, when I leave the gym, I often think to myself, “I just worked out, so I can snag that Oreo McFlurry I’ve been craving all day. »

A code smell is a surface indication that usually corresponds to a deeper problem in the system…smells don’t always indicate a problem…You have to look deeper to see if there is an underlying problem there. –Martin Fowler Some people don’t think Dagger is very useful. I’m a bit suspicious of these people. An application that doesn’t need Dagger smells. It suggests that there might be something wrong with the application’s architecture. »

Some tests are fast. You can run 1000s of them in seconds. These are the tests that are the heart and soul of TDD, so you run them every chance you get. There are other tests that aren’t so fast. Because they’re slow, you don’t want to run them often. You’ve got better things to do than to sit and wait for test results to come through. Unfortunately, the less you run your slow tests, the less valuable they are. »

Imagine that you’ve never run a single mile in your life. You know that exercising is good for your health, so you decide that you’re going to take up running. Strangely, however, you also decide that you’re going to begin your journey towards physical fitness by running a marathon tomorrow. That’s obviously a bad idea. Less obviously, deciding to go from no experience with testing to writing tests for an already existing Android app is also a bad idea. »

Activitys and Fragments, perhaps by some strange historical accidents, have been seen as the optimal building blocks upon which we can build our Android applications for much of the time that Android has been around. Let’s call this idea – the idea that Activitys and Fragments are the best building blocks for our apps – “android-centric” architecture. This series of posts is about the connection between the testability of android-centric architecture and the other problems that are now leading Android developers to reject it; it’s about how our unit tests are trying to tell us that Activitys and Fragments – like the cracking bricks in the above image – don’t make the best building blocks for our apps because they tempt us to write code with tight coupling and low cohesion. »

We as engineers somewhere have a level somewhere where everything beneath that is a black box… Jake Wharton, Fragmented Episode 7, 1:12:00 For a while now, anything security or crypto related on Android has been a black box for me. For example, when I read the docs on Android’s KeyStore class or hear about Android’s Fingerprint authentication functionality on Fragmented, I often feel like I’m just barely understanding what’s being said. »

A few weeks ago, the folks working on Kotlin announced the 1.1 release. Kotlin’s 1.1 release has experiment support for coroutines. Here’s the elevator pitch for coroutines from their blog post announcing the release: Asynchronous programming is taking over the world, and the only thing that is holding us back is that non-blocking code adds considerable complexity to our systems. Kotlin now offers means to tame this complexity by making coroutines first-class citizens in the language through the single primitive: suspending functions. »

Activitys and Fragments, perhaps by some strange historical accidents, have been seen as the optimal building blocks upon which we can build our Android applications for much of the time that Android has been around. Let’s call this idea – the idea that Activitys and Fragments are the best building blocks for our apps – “android-centric” architecture. This series of posts is about the connection between the testability of android-centric architecture and the other problems that are now leading Android developers to reject it; it’s about how our unit tests are trying to tell us that Activitys and Fragments don’t make the best building blocks for our apps because they force us to write code with tight coupling and low cohesion. »