Android: Don't use stale views

In MusicSync , one of the views became complex and too slow to be inflated on the UI thread. So, I decided to do some Pooling around it to inflate it on the background thread and use it on the UI thread. This made the UI snappier, reducing multiple-second load times when opening some folders. However, soon I ended up with an edge case where re-opening the activity (and not the app) led to a semi-functional app. This edge case is hard as it gets triggered only in particular scenarios where the user destroys the activity via swipe up. At the same time, the app keeps running due to the attached foreground service that’s playing the media. And on activity re-creation, I got stale views! ...

When to commit Generated code to version control

Generated code, ideally, should not be committed to version control. Committing generated code can sometimes speed up testing and code generation but it is a design smell. It is better to cache generated code via CI caching . Committing generated code to version control is the worst as it is hard to even detect the difference. However, there are a few specific circumstances where committing generated code/config/data to version control is worth it. ...

React Native

There are tons of hyped-up claims surrounding React Native that are worth addressing. The reasons why companies run for React Native are usually, We already use Javascript for the website and now, we can build apps in that as well. We can use one codebase for Android, iOS, and web apps. Or at least, Android and iOS apps. Facebook uses it

How many source-code repositories should a startup have

Recently, this question came up during the discussion. “How many source-code repositories should a startup have?” There are two extreme answers, a single monorepo for all the code or repository for each library/microservice. Uber, for example, had 8000 git repositories with only 200 engineers! I think both extremes are wrong. Too many repositories make it hard to find code and one single repository makes it harder to do simple things like testing , bisecting (to find buggy commit), deciding repository owners.

The two-step approach to big code modifications

We all have to make significant code changes from time to time. Most of these code changes are large. Consider the scenario that you merged one such significant change, and then other team members made a few more changes on top. Then a major bug is detected. You desperately make the fix. It makes it in. You declare a victory, and a few hours later, your colleague notices another bug/crash/performance regression. Your commit cannot be reverted. It isn’t just about you. Many others have built on top of the change you made—the code sloths along in this broken state for a few days before you eventually fix it. Everyone has faced this issue at some point or the other.

Consoles by Google

A single developer has to sometimes deal with 7 different consoles by the same company…

File size should always be of "long" type

Java 1 2 3 int getTextFileSize(String fileName) { return (int) (new File(BASE_DIR, fileName).length(); // WRONG } A 32-bit signed int can deal with ~2GB worth of data. And if your code is not going to deal with files larger than 2GB, why worry? But what if someone wants to use the same code for a video file some day? Or What if someone writes another code to iterate over all the files in the BASE_DIR directory? Most likely they will be inclined to use int for the final sum as well. Adding integers in most languages results in int and automatic overflows into a negative number (and even worse, back to a positive number). The caller code might think that BASE_DIR does not exist. Therefore, the best future-proofing is to never have file size stored as an integer. Even, Android platform got it wrong with StatFs#getBlockSize and corrected it by adding StatFs#getBlockSizeLong . ...

Basic GDB Tutorial

So, you believe there are bugs in your C/C++ code or you have encountered SEGFAULT while executing your code. What will you do? write a lot of printf statements at various places in your code under suspicion OR use gdb (GNU code debugger) This article is about Approach 2

GCC Hacks

A small list of GCC Hacks g++ -o helloworld helloworld.cc produces helloworld binary from helloworld.cc C++ file. use -Wall switch turns on all warnings(potential errors) in the code (like unused variables) g++ -E helloworld.cc generates output code after the pre-processing stage.