In one of my recent projects I needed to implement a quite popular UI for entering confirmation codes (which are usually received via SMS messages):
After a quick Googling, it appeared that some good solutions had already been available on GitHub but unfortunately none of those libraries was quite compatible with my design, and many of them didn’t quite match my overall expectations for the functionality and API. So I decided to go with a custom implementation of all the necessary stuff, luckily the deadline wasn’t strict enough and I had some spare time for investigations and playing with custom…
In the first article of this series, we discussed some disadvantages of the traditional “1 adapter per case” approach of working with
RecyclerView in Android. I also demonstrated a simplified concept of a universal, DataBinding-based
RecyclerView.Adapter which could serve a potential solution to most of the discussed issues. In this post, I’d like to dive a little bit deeper into this topic and try to improve the original adapter by applying it to some real-world examples.
I also received a couple of interesting questions and I’m going to discuss the most popular ones as well. …
RecyclerView is undoubtedly one of the most important and widely used UI widgets available in Android SDK nowadays, and it’s really hard to imagine a modern application with no lists at all. There are hundreds of articles about this component and there is a lot of great libraries simplifying its usage provided by the community. Nevertheless, I’d like to add my 5 cents here and discuss traditional approaches of working with lists, what problems they bring, and how they can potentially be solved by using Android Data Binding Library.
In the first article, we discovered one of the two key Gradle commands which come with Jacoco plugin — jacocoTestReport. As you now know, it can be used to measure code coverage in your project by generating detailed reports in HTML, XML, or CVS formats. This time I’d like to share my experience with the second piece of this puzzle — jacocoTestCoverageVerification.
As per the documentation, this task does the following:
Task for verifying code coverage metrics. Fails the task if violations are detected based on specified rules.
Not so long time ago our Android team decided to push our processes related to unit testing to the next level. We’ve already had some verbal agreements but most of the time everything was a bit spontaneous (not to say chaotic). We didn’t have any formal rules and metrics and as some famous man said — “you can’t improve something if you cannot measure it”. So I started searching for a way to automate our processes related to writing tests. Quick Googling led me to Jacoco: there is…