A few months ago, my team came upon an agreement that when leaving a TODO anywhere in our code, we need to always provide several things:
- the person who is expected to address the TODO
- date when the TODO was left
- a comment or explanation on what needs to be done
I created a live template to support adherence to this rule, but why not go one step further and integrate the rule into our daily workflow?
We have previously seen:
Having tests for our custom Lint rule is really important. We do not want Lint to flag errors, uhm, erroneously. …
A few months ago, my team came upon an agreement that when leaving a TODO anywhere in our code, we need to always provide several things:
- the person who is expected to address the TODO
- date when the TODO was left
- a comment or explanation on what needs to be done
I created a live template to support adherence to this rule, but why not go one step further and integrate the rule into our daily workflow?
In this post, we build upon the foundations we have started.
Now that we have our module set up, we can start writing our detector. …
A few months ago, my team came upon an agreement that when leaving a TODO anywhere in our code, we need to always provide several things:
- the person who is expected to address the TODO
- date when the TODO was left
- a comment or explanation on what needs to be done
But memories fade and sometimes people forget. So I made a live template to make it easier for everyone to adhere to the rule. A simple ALT+ENTER and tada, there’s the TODO template for you to fill in:
Throughout my career, I have worked in projects of all sizes. I have taken part in greenfield projects and some that are a few years old. One of the lessons I have learned over the years is that no one ever goes back to fix the TODO s.
In our current project, we are trying to mitigate the unchecked growth of this list (we have some from 2015 😭). One of the solutions we are trying to explore is to create labeled TODO s:
// TODO-Zarah (06 Mar 2020): Some comments go here
This means that when leaving a TODO, devs would have to leave their name and the date in the comment. We then do periodic checks (usually before a release) to make sure that we are actively going back and actually fixing the issues. …
I have always believed that one of the biggest factors that influence a person’s enjoyment and delight in doing their job are the tools. Having the right tools and using them the best way possible helps direct our energy on the what rather than the how.
It is for this reason that I have written and spoken about making the most out of Android Studio a few times over the past few years.
For instance, I have lost count of how many times I stopped in the middle of a debugging session only to find myself drowning in breakpoints. I have put in so many that I have lost track of which breakpoint does what, or why I even put a breakpoint on a particular line in the first place. …
One of the most useful things for me whilst I was learning Kotlin was TryKotlin. It gave me a quick way to test concepts, try new APIs, or just to get familiar with the syntax.
Sometimes though I want to see if something would work with my own data classes, and it’s a bit too much trying to cram them all into that page. …
Over the past year, my team have been steadily building a Developer Options screen for our app. It is a simple PreferenceScreen available on debug builds that help us:
- figure out what’s going on without needing to be attached to a computer
- test various configurations without re-installing
- have a host for various experimentations we are trying to explore
In this series of posts, I will share what these various options are and how we made them.
Read the other posts in this series:
Over the past year, my team have been steadily building a Developer Options screen for our app. It is a simple PreferenceScreen available on debug builds that help us:
- figure out what’s going on without needing to be attached to a computer
- test various configurations without re-installing
- have a host for various experimentations we are trying to explore
In this series of posts, I will share what these various options are and how we made them.
Read the other posts in this series:
(If you are not familiar with PreferenceFragmentCompat, I highly suggest to read about that first before proceeding. You can start with this AndroidX guide on…
Over the past year, my team have been steadily building a Developer Options screen for our app. It is a simple PreferenceScreen available on debug builds that help us:
- figure out what’s going on without needing to be attached to a computer
- test various configurations without re-installing
- have a host for various experimentations we are trying to explore
In this series of posts, I will share what these various options are and how we made them.
Read the other posts in this series:
(If you are not familiar with PreferenceFragmentCompat, I highly suggest to read about that first before proceeding. You can start with this AndroidX guide on Settings.) …
Over the past year, my team have been steadily building a Developer Options screen for our app. It is a simple PreferenceScreen available on debug builds that aims to help us:
- figure out what’s going on without needing to be attached to a computer
- test various configurations without re-installing
- have a host for various experimentations we are trying to explore
In this series of posts, I will share what these various options are and how we made them.
(If you are not familiar with PreferenceFragmentCompat, I highly suggest to read about that first before proceeding. …
