On My Mind Today

I was recently introduced to IntDef and StringDef interfaces by a co worker. I was using enums to maintain a list of constants for some purpose and he suggested me to use these interfaces. I went ahead to read more on that and would be sharing here what I learned. So, it turns out that enums often require more than twice as much memory as static constants (quoted from andev docs ). They are class objects, so : A single reference to an enum constant occupies 4 bytes Every enum occupies space that is the sum of all its fields’ sizes and overhead of an object the class itself occupies some space. Whereas constants require fixed space, 4 bytes in case of an int constant and (num of chars) * 1 bytes in a string constant. That said, we can replace enums with constants only in cases where we are just using them as constants. In cases where we are storing more (or complex data) data in enums, or using method overloading (every enum constant can have it’s own implementation of a ...

This one is a pretty small but useful tip. For people who don’t know about it, Android provides a class by the name ApplicationInfo . As stated by the docs, this class provides information about your application and it collected from the Android Manifest’s <application> tag. It might not sound useful right now, but may come handy for some use cases : Data directory for your app : Checking if the app is debuggable or not Name of the process of your application Default Task Affinity of all the activities in the application Full path to the base apk of the application Let me know in case of any doubts. Cheers !

Let’s start with defining some terms : MotionEvent : Every User event in android is wrapped in the MotionEvent class by the framework. It describes user’s current action as well as other metadata such as touch location, no. of pointers and the time when it occurred. MotionEvents first flow top down in view hierarchy and then come back to the rootview unless they are handled somewhere (explained later) in between. So, a parent always has the control of what to do with an event before sending it to children. Each view/viewgroup has two functions that are involved in touch handling : dispatchTouchEvent : This function is called by a view’s parent to pass it a touch event. The aim of this function is to appropriately route this touch event. It may want to consume this event itself : calls it’s own onTouchEvent method (explained below). pass it to the children : calls child’s dispatchTouchEvent method. a listener : calls listener’s onTouch method if it has been set. Remember,...