Updated 20 June 2017
There are a lot of tricks and shortcut that “lazy” developer(s) uses in their daily routine. Here is a list of few tips and tricks that might be helpful during android programming.
Adding tag always helpful. It is a good practice to add one TAG to identify any .java file. The main use is for logging and debugging. It is efficient to have one TAG for each .java file instead of having random tags or a Global tag. You might not be logging in some file like model classes but still, you should add TAG in it.
There are already predefined shortcuts like logt, logd in the android studio to make this work easy for you.
1 2 |
@SuppressWarnings("unused") private static final String TAG = "DashboardData"; |
Exceptions are always thrown even if you code with utmost validation. So it better to let the user aware of the problem or handle the situation efficiently rather than leaving the empty catch block or printing the stack trace.
It is better to write all the existing cases, designing the complete view, applying attributes and like that at once rather than writing code line by line or adding an attribute on a view to check the effect. This is seriously a non-efficient approach of doing a thing. Plus, this will eventually increase the productivity and you will never cry for the slow build time for your setup.
For clean code, you must follow the standard programming guidelines, design patterns, and clean project architecture. Remove code only when you are assured that you will not need it.
You must never take NPE with ease, otherwise, you will end it an ANR (Android not responding).
You can use various tricks like:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
i. Using ternary operators to check null's: data == null ? true : data.items ii. returning empty string from accessor methods: public String getName() { if (name == null) { return ""; } return name; } iii. Using annotations like @NonNull: public SignUpRequest(@NonNull String login, @NonNull String password) |
As Human make mistakes and always miss something.
There is no need to use refractor “judiciously”. Just review what changes are going to refractor and you are good to go. Use arrows to navigate and view changes just like we do in the todo(s).
to achieve this you can prepare the todo(s) in your application project. You can prepare bookmark that you want to continue with. Instead partially completing it and moving to one another. I am sure one can be more focused and productive using this approach.
Apart from debugging using a debugger, we can use it for multiple purposes. E.g. checking the content of data etc. It is not necessary to override toString() method of a model we can use the debugger to check its key and value e.g. RemoteMessage class of Firebase messaging there is no overridden toString() method and thus it is little tricky to log all the data arriving when onMessageReceived(RemoteMessage remoteMessage) is called. It’s better to add a breakpoint and check the content of the remoteMessage would be handy.
It will be helpful to handle and perform common task. Especially where lifecycle is related like BaseActivity, Base Fragment etc.
If you have more details or questions, you can reply to the received confirmation email.
Back to Home
Be the first to comment.