Messages from Log.wtf() sound pretty bad

    Notifications like that of Google Play Music offers more details and real estate to work with. However, it is available only from version Jellybean (API 16 and above). The documentation recommends using NotificationCompat.Builder API for fallback behavior on older API levels. The API levels can be handled at runtime and this blog is about posting a custom layout as an expanded view just like Google Play Music.       First, lets create a custom layout for our own style needs,     Now that we have a layout, we just have to inflate it and associate it with the Notification API. In case of NotificationManager, inflation of custom layouts is handled by RemoteViews.           NotificationCompat.Builder builder = new NotificationCompat.Builder(this)                                             ...

There is enough documentation as to how to collect the trace data, load it in TraceView etc. This post is just about the analysis of the collected trace data for CPU based operations. The data in this case is for AOSP browser running Google home page on an API 19 based emulator. The web page for most part was static except for the animating google doodle.   TraceView's snapshot over a period of 45 seconds looked like this. Clearly the main thread is the most active thread and the top level accounts for 38 seconds of CPU usage.    Clicking on the top level expands the functions called from here. The handler in this case accounts for 17 seconds worth of operation.    Clicking on the handler expands the next set of functions in the stack frame.    The handler is basically processing a callback for most of the time,    And its basically a callback corresponding to Choregrapher's FrameDisplayEventReceiver. Cl...

   Android's view attributes could be defined in different places like layout, styles and theme. This however leads to a possibility where in an attribute could be defined in multiple places and in such cases, android gives more preference to local specification in the following sequence (based on Android Kitkat 4.4)   * The value specified explicitly in the layout get first preference                 android:textColor="#ff10ff30"   * The value specified by a style gets the next preference                  style="@style/TextStyle.Red"   * The value specified by a style in the corresponding activity's theme gets the next preference. The value is picked from the activity's theme definition of textStyle.                 style="?attr/textStyle"   * The value specified by a style in the corresponding application's theme gets...

   Android's style property is often used to either directly refer to a specific style or a theme specific style via reference attributes . This works fine in a layout, however in some cases the Java source code of a custom view might need to do the same. In such cases, trying to directly use the reference attribute via R.attr isn't going to work as that is just going to give the id of the attribute and not that of the resource being referred to. In C style, it would be like a ptr instead of *ptr. The dereference can be performed via the current theme.     TypedValue resolvedValue = new TypedValue();     context.getTheme().resolveAttributes(R.attr.referenceAttributeName, resolvedValue, true);     int actualResourceId = resolvedValue.resourceId;     actualResourceId could now be used for any APIs which expects the resource id like setImageResource() etc.

     Beauty of Android's UI design is a very good separation of concerns for application developers and the user interface folks. In my experience, the user interface folks don't prefer looking into the code and figure out as to how an UI element's style is implemented and in some cases they don't even want to look at the layout resources. All they have is a document describing the look and feel of the application and their desire to work only with styles and theme files. Fortunately, Android supports this by providing reference attributes. These reference attributes can refer to styles, drawable resources, color etc. attrs.xml     styles.xml layout.xml     Application developers can use the desired styles via reference attribute, instead of directly specifying the view attributes. The only catch is that the attribute should point to a valid style in the current theme. themes.xml    User interface folks can just use...

    I came across this interesting problem where in the style specified by an attribute wasn't actually applied to the list view item. The items were inflated by an adapter and it used a simple layout with style specifications. style = "?attr/listViewItemStyle " android:layout_width = "match_parent" android:layout_height = "wrap_content" android:clickable = "true" >     listViewItemStyle is a reference attribute pointing to a style in a theme. In this application, the attribute was set fine in the theme and the theme was explicitly applied to the activity hosting the list view and yet the style wasn't applied to the list view items.     Upon closer look, it turned out to be a context issue. The adapter which inflated the list view items used the application context instead of an activity context and hence was using the application's theme to apply styles to inflated views. In this case, the application wa...