So I was finally excited that my brother and I decided to drop support for Gingerbread for the next iteration of Squiggly and that allows me to do things like use the MultiSelectListPreference and use the local Calendar API exclusively.
But there is a drawback with MultiSelectListPreference. You have to pre-define the string arrays for entries and entryValues. This sucks. This is why I have now added CustomMultiSelectListPreference to CustomPreferences. I have followed the same pattern which I did with CustomListPreference by implementing the IDynamicProvider which I introduced a while back when I needed to populate a regular list preference dynamically.
This is the class to reference in your preference xml file.
To use it:
<com.myappfactory.preferences.CustomMultiSelectListPreference
android:key="@string/calendarsToMonitorKey"
android:dependency="@string/enableCalendarBackgroundServicesKey"
android:title="@string/calendarsToMonitorTitle"
android:dialogTitle="@string/calendarsToMonitorDialogTitle"
android:summary="@string/calendarsToMonitorSummary"
customPreference:dynamicEntriesProvider="your.app.package.ClassThatImplementsIDynamicProvider"
customPreference:dynamicEntryValuesProvider="your.app.package.ClassThatImplementsIDynamicProvider"
customPreference:selectAllValuesByDefault="true"
android:entries="@array/empty_array"
android:entryValues="@array/empty_array"
android:defaultValue="@array/empty_array"/>
selectAllValuesByDefault does exactly what it says. It selects all the values that are dynamically added. The class that provides these dynamic entries and entryValues need to implement IDynamicProvider. The no-argument version of populate method will no longer be supported. So be sure to implement the populate that accepts a Context. CustomMultiSelectListPreference first calls populate then calls getItem. I have tried to keep the same naming convention that Android’s adapter classes use. So you will see getCount and getItems in there.
Here’s a preview of what it will look like:
