In the last Test-Driven iOS post, we talked about setting up our code and test files to allow unit testing on storyboarded apps. I mentioned that an extension of that setup could be used to take control of dependency injection inside of our apps. We’ll talk about that today.
In this post a while back, I mentioned two options for setting up unit test-friendly dependency injection in an iOS app: dependency injection libraries and constructor injection with code-defined views. In that piece, I talked about using a code-only UI to achieve my testing goals.
Since then, I have learned a few more strategies that allow me to unit test my iOS apps while still defining the views through the storyboard, as Apple intended. Here I’ll share some of what that looks like with you.
I came across an article on Firstround called ‘Forget Tech Debt…Here’s How to Build Technical Wealth.’ Andrea Goulet introduces us to some of the practices her consultancy uses to dive headfirst into legacy codebases, improve their design, and make them more maintainable.
Enterprises tend to be large, old institutions. They have done a lot of stuff, and they have a lot of data under their belts. When we’re working with enterprises to build apps that will help them understand their data, we need a way to process that data that takes time and system limitations into account. We can often process a lot of stuff at once more efficiently by using batch jobs. Spring Batch gives us a convenient tool to perform batch processing in Spring applications.
The year is 2016. As a developer, the majority of the third-party service endpoints I work with on a daily basis follow (or sort of follow) the RESTful API guidelines. However, RESTful APIs were not always the web transfer methodology of choice. There are numerous ways to transmit information over HTTP. Outside of HTTP, systems might also employ FTP or another use of the TCP/IP protocol to transmit information between computers. For managing multiple myriad types of integrations, we have Spring Integration.
Today at lunch at Pivotal Labs, our designer Andy Detskas talked with us about some of the things he has learned about material design for Android Marshmallow.
If you’d like to see more details on the presentation than the rundown provided here, or if you’d like to follow some links to useful resources on designing for Android, you can see the slides right here.
Tab layouts indicate that there are multiple pages to look at, and users can swipe them or click them to move from page to page.
Their implementation makes them difficult to test drive, so in this post we will go over how to do it.
We implement the tabs in Android by placing a TabLayout element in our activity’s view, then getting ahold of it in the Activity class code and adding tabs to it. There are limited ways to get an instance of TabLayout.Tab, and because it is a final class, it cannot be mocked.
For the past four months, I have worked on a project in which I needed to pair program remotely with developers in other states, other countries, and other time zones.
Remote pairing feels different from pairing with someone in person: you lose the benefits of colocation for asking each other questions and reading each others’ moods and body language. That said, I have learned some practices that work better than others for pairing remotely, and I’d like to share them so that you can make your remote pairing experiences go as smoothly as possible.
It’s much easier to write a test-driven application when we can isolate the class under test, so its tests fail as a result of its behavior and not the behavior of its dependencies. Exercising the dependencies in tests—whether they’re collaborating classes or entire frameworks—increases the number of reasons that a test might be failing, which limits how helpful that test can be in diagnosing issues and driving out an implementation.
In Android, there’s an additional concern: exercising the Android framework in tests is slow. So it makes sense to exercise the framework as little as possible in tests. This gets complicated when we consider the way the Android framework is built, though. First of all, it works chiefly by allowing us to subclass Android classes and override life cycle methods. This is not a recipe for easy dependency injection. Furthermore, idiosyncratic implementations of Android sometimes involve obtaining dependencies (like views from the layout) via a method besides injection. (We talk about how to test dependencies in that scenario in this post).
But there’s another catch to decoupling and testing in Android: the launching of some components depends on passing in other components.
Welcome! You’ve landed on the second post in a series of posts designed to be companion reading for Android Programming: The Big Nerd Ranch Guide, 2nd ed.
BNR goes step-by-step through how to make a RecyclerView and all of the component objects that come together to make it work. The RecyclerView differs from the ListView, which is the list creation method that I have used the most in Android, so I was excited to see the RecyclerView in action. That having been said, the explanation in the book spreads out over several pages; I wanted to find something more concise to help me achieve a high-level picture of how everything talks to each other and how I might implement a RecyclerView on my own rather than copying the code verbatim in the book. I found this blog post by Ashraff Hathibelagal, which helped me sketch out a responsibility diagram for RecyclerViews to contrast with a responsibility diagram of its predecessor, the ListView/GridView: