search

ponewheel / android-ponewheel

pOneWheel Android app
MIT License
71 stars 25 forks source link

Databinding characteristics are hard to read/maintain #21

Open ebabel opened 6 years ago

ebabel commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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