Just Some Notes

Android Engineer @ Tumblr. Notes on this and that. No notes on anything in particular.

[intercal]

when I’m writing code I find that comments are more than just a tool for explaining what’s going on - a lot of the time, I have to explain to myself why I didn’t do something a certain way, as to avoid dumb half-hour mistakes that get me into the same previous mindset I was in when writing the code

comments are important, not just to know why you did do something, but also to know why you didn’t do something.

[sumbulalvi]

Very true. Comments do have a place in a code base. Many times, comments are dismissed as content that only clutters the codebase, however if used correctly, they can save future developers and yourself from introducing regressions, bugs and overlooking a corner case that's not obvious.

However, before writing a comment, you should question whether you can extract logic to well named variables or refactor the code to make it more readable and clear without comments.

My 2¢.

[sumbulalvi]

@SuppressWarnings(?)

Usually, IntelliJ’s IDE warnings should be listened to and followed. After all, they’re WARNINGS for a reason. Some reasons include naming conventions, clean coding standards, or possible runtime errors that can occur. However, in the rare case, warnings may not be applicable and just become annoying. 

Recently I was working on a project that required a lot of plain calculations and plain mathematics, I found that not a lot of the warnings applied. This is a scenario you can use the following handy annotation:

@SuppressWarnings(”warningName”);

You can annotate a piece of code or method or even an entire class with this annotation and make those warnings disappear, or “suppress” them. I found a handy list of of warning strings compiled by James Roper you can use for many different situations here:

https://jazzy.id.au/2008/10/30/list_of_suppresswarnings_arguments.html

Suppress Responsibly.

[sumbulalvi]

startActivityForResult() Shenanigans

A Fragment's onActivityResult() will be called after the host Activity's onActivityResult You can set a targetFragment in your fragment using setTargetFragment() and later retrieve it. It is useful for passing around data between fragments, but should be used carefully (i.e. that is really the host Activity's job! A clever usecase of using a Target fragment would be when receiving an onActivityResult() on one fragment but you want another to handle it. This would be a common usecase implored in 'headless fragments' that are meant to be helpers.