Show HN: Bindroid - a data binding framework for Android | Hacker News Reader

Show HN: Bindroid - a data binding framework for Android

davidpoll.com

30 pointsdepoll9 comments

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?

1. I don't think ListAdapters can be bound because ListViews recycle views. I don't think you can bind 1 view to many objects.

OP here.

1. Instead of using a ListAdapter, I've provided a "BoundCollectionAdapter": http://depoll.github.com/bindroid/docs/com/bindroid/ui/Bound... 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.

BoundCollectionAdapter! Nice!

I will check it out.

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...). 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.

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?

Take a look at the screenshots for Tag Master (https://play.google.com/store/apps/details?id=depollsoft.tag...), 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.

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.

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).

Reply on news.ycombinator.com