Sometimes it just works | Less is more

Sometimes It Just Works

On my last open source work update, I was interested at working on K9-Mail and targeted a particular Issue. However, there was something weird with it – at times the Issue was able to be replicated but sometimes it wasn’t able to be replicated. To demonstrate this, let’s take a look at the steps to replicate the problem:

The email author has no PGP key setup in the OpenKeychain app.

Compose mail to PGP recipient.

Toggle Encryption to “Encrypt” (green lock symbol)

Hit the “Send” button.

Email author has no PGP key setup and only the recipient(John Smith) has a PGP key setup (same device):

Now, we compose an encrypted email to the recipient and attempt to send it:

As it can be seen here, the Toast displayed the appropriate error instead of the “Send Error: Null” that’s reported in the Issue. Sometimes I was able to replicate the same Issue with the exact same steps but I can barely capture it because it rarely happens and I’m sure that there’s another extract step involved in it, and even then I can’t really say for sure that this would require fixing. Until another Issue comes up with this kind of problem, I don’t see how or why should I make a PR for this kind of Issue because the error message is properly displaying most of the time.

Therefore, I wanted to move on to another Issue that can be solved.

A Familiar Place

I checked in on TravelMate’s repo and found an Issue where I knew I could actually finish and can be easily replicated. It’s also a simple matter of refactoring code which I have done before too.

The Problem:

As seen above, when TravelMate first starts up as an app and the user has not logged in yet, it asks for a bunch of permissions. These permissions are necessary for some functionality in the app but it’s not always necessary, therefore it just bogs down the user’s experience of using the app for the first time if they don’t know what to do with the permissions. That is not the worst case though, the worst case is that a privacy-focused user can just deny all these permissions in the app because they think that these permissions aren’t necessary since they haven’t fully tried out the app yet.

Simple Solutions For Less

Since the code for the runtime permissions is already available, what I basically had to do is just move them to other parts of the app that actually need them. From the LoginActivity.java file and moving it to the HotelsActivity.java:

It’s not much of a coding work, but it’s an honest day’s worth of work that can improve user experience for the app, as can be seen in the GIF below:

Less Is More

As shown above, the permissions are now only relegated to being asked when the user selects the ‘Travel’ section of the app because these permissions are actually required to use the features under the Travel section of the app – in this case, possible hotel bookings depending on the user’s location.