<include ..> tag
Sometimes I reuse layouts inside of other layouts. I use "include" tag. Holdr does not include ids from included xmls. I'd like it to include them.
The code I have: dialog_record.xml
<include layout="@layout/dialog_item_edit_actions" />
<include layout="@layout/dialog_item_delete_actions" />
<include layout="@layout/dialog_item_date_picker_actions" />
h = new Holdr_DialogRecord(view);
h.setListener(this);
new Holdr_DialogItemEditActions(view).setListener(this);
new Holdr_DialogItemDeleteActions(view).setListener(this);
new Holdr_DialogItemDatePickerActions(view).setListener(this);
This looks like a boilerplate to me ;)
Is it possible to somehow mark my includes for Holdr to include them into parent xml?
You can just give your include an id and holdr will generate a field for it that points to the included holdr. It's currently not the most robust since it constructs all included instances from the root view which won't make it work correctly if you have any includes that contain the same id, but it should be fine for your example.
<include android:id="@+id/include_edit_actions" layout="@layout/dialog_item_edit_actions" />
<include android:id="@+id/include_delete_actions" layout="@layout/dialog_item_delete_actions" />
<include android:id="@+id/include_date_picker_actions" layout="@layout/dialog_item_date_picker_actions" />
h = new Holdr_DialogRecord(view);
h.setListener(this);
h.includeEditActions.setListener(this);
h.includeDeleteActions.setListener(this);
h.includeDatePickerActions.setListener(this);
But I still need to write 5 lines of code where with Butterknife I need only one. So, a little attr would be great. ;)
I hadn't considered making listeners transitive, but I do see the use case for it. I wonder if there any cases where you would not want them to be.
I actually had a better idea. How about an holdr_flatten="true/false" attribute that would put all the id's and listeners in what you included in the parent Holdr class? You would have to ensure that id's aren't duplicated across includes, but that should be ok since otherwise the listener callbacks would conflict as well.
Yes, this looks good.