While currently working on a new app, I decided to use a PagedView with 3 screens. I was surprised that the 3rd screen will always show what is displayed in the first screen. I tested to see what would happen if I use 4 screens. The same thing happened: the 4th screen displayed the contents of the 2nd screen.

I was confused why it acted like this. Instantiating new views on the 3rd and 4th position will work. However, I wanted to find a way where the views had to be reused rather than creating new instances because more memory will be used.

I asked Cyril, the creator of Greendroid if this is a bug or not. This is his answer.

The PagedView is based on a reuse mechanism really similar to the one used by ListView. As a result, once a new page is required, the PagedView asks the PagedAdapter a new page trying to reuse a old page (that is a page that is no longer visible on screen).
This is the reason why you have at most 2 pages instantiated : you have to reuse the previously created pages.
If your pages are really different, you can by-pass this behavior by not reusing the convertView. Just keep in mind having a very small number of pages as it will probably imply having a large number of pages in memory at the same time (hence a large number of Views).

I guess having multiple paged views at 3 screens is enough. Going beyond that is probably overkill. If you can make it up to 2 screens only, then the better.

GreenDroid has a great widget called a SegmentedBar where an app can display information in different sections much like how tabs work but they all get loaded at one time.

From the developer of GreenDroid, he describes a SegmentedBar as a bunch of segments where each segment has an indicator that can be on or off depending on its current state (checked or not). Once you are tapping a segment, the associated view is displayed.

Each of these segments is represented by a CheckBox widget. There came a point wherein I wanted my app to show only images without any text. The problem was that even if I managed to center the default checkbox image (the one with a checkmark), it did not center itself when I set a custom drawable image like the ones below.

There was always an extra space on the right that made the drawable images not aligned to the center. So how did I manage to make the custom drawables aligned to the center (pictured above)? By creating my own custom CheckBox class.

I also extended GreenDroid classes related to the SegmentedBar (no sense modifying the source in GreenDroid in case of new updates, right?) to cater to the XML layout file of the CheckBox widget.

Here is the segmented bar background 9-patch image that I trimmed. Save it as segment_bg.9.png.

Here is a sample drawable state list on for a checkbox. Make sure you place this in the drawables folder.

Here is the segmented XML file that covers the CheckBox. I purposely placed another LinearLayout layer on top of the CheckBox widget to center it within the layout.

To make this work, here is a sample code that assigns a drawable to each segment. For this sample, I have 6 segments in total.

If you wondered why the index is in increments of even numbers, it is because the odd numbers represent the divider drawable image that divides each segment.

So there you have it. It took me quite some time to figure this out. I had to dig into the CompoundButton class to see what methods I could override to make the icons of segments without text aligned to the center.