Haram things to do as an Android Developer🤖

Dony “A” Nuransyah
3 min readJun 27, 2021

--

Back then(before the pandemic spread all over the world) at my mobile team. We are usually say`haram`(something you shouldn't do) every time we saw smell code or bad code however we still use linter but as a seasoned developer #selfclaim, we tried to prevent it earlier, so without any further do here is haram things as Android Developer, I tried to wrap it up :

  1. Create a PR with bunch of code changes because it will make teammate frustrated and don’t forget they have tasks too.
  2. Forgot to clear Databinding when fragment destroyed especially when we use retain fragment.
  3. Forgot to dispose of the I/O task when ViewModel has been disposed of.
  4. Initialization of an object inside the onDraw method, it will cause GC frequently.
  5. Do invalidate view, when we don’t have to.
  6. Use draw method not in hardware accelerated.
  7. Forgot to release some memory cache when onLowMemorycallback called by the OS.
  8. Using a view reference inside an asynchronous task because it will cause a view leak.
  9. Using a view reference on a static object it will cause a view leak.
  10. Using a generic hashMapcan cause a large memory heap because it needs a separate entry object for every mapping better use arrayMap by the android framework.
  11. Overuse abstraction on code, abstraction comes at a significant cost: generally, they require a fair amount more code that needs to be executed, requiring more time and more RAM for that code to be mapped into memory, so be careful even though it makes the code clean.
  12. Not evaluate if object pools benefit the use case and choose to drop the allocated object and then initialize the new one, however its not for all cases.
  13. Doesn’t measure reflection impact on code performance, because reflection will create a memory footprint if not handled correctly.
  14. Doesn’t care about user connection speed when fetching data, because it related to prefetching strategy and going to be really tricky if a user on the slow network and we force the user to fetch a lot of data then the user will wait longer, if we fetch too little then we are not optimizing the bandwidth.
  15. Not aware when lot of short dips on the memory monitor tool, because it is a huge problem, will make our app janky because the system doing GC frequently.
  16. Using serializable rather than parceable to passing data.
  17. Not Using ClipRect to onDraw method when we have some overdraw UI.
  18. Not calling stopServiceand just call unBindto stop the service, service is run on UI thread though.

Might you ask why no example code or piece of code how to tackle this problem, well I thought this problem is going to exist as long as application exist because it’s part of development cycle, and code is art, unique and different based on developer perspective. However API documentation and google is a friend if you want to find some example use case and how others manage to solve the issue.

others article you might want to read :

How to become a better Android developer: 30+ bite-sized pro tips | TechBeacon

Top 10 Most Common Mistakes That Android Developers Make | Toptal

--

--

Dony “A” Nuransyah
Dony “A” Nuransyah

Written by Dony “A” Nuransyah

“Pessimists sound smart. Optimists make money.” ― Patrick Collison

No responses yet