Since the early days of Android, there has been an ongoing debate about whether or not enums should be used due to their overhead in memory consumption. Google has long been in favor of using int constants as a substitute and even go as far as saying enums should be strictly avoided. A memory comparison between the two methods is neatly outlined in this Stack Overflow answer.
Recently, this debate has come back into the spotlight. One reason for this is that Google has been pushing the issue lately as part of their #perfmatters campaign, which educates Android developers on performance related topics. They’ve also released a new support annotations library containing the @IntDef annotation, which provides compile-time type checking for int constants (I wrote an article on it here). As a result of all of this, there has been backlash from some prominent community members regarding the merit of Google’s stance on enums.
At some point you may find yourself needing to implement a splash screen for your Android app. Reasons for doing so include matching an existing design for iOS, performing necessary background work at start up, or simply for the visual appeal alone. It should be noted that splash screens are certainly not required in your app. In fact, some feel that they should be avoided entirely. Still, it is not uncommon to come across Android apps that utilize a splash screen.
This article provides a detailed outline for implementing a splash screen on Android. While the implementation is relatively straight forward, there are a few details that often get overlooked. We’ve also provided a working sample project that can be run on your device or emulator.
My first encounter with the UIAppearance protocol came after many frustrating hours of hunting down an inexplicable bug. In a recent project here at MIL, every UISegmentedControl object in our app had its appearance altered after segueing to a specific view controller. New to the iOS platform and oblivious that such a protocol existed, I had no clue why such behavior was occurring.
I eventually stumbled across the following line of code in the aforementioned view controller:
A quick web search returned several results describing the UIAppearance protocol and its ability to customize UI components across a single app. Clearly, this line of code was unintended since we did not want the second segment of every UISegmentedControl to have a fixed width.