

Show HN: Bindroid - a data binding framework for Android - depoll
http://www.davidpoll.com/2013/03/17/bindroid-a-binding-framework-for-android/

======
readme
Looks like a great idea. I have a few questions about it:

1\. How does this work if you're using it in a ListAdapter? Should it even be
used there?

2\. It seems like it would play nice with jackson, as jackson will only call
your setters and getters if they're there, anyway. Are you using it alongside
any serialization libraries or ORMs?

~~~
depoll
OP here.

1\. Instead of using a ListAdapter, I've provided a "BoundCollectionAdapter":
[http://depoll.github.com/bindroid/docs/com/bindroid/ui/Bound...](http://depoll.github.com/bindroid/docs/com/bindroid/ui/BoundCollectionAdapter.html)
If you use a TrackableCollection (or any other list), this adapter will track
the changes to that collection.

2\. I don't know a huge amount about Jackson -- I've used my own libraries for
JSON serialization within my apps since they need to interoperate across
Windows Phone, Android, and iOS. Taking a quick look at the tutorials there,
it looks like it should play very nicely with Bindroid.

~~~
readme
BoundCollectionAdapter! Nice!

I will check it out.

~~~
depoll
When you're using this with a binding, you can easily produce one of these
using AdapterConverter
([http://depoll.github.com/bindroid/docs/com/bindroid/converte...](http://depoll.github.com/bindroid/docs/com/bindroid/converters/AdapterConverter.html)).
This takes a list and produces a BoundCollectionAdapter, all set up and ready
to go. The BindroidSample project has a simple example of how you'd use this.

------
Noughmad
This looks like an example of forcing a concept from one framework to another.
Android doesn't have bindings, but instead uses adapters and
notifyDataSetChanged().

This binding may be more useful for non-list data. However, do you really have
a large number of views that are not is a list?

~~~
depoll
Take a look at the screenshots for Tag Master
([https://play.google.com/store/apps/details?id=depollsoft.tag...](https://play.google.com/store/apps/details?id=depollsoft.tagmaster)),
one of the apps I built this for.

Data-centric apps (when I worked in the developer division at Microsoft, we
frequently called these "Forms over Data applications") make heavy use of this
feature. Whether it's for input (e.g. binding a field on your model to the
text in a textbox) or just dynamic, read-only display (e.g. binding a bunch of
labels to data you've pulled from some other source), this is one of the most
common things you do when building a user interface.

As an example, in Android, to keep a textbox up-to-date with some model, you
have to:

1\. Initialize the value of the textbox at creation

2\. Monitor changes to the textbox and proffer those changes back to the model

3\. Monitor changes to the model and proffer those changes back to the textbox
(e.g. a phone number might be transformed from one format to another
automatically)

4\. Make sure you don't end up recursing into yourself, wherein a change to
the model notifies the textbox to update, which notifies the model to change,
etc.

Each of these steps is prone to errors if you've missed a place where the
value might change or where the textbox has its value reset. Things only
become more complex from there. If you have to deal with any sort of
calculated or nested property, making sure you're watching all of the right
values for changes and propagating them correctly can be a nightmare. Bindroid
tries to solve that for you altogether.

FWIW, "Trackables" in Bindroid are quite different from the property change
notifications you'd find in Silverlight/WPF. The XAML technologies use a
pretty low-level INotifyPropertyChanged interface which still forces you to
manage changes in calculated properties manually. However, Bindings in XAML
take care of "dotting down" into your model (e.g. Foo.Bar.Baz[0]) and
correctly register for notifications along the way, which turns out to be a
hugely useful thing for building data-centric UI.

------
TeeWEE
Looks nice, but as far as i can see this is using Reflection, which might be a
performance penalty you don't want to take in your app.

B.t.w. I never really worked on data (input) intensive apps on Android.

~~~
depoll
It only actually uses reflection if you choose to -- you can avoid it entirely
if you don't want to use the property-path-based bindings. Additionally, it
caches the reflected information, so that it's not constantly doing lookups
for the methods that make up properties -- just the first time a particular
property is seen on a type. This cuts out a huge amount of the time spent on
reflection, and it generally is a tiny portion of time compared to the amount
of time it takes to build and render the UI. I've found it hasn't caused
performance problems in my app at all (usually the layout is the most
expensive part of the UI).

