{ "version": "https://jsonfeed.org/version/1.1", "title": "Kyle Mallette", "description": "A blog about programming the web and Android", "home_page_url": "https://www.kylemallette.com/", "feed_url": "https://www.kylemallette.com/feed.json", "language": "en", "authors": [{ "name": "Kyle Mallette", "url": "https://www.kylemallette.com/about/", "avatar": "https://www.kylemallette.com/images/me.jpg" }], "items": [ { "id": "https://www.kylemallette.com/android/2013/09/16/refreshing-lists-part2.html", "url": "https://www.kylemallette.com/android/2013/09/16/refreshing-lists-part2.html", "title": "Refreshing ExpandableListView", "summary": "Refreshing visible ExpandableListView items: flat list, packed, group, and child positions, and how ExpandableListConnector maps between them.", "content_html": "

Refreshing visible ExpandableListView items has some extra steps and concerns. A quick glance at ExpandableListView’s source shows that relatively few inherited methods are overridden. Instead, ExpandableListConnector does the heavy lifting for ExpandableListView’s extra functionality.

\n\n

Internally, this connector translates the flat list position that the ListAdapter expects to/from group and child positions that the ExpandableListAdapter expects.

\n\n

If you browse the whole file, you’ll find some TODOs and get the feeling that the Android team probably didn’t get to spend as much time as they may have wanted on this widget. Thankfully, they’ve provided us some convenience methods to translate positions in a mostly straightforward manner which gives us access to some of ListView’s functionality directly.

\n\n

Do you mean position, position or position?

\n\n

As the heading hints at, ExpandableListView and ListView have different terminology to differentiate which type of position is being used. Inside the ExpandableListConnector source, some helpful implementation notes were left for us defining three types of positions. Along with the published ExpandableListView docs, we get a decent picture of the four position types we’ll be using. I imagine you’re already familiar with group and child positions, but I’ve listed them for completeness anyway.

\n\n
\n
\n Flat list position:\n
\n
\n The position used by ListView and its adapters\n
\n\n
\n Packed position:\n
\n
\n A long that \"packs\" (bit twiddling) what type of position (group, child, or null for headers/footers) as well as the position value(s) (group/child values)\n
\n\n
\n Group position:\n
\n
\n The position of a group among all the groups used by ExpandableListView and its adapters.\n
\n\n
\n Child position:\n
\n
\n The position of a child among all the children in a group used by ExpandableListView and its adapters\n
\n
\n\n

Note: We’re going to be dealing with 5 different kinds of positions for our color refresh example. The other type if you recall from the previous ListView color refresh example, is the ViewGroup position we used with getChildAt(int position).

\n\n

Two methods allow us to convert flat list positions to packed positions and vice versa:

\n\n


\n\n\n \n \n \n \n \n \n\n \n
Public Methods
longgetExpandableListPosition(int flatListPosition)
\n Converts a flat list position (the raw position of an item (child or group) in the list) to a group and/or child position (represented in a packed position). This is useful in situations where the caller needs to use the underlying ListView's methods.\n
intgetFlatListPosition(long packedPosition)
\n Reverses the conversion from a packed position to a flat list position.\n
\n\n


\n\n

Finally, five static methods allow us to pack group/child positions and unpack packed positions. These first three take a packed position and return which type of ExpandableListView (group and child positions) position it is and the position value(s). Note that for a PACKED_POSITION_TYPE_CHILD both group and child position values are packed up.

\n\n


\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Public Methods
static intgetPackedPositionGroup(long packedPosition)
\n Gets the group position from a packed position.
static int getPackedPositionChild(long packedPosition)
\n Gets the child position from a packed position that is of `PACKED_POSITION_TYPE_CHILD` type.
static intgetPackedPositionType(long packedPosition)
\n Gets the type of a packed position.
static longgetPackedPositionForChild(int groupPosition, int childPosition)
\n Returns the packed position representation of a child's position.
static longgetPackedPositionForGroup(int groupPosition)
\n\n Returns the packed position representation of a group's position.
\n\n


\n\n

Possible packed position types are:

\n\n


\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Constants
intPACKED_POSITION_TYPE_CHILD The packed position represents a child.
intPACKED_POSITION_TYPE_GROUPThe packed position represents a group.
intPACKED_POSITION_TYPE_NULLThe packed position represents a neither/null/no preference.
\n\n


\n\n

Here’s a quick code snippet to illustrate the conversion flow:

\n\n
/*  FlatList position  ->  Packed position  ->  ExpandableList Group/Child positions\n *           ^                    ^                              ^    ^\n *        integer                long                           integers\n */\n\n  // 1. Flat list position  ->  Packed position\n  long packedPosition = getExpandableListPosition(flatListPosition);\n\n  // 2. Unpack packed position type\n  int positionType = getPackedPositionType(packedPosition);\n\n  // 3. Unpack position values based on positionType\n  //    if not PACKED_POSITION_TYPE_NULL there will at least be a groupPosition\n  if( positionType != PACKED_POSITION_TYPE_NULL ){\n\n      groupPosition = getPackedPositionGroup(packedPosition);\n\n      if(positionType == PACKED_POSITION_TYPE_CHILD){\n          childPosition = getPackedPositionChild(packedPosition);\n      }\n\n  }else{\n      Log.d(\"FooLabel\", \"positionType was NULL - header/footer?\");\n  }
\n\n

The reverse is a breeze.

\n\n
 /*  To Convert from an ExpandableList position to a packed position there's\n  *  only two steps.\n  *    1. Pack up our ExpandableList position. Two methods are available to pack\n  *       up the two kinds of ExpandableList positions; group and child.\n  *    2. Convert from a packed position to a flat list position\n  */\n long packedPosition =\n         getPackedPositionForGroup(groupPosition); //For a group position\n         getPackedPositionForChild(groupPosition, childPosition); //For a child position\n\n // Can now use this to access ListView functionality directly\n int flatListPosition = getFlatListPosition(packedPosition);
\n\n

Now Can We Refresh Visible Items?

\n

Yes! Now that the various positions values make sense, let’s implement our color refresh example.

\n\n
// Declare the initial list item colors\nprivate int             groupTextColor  = Color.BLACK;\nprivate int             childTextColor  = Color.BLACK;\nprivate int             childBgColor  = Color.WHITE;\nprivate int             groupBgColor  = Color.WHITE;\n\n/*  Grabs the user color inputs and converts them proper integer color values.\n *  Since we're working on an ExpandableListView, we'll need four inputs for\n *  group and child text colors as well as group and child background colors.\n *\n *  Definitely check out Color.parseColor(String). It's very handy!\n */\nprivate void retrieveColors() {\n\n    if (mGroupTextColorInput.getText().length() > 0)\n      groupTextColor = Color.parseColor(mGroupTextColorInput.getText()\n                                                            .toString()\n                                                            .toLowerCase());\n    if (mChildTextColorInput.getText().length() > 0)\n          childTextColor = Color.parseColor(mChildTextColorInput.getText()\n                                                                .toString()\n                                                                .toLowerCase());\n    if (mChildBackgroundColorInput.getText().length() > 0)\n      childBgColor = Color.parseColor(mChildBackgroundColorInput.getText()\n                                                                .toString()\n                                                                .toLowerCase());\n    if (mGroupBackgroundColorInput.getText().length() > 0)\n      groupBgColor = Color.parseColor(mGroupBackgroundColorInput.getText()\n                                                                .toString()\n                                                                .toLowerCase());\n}\n\n/*  Applies the user supplied color values to the visible list items. This\n *  does not touch the recycled off screen views.*/\nprivate void applyColors(){\n\n  View listItem;\n  ViewHolder mHolder;\n\n  retrieveColors();\n\n  int packedPositionType, groupPosition, childPosition;\n\n  // These are both implemented in AdapterView which means\n  // they're flat list positions\n  int firstVis = mList.getFirstVisiblePosition();\n  int lastVis = mList.getLastVisiblePosition();\n\n  /* This is the \"conversion\" from flat list positions to ViewGroup child positions */\n  int count = lastVis - firstVis;\n\n  long packedPosition;\n\n  while (count >= 0){ // looping through visible list items\n\n    /*  getChildAt(pos) is implemented in ViewGroup and has a different meaning for\n     *  its position values. ViewGroup tracks visible items as children and is 0 indexed.\n     *  This means you'll have 0 - X positions where X is however many items it takes\n     *  to fill the visible area of your screen; usually less than 10. */\n    listItem = mList.getChildAt(count);\n\n    if (listItem != null){\n\n      mHolder = (ViewHolder) listItem.getTag();\n      if (mHolder == null){ // This shouldn't happen, but we'll make\n                            // sure in case some strange concurrency\n                            // bugs appear\n        mHolder = new ViewHolder();\n        mHolder.mText = (TextView) listItem.findViewById(android.R.id.text1);\n        listItem.setTag(mHolder);\n      }\n\n      /*  Adding count, which is our current ViewGroup visible item position to\n       *  AdapterView's firstVisiblePosition which is a flat list position gives us\n       *  our current flat list position. From that we'll follow the flat list to\n       *  expandable list position (group/child values) flow:\n       *\n       *      FlatListPos > packed position > group/child position(s)\n       */\n      packedPosition = mList.getExpandableListPosition(count + firstVis);\n\n      // Using our static helpers to unpack what type of position this item represents.\n      packedPositionType = ExpandableListView.getPackedPositionType(packedPosition);\n\n      if (packedPositionType != ExpandableListView.PACKED_POSITION_TYPE_NULL){\n\n        /* If the packedPosition type isn't NULL then we know there has to be at least\n         * a group position value. If it's a child item, we'll additionally have a\n         * child position value */\n        groupPosition = ExpandableListView.getPackedPositionGroup(packedPosition);\n\n        if (packedPositionType == ExpandableListView.PACKED_POSITION_TYPE_CHILD){\n\n          childPosition = ExpandableListView.getPackedPositionChild(packedPosition);\n\n          listItem.setBackgroundColor(childBgColor); // Setting our child bgColor\n          mHolder.mText.setTextColor(childTextColor);// Setting our child textColor\n\n        }else{\n\n          listItem.setBackgroundColor(groupBgColor); // Setting our group bgColor\n          mHolder.mText.setTextColor(groupTextColor); // Setting our child textColor\n        }\n\n      }else\n        Log.d(  TAG,\n            \"Packed position type was null.\");\n    }else\n      Log.d(  TAG,\n          \"getChildAt didn't retrieve a non-null view\");\n    count--;\n  }\n}
\n\n

Applying Changes to All Items

\n

Once again, we find that although our adapter requires a bit more work compared to its ListView siblings, the strategy is the same. I’m using one ViewHolder for both since I’m using the same layout. You could make separate Holders for group and child items if they have some big differences. It’s up to you.

\n\n
@Override\npublic View getGroupView(int groupPosition,\n                         boolean isExpanded,\n                         View convertView,\n                         ViewGroup parent){\n\n  ViewHolder mHolder;\n\n  if (convertView == null){\n    convertView = getLayoutInflater().inflate(\n                                      android.R.layout.simple_expandable_list_item_1,\n                                      parent,\n                                      false);\n    mHolder = new ViewHolder();\n    mHolder.mText = (TextView) convertView.findViewById(android.R.id.text1);\n    convertView.setTag(mHolder);\n  }else\n    mHolder = (ViewHolder) convertView.getTag();\n\n  /* Since all visible items have had their appropriate user selected\n   * colors applied, we need to make sure any of the recycler's\n   * scrapped views (which wouldn't be touched by our visible item\n   * changes) also reflect our changes. */\n  convertView.setBackgroundColor(groupBgColor);\n  mHolder.mText.setTextColor(groupTextColor);\n\n  mHolder.mText.setText(getGroup(groupPosition).toString().toUpperCase());\n\n  return convertView;\n}\n\n\n@Override\npublic View getChildView(int groupPosition,\n                         int childPosition,\n                         boolean isLastChild,\n                         View convertView,\n                         ViewGroup parent){\n\n  ViewHolder mHolder;\n\n  if (convertView == null){\n    convertView = getLayoutInflater().inflate(\n                                      android.R.layout.simple_expandable_list_item_1,\n                                      parent,\n                                      false);\n    mHolder = new ViewHolder();\n    mHolder.mText = (TextView) convertView.findViewById(android.R.id.text1);\n    convertView.setTag(mHolder);\n  }else\n    mHolder = (ViewHolder) convertView.getTag();\n\n  /* Since all visible items have had their appropriate user selected\n   * colors applied, we need to make sure any of the recycler's\n   * scrapped views (which wouldn't be touched by our visible item\n   * changes) that may get returned also reflect our changes. */\n  convertView.setBackgroundColor(childBgColor);\n  mHolder.mText.setTextColor(childTextColor);\n\n  mHolder.mText.setText(getChild(groupPosition, childPosition).toString());\n\n  return convertView;\n}
\n\n", "date_published": "2013-09-16T00:00:00+00:00", "tags": ["Exploring Lists Series","ListView","ExpandableListView"], "image": "https://www.kylemallette.com/images/art/photography/st-johns-piano.jpg", "_markdown": { "about": "https://llmstxt.org", "url": "https://www.kylemallette.com/android/2013/09/16/refreshing-lists-part2.html.md" } }, { "id": "https://www.kylemallette.com/android/2013/09/15/refreshing-lists-part1.html", "url": "https://www.kylemallette.com/android/2013/09/15/refreshing-lists-part1.html", "title": "Refreshing ListView", "summary": "Why notifyDataSetChanged() seems to do nothing, what it is actually for, and how to refresh visible ListView items without replacing the adapter.", "content_html": "

If you’re like me, you’ve encountered situations where calling notifyDataSetChanged() on your adapter doesn’t seem to do anything. Certainly, something is happening, but that doesn’t seem to always cause your ListView or ExpandableListView to redraw on screen to reflect changes to your underlying dataset. Once again, trusty StackOverflow reveals that there’s some controversy surrounding this issue.

\n\n

Thankfully, the accepted answer is exactly what the Android team recommends. True to StackOverflow form however, the first comment on the accepted answer with more than a handful of votes, declares that notifyDataSetChanged() doesn’t work! Further down another user points out the gotcha’s that a lot of developers run in to; all of which, are discussed in The World of ListView from GoogleIO 2010 that I mentioned in the introduction to this series. If you haven’t watched it yet, I can’t recommend enough that you view it now.

\n\n

That should be the end of the story, right? Not quite. Even Mark Murphy, author of The Busy Coder’s Guide to Android Development and one of the foremost Android experts recently uncovered a bug in EndlessAdapter; one of his open source contributions which employs notifyDataSetChanged().

\n\n

For us mere mortals in the Android community, the heart of this issue is almost certainly a simple misunderstanding on what notifyDataSetChanged() and its companion notifyDataSetInvalidated() are used for. They are used to reflect changes to (or complete invalidation of) the dataset your adapter is pulling from and should be called on the UI thread immediately after making changes to your data. If you’re curious about what exactly is going on behind the scenes after notifying your adapter, take a look at AbsListView’s AdapterDataSetObserver and its call to AdapterView’s (super) implementation.

\n\n

Please Recycle

\n\n

By now I’m going to assume you’ve got warm and fuzzies about notifyDataSetChanged() and notifyDataSetInvalidated(). Let’s talk about what to do when you’re not making changes to your dataset, but still need to update some visual aspect of your list. You could scrap your whole adapter and replace it with a new one that reflects the visual changes you want, but that’s hacky and not performant. Remember that on mobile, poor performance means eating up your user’s battery even if the user doesn’t notice visual sluggishness. Fortunately, there’s a better way. You’re probably painfully aware by now that ListView and ExpandableListView use a view recycler that drastically increases performance. It achieves this by scrapping views as they fall off the visible portion of the screen and reusing only the few it needs. Those views are then returned to your adapter as the convertView parameter in getView(int position, View convertView, ViewGroup parent). If you’re curious about the recycler implementation, I encourage you take a look at the source. There’s even a RecyclerListener if you’re so inclined. This recycling strategy means we can make the visual changes we want to only the views visible on the screen and then let getView take care of making sure our recycled views look the way we want. Let’s jump in to a simple coloring example.

\n\n

Color Me not so Surprised

\n\n

In the full example project I’ve implemented some EditTexts for users to input desired text and background colors for our ListView items as well as button to apply those colors. As most of it is boiler plate, I’ll just show you the relevant bits here. ExpandableListView has some important implementation differences which make it a bit more complicated, but the strategy is the same. Feel free to skip ahead to the ExpandableListView example if that’s more relevant to you.

\n\n

ListView

\n\n

Refreshing Visible Items

\n\n

We’ll be using the provided getFirstVisiblePosition(), getLastVisiblePosition() and getChildAt(int position) methods to grab the visible item views and make our changes. It’s important that you don’t make any structural changes to your item views. Doing so will create performance issues caused by remeasuring and conflicts with optimization assumptions ListView makes. Implement getItemViewType(position) and getViewTypeCount() instead for structural changes as demonstrated here.

\n\n
// Declare the initial list item color variables\nprivate int bgColor = Color.WHITE;\nprivate int textColor = Color.BLACK;\n\n\n/* Grabs the user color inputs and converts them proper integer color values.\n * Since we're working on ListView, two inputs are needed; text color and\n * background color.\n *\n * Definitely check out Color.parseColor(String). It's very handy!\n */\nprivate void retrieveColors() {\n\n  if (mTextColorInput.getText().length() > 0)\n    textColor = Color.parseColor(mTextColorInput.getText()\n                                                .toString()\n                                                .toLowerCase());\n  if (mBackgroundColorInput.getText().length() > 0)\n    bgColor = Color.parseColor(mBackgroundColorInput.getText()\n                                                    .toString()\n                                                    .toLowerCase());\n}\n\n/* Applies the user supplied color values to the visible list items. This\n * does not touch the recycled off screen views.\n */\nprivate void applyColors() {\n\n  View listItem;\n  Holder mHolder;\n\n  retrieveColors(); //First we collect our user input and\n                    //convert it to valid integer color values\n\n  // These are both implemented in AdapterView which means\n  // they're flat list positions\n  int firstVis = mList.getFirstVisiblePosition();\n  int lastVis = mList.getLastVisiblePosition();\n\n  /* This is the \"conversion\" from flat list positions to ViewGroup child positions */\n  int count = lastVis - firstVis;\n\n  while (count >= 0) {  // looping through visible list items\n\n    /*  getChildAt(pos) is implemented in ViewGroup and has a different meaning for\n     *  its position values. ViewGroup tracks visible items as children and is 0 indexed.\n     *  This means you'll have 0 - X positions where X is however many items it takes\n     *  to fill the visible area of your screen; usually less than 10. */\n    listItem = mList.getChildAt(count);\n\n    if (listItem != null) {\n\n      mHolder = (Holder) listItem.getTag();\n      if (mHolder == null) {  // This shouldn't happen, but we'll make\n                              // sure in case some strange concurrency\n                              // bugs appear\n        mHolder = new Holder();\n        mHolder.mText = (TextView) listItem.findViewById(android.R.id.text1);\n        listItem.setTag(mHolder);\n      }\n\n      listItem.setBackgroundColor(bgColor); // Setting our user input\n                                            // background color\n      mHolder.mText.setTextColor(textColor);// Setting our user input\n                                            // text color\n    } else\n      Log.d(TAG, \"getChildAt retrieved a null view :( \");\n\n    count--;\n  }\n}
\n\n

Applying Changes to All Items

\n

Now that we’ve got our visible item updates working, we need to make sure all of our items reflect our color changes. For this, we just need to override our adapter’s getView(int position, View convertView, ViewGroup parent) method and ensure that each convertView we get shows the correct colors.

\n\n
@Override\npublic View getView(int position, View convertView, ViewGroup parent){\n\n  Holder mHolder;\n\n  if (convertView == null){ // ViewHolder pattern implementation\n    convertView = getLayoutInflater().inflate(android.R.layout.simple_list_item_1,\n                                              parent,\n                                              false);\n    mHolder = new Holder();\n    mHolder.mText = (TextView) convertView.findViewById(android.R.id.text1);\n    convertView.setTag(mHolder);\n  }else\n    mHolder = (Holder) convertView.getTag();\n\n/* Since all visible items have had their appropriate user selected\n * colors applied, we need to make sure any of the recycler's\n * scrapped views (which wouldn't be touched by our visible item\n * changes) also reflect our changes. */\n  convertView.setBackgroundColor(bgColor);\n  mHolder.mText.setTextColor(textColor);\n\n  mHolder.mText.setText(getItem(position).toString());\n\n  return convertView;\n}
\n\n", "date_published": "2013-09-15T00:00:00+00:00", "tags": ["Exploring Lists Series","ListView","ExpandableListView"], "image": "https://www.kylemallette.com/images/art/photography/st-johns-piano.jpg", "_markdown": { "about": "https://llmstxt.org", "url": "https://www.kylemallette.com/android/2013/09/15/refreshing-lists-part1.html.md" } }, { "id": "https://www.kylemallette.com/android/2013/09/09/exploring-list-expandablelist-adapters.html", "url": "https://www.kylemallette.com/android/2013/09/09/exploring-list-expandablelist-adapters.html", "title": "Exploring Lists and Adapters", "summary": "An introduction to Android's ListView, ExpandableListView, and AbsListView, the adapters behind them, and why they trip up so many developers.", "content_html": "

\"Android\nIf you’re working with Android, chances are you’ve run in to issues with ListView, ExpandableListView or their parent, AbsListView. I’m not ashamed to admit spending more than a couple evenings staring angrily at misbehaving lists and adapters. It’s almost a right of passage for new Android devs.

\n\n

The most frequently referenced question out of all Android tagged questions on StackOverflow is “How do I do a lazy load of images in ListView?”. Answering requires a non-trivial understanding of how these components and their adapters work along with a healthy dose of Android concurrency patterns. Poking around Stack Overflow, I found that of 380,906 Android tagged questions at the time of this posting, roughly 25,000 sport tags closely related to ListView, ExpandableListView or their Adapter partners roughly representing 5% of all Android tagged questions. In response, I’m kicking off a series of posts centered on ListView, ExpandableListView and their related Adapter partners. The basics and some much needed best practices are covered well2 and distributed broadly. Instead, I’m going to provide some working examples to reveal a few unexplored gotcha’s in ListView and the oft ignored ExpandableListView. Along the way, I’m going to slice open the source code reveal some of the least exposed innards of these components. There’s no better way to truly understand a framework than to dive in to the source. Enjoy!

\n\n

\n [2] If you haven’t seen The World Of ListView video from GoogleIO 2010, watch it before you write another piece of code relating to a ListView or Adapter! I can’t recommend it enough.\n ↩\n

\n\n", "date_published": "2013-09-09T00:00:00+00:00", "tags": ["Exploring Lists Series","ListView","ExpandableListView"], "image": "https://www.kylemallette.com/images/art/photography/st-johns-piano.jpg", "_markdown": { "about": "https://llmstxt.org", "url": "https://www.kylemallette.com/android/2013/09/09/exploring-list-expandablelist-adapters.html.md" } } ] }