Databinding characteristics are hard to read/maintain

[ebabel]

It's hard to figure out whats going on in main_activity.xml:
android:layout_row="53"
android:text='@{owdevice.deviceReadCharacteristics.get(4).ui_name}'

The hardest thing is the specified row. I'm pretty sure there aren't 53 rows and I don't know if they are all showing up. I think it would be nicer to not specify the row and put them in order in the xml.

Less hard to figure out, but not ideal is the 4, I think this means I need to find the 5th item added to deviceReadCharacteristics? I tried to change deviceReadCharacteristics to a hashmap, and I might be tempted to go back to that, but I haven't done databinding yet so I'm not quite sure what I'm doing.

[kwatkins]

Yeah - this one is confusing and never turned out like I wanted. The intent was to be able to easily remove/add deviceReadCharacteristics and that be the driver for the ui (ui_name, flags like ui_enabled etc) via data binding. If I recall I think it hit some limits with data binding? or didn't understand some part of it. I think it had to something with limitations of iterations in data binding, or some shit like that.

I'm all for whatever you think should be done to make it clear. The layout_row was some grouping thing I was trying (notifying BLE chars vs read-once values), agree just putting them in order would clear that confusion up.

[ebabel]

Hmm, maybe abandon databinding? Its definitely nice to have, but also has its limits. I bet we could maybe come up with a dynamic solution that iterates over the characteristics and creates views programmatically. Not sure if its worth the effort but could be cleaner and more powerful.

[kwatkins]

Would take a bit of work for little return right now, agree we should avoid it when we can and slowly phase it out.