Tech-Thoughts

Infrastructure - Architecture & Performance Android Vitals - More visibility in Google Play dev console on battery drain, wakelocks being held for too long, ANRs, crashes, dropped frames, and frozen frames. Architecture components - better handling of the lifecycle, Room (ORM for Sqlite), live data observers. The API looks clunky though. Performance 50% 1-star reviews mention stability & bugs. 60% 5-star reviews mention speed, design, or reliability. Apps with > 5% crash rate have 30% higher uninstall rate. Emerging Markets > 100M users came online in 2016. 1B 2G devices expected in 2020. 50% of India is on 2G 33% users run out of storage in India every day. Data is expensive - it costs ~$2 to download a 40MB free app in India 53% users abandon websites if it takes more than 3 seconds to load Action items ...

iPhone iPhone iPhone 3G -> iPhone 3GS iPhone 4 -> iPhone 4S iPhone 5 -> iPhone 5S iPhone 6 -> iPhone 6S (and plus sizes) iPhone 7 (and plus sizes) Android Nexus One Nexus S Galaxy Nexus Nexus 4 Nexus 5 Nexus 6 Nexus 5X & Nexus 6P Pixel & Pixel XL While iPhone is recognized as a global name while erstwhile Nexus and now, Pixel has almost no branding outside of the Android fanboys. ...

Our brain loves distractions, and multi-tasking gets bored quickly. When we read text or watch a photo, it engages us visually, a video (with audio) engages us even more. The bandwidth of eyes is much larger than the bandwidth of our ears. When we are watching something, it utilizes more bandwidth and hence occupies more of our attention span. Also, given the way our eyes work, we can focus more on the exciting aspect of the visual feed. Compared to that, audio underutilizes our brain’s bandwidth. Further, the unidimensional flow of audio data at a linear speed does not mimic our ability to process it. Contrast forced direct listening with how non-linearly humans read. ...

Consider two systems: the first is 90% reliable and the second is 99%. The wrong to compare them is to compare the reliability and conclude that the second one is 9% (or 10% if you take 90% as the base) better. The right way to compare them is to compare the unreliability and conclude that the first system fails in 10% of the cases while the second fails only in 1%, making it 10X more error-prone than the second. The reliability comparison is a vanity matrix while the unreliability comparison not only demonstrates the user perception (“The user saw ten crashes in past one hour” vs “The user saw one crash in past one hour”) drastically but also shows the effort that goes into making the system more reliable. ...

All consumer internet products are either about consumption, production or both. A blog site is primarily about consumption. A photo transforming app is primarily about production. Social networks are consumption heavy. Good Messaging apps are symmetric. And a grievance collection product like BBB is production heavy. Building aggregation on top of similar products is a well-known strategy. The hard realization to note is that it can succeed only in very specific scenarios. Look at all the successful aggregation products, travel booking sites, news aggregators, RSS readers, discount coupon aggregators. As opposed to that, attempts to write an email aggregator, a social media aggregator etc. have not been as successful. And that’s the underlying theme, aggregator works well for consumption only interfaces where the product is sourced from many sources (more the better) and is standardized in the eyes of the consumer. They have limited success almost everywhere else. And this just doesn’t apply to software products. Microsoft tried and failed to have their own hardware stores since their offerings were similar and a subset of BestBuy whereas Apple succeeded in the same strategy despite the naysayers. ...

Articles with the following titles would be considered a joke “BMW is planning to merge its series i5 cars and Motorrad bikes” “P&G is planning to merge tissue paper and toilet paper” “Arm and Hammer is working on merging face wash, body soap, shampoo, laundry detergent, and dish cleaner” Not that these combinations can’t be made or have never been made but consumers would just not buy them. They are usually inferior or more convoluted, or even worse, both. ...

In 2001, Amazon’s share price crashed from 100$ to 6$, they had to do a 15% layoff. But it was Jeff Bezos’s perseverance, tenacity and grit because of which Amazon survived. As several startups from the Bay area to Bangalore get a mark-down of their valuations, the question about how many will survive and eventually produce a [positive] return for their investors is being asked. Between what a startup’s real value is and how viable is its business model, the real question to ask is how committed are the founder(s) to make things works. In the longer run, only that will matter. ...

Apple Siri, Google Now, Amazon Echo, and Microsoft Cortana have garnered a lot of press lately. But one thing which is still missing out is voice-native user experience. Let me illustrate that with the evolution of user experience on touchscreens. When they first came out, there was a stylus, and that’s it. It was an inferior version of the mouse-keyboard-monitor trio. Then some fantastic interactions were invented. Interactions like double tap to zoom, multi-finger rotation, swipe to like/dislike, pull down to refresh, long-press for options, and a Swype keyboard. All of these were native to a touchscreen-based environment. Porting them back to a mouse-keyboard-monitor trio was of limited utility at based and useless at worst.

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. ...

General Multitasking - multi-window mode and picture-in-picture mode. This includes the ability to launch window in adjacent activity, and drag and drop between activities. Notifications - Custom quick settings tile for an activity Multi-locale - users can specify locale beyond their primary locale ScopedDirectoryAccess for the shared storage New file-level encryption mode (as opposed to block-level encryption) and the corresponding Direct Boot Java 8, Jack, and ndk support in Gradle GCC deprecated in favor of Clang TechTalk on Image size/compression PNG - Get image down to 256-bit palette (if possible) or compress them using Zopfli. Test the difference with butteraugli Convert PNG to Vector drawable using Potrace. Vector drawable are natively supported on Android 5.0 and above. Use compat to use them on the older versions. Or generate PNG for the older versions (not recommended) WebP is another option (Note: Speaker failed to mention that WebP is natively supported only on Android). Avoid JPEGs. They are usually larger in size.