5 Pull Request Tips for Mobile Developers

Mobile app features usually have a significant part of UI-related code, which isn’t fast to review during the pull request (PR) especially when the screen’s design is complex. Not reviewing the UI is not a solution, the problems and visual inconsistencies will later be found and filed as bugs.

Sure, the code has to be checked on following best practices for building UI — keeping the layout simple, and flat, avoiding unnecessary nesting, using resources for dimensions, color, styles, etc. What about validating the visual part of the app? To know that the layout follows UI prototypes running code is a must. Now, as a reviewer, not only do you have to put aside your tasks and focus on understanding what’s happening in the PR, but also open design prototypes, stash all the changes, fetch the remote branch and run a code to validate that the UI matches the design.

How can we make PR reviews faster and more convenient? Without further ado, let’s get to the ways of speeding up your Android PR reviews:

1. Apply PR templates

The PR template is a greater way to standardize the content of your PRs. The template is a checklist that is added to PR’s description for every developer to fill up prior to creating the PR. They are relatively easy to integrate see the GitHub PR template.

There are many templates out there, usually, they consist of the following sections/checks:

• PR Description
• Type of PR (new feature/bug fix/etc.)
• Supporting content — videos, screenshots
• Steps to test functionality added or affected by the PR
• Additional conventions that the team follows and platform-specific requirements to be checked (OS versions feature is tested on / Unit, Integration, UI tests added)

Check out the Telegram-X template and how it is being applied to PRs.

2. Add video to PR

Record a video for PRs that have more than 2 screens involved, or ones that have transitions, animations, or interactions with UI components.

To record a video just launch an emulator, open the Logcat, and find the “Screen recorder” option on a panel. Then save the video and upload it in a Slack chat or whichever messaging app you are using and attach the video link to the PR.

Android studio - device screen recording

3. Take side-by-side screenshots

Put the emulator and the design prototypes side-by-side, and take a screenshot, then attach it to the PR.

It becomes quite apparent when something is off when comparing things side-by-side. The developer creating PR will most probably spot obvious problems at this step and fix them.

4. Apply “Show layout bound” while taking screenshots

Use “Show layout bound” from “Developer options” to display the layout bounds of the views. You can find it under the Drawing section. You can even add it to the quick settings menu, for that do:

Developer options => Quick settings developer tiles => Toggle Show layout bounds

Layout bounds are especially useful in situations when:

• Need to see the clickable area or the view.
• Need to see if one mistakes padding with margin.
• Working with 9 patch images (God bless you).
• Working with custom views.
• Applying custom fonts — they commonly have problems with font paddings.
• Working with Window API, Full-screen mode, status bar, and insets.
• Working with Relative and Constraint layout.

Let’s have a look at the Google I/O app v 7.0.15 (It just happened to be on my test device). Without looking at the code, see if you can spot any potential bugs in the layout.

From the 1st and 2nd items, we can see that if the talk’s title is 1 line long and the venue name is long enough, then the venue name will either overlay the favorite icon or will be overlayed by it. Because the constraint is applied to the end of the parent layout, not to the start of the favorite icon.

5. Use the “Material Cue” app and apply grid overlay

“Material Cue” is an app that overlays the screen with a grid of different formats. Just download an APK, drag and drop into an emulator or install it with an ADB command.

adb install <path_to_apk_file>

I can no longer find it on Play Store, so you’ll have to find an APK in google, so be careful and avoid dodgy websites.

For complex layouts use this app together with “Show layout bounds” to find mistakes in UI implementations. That being said, on it can also be used on its own in the subset of cases where you would normally apply “Show layout bounds”.

On the screenshots above you can the “Standard Grid”’s effect. It essentially segments the screen into 8dp cells and adds purple material guidelines of 16dp from the start and end of the screen and one red line 72dp away from the start.

Can you spot any problems with the details screen? I can only guess that by design the “Keynote” tag was planned to be 8 dp below the description section, while here it is 12 dp below it because there is inner padding of 4 dp inside the Layout that wraps the tags.

Conclusion

At first glance, it seems that applying these suggestions will benefit and save reviewers’ time but increase the time spent on creating a PR. In practice though, the time spent on PR preparation is beneficial for the PR creator as well. These suggestions seamlessly introduce the practice of diligent and conscientious self-review of the submitted code and minimize the chances of pushing buggy code. Which, then reduces the number of fixes requested by the reviewers and the need for subsequent review.

Connect with me:
- Twitter: https://twitter.com/leonov_dmitrii
- LinkedIn: https://www.linkedin.com/in/dmitrii-leonov/