depoll

This seems to answer the question: https://www.facebook.com/help/458736564237313

FWIW, the official policy document I linked above makes no mention of opt-in whatsoever.

I don't think that this page is actually the policy. The intro text points here: http://play.google.com/about/developer-content-policy.html

And the relevant text in the intro points out that these are guidelines to help you follow the policies: "The sections below highlight best practices and common examples to help you avoid the most common types of policy violations."

Huge congrats to the Xamarin folks. I'm a huge fan of their products. Personally, I've found their tools for Android development to be less cumbersome than Google's tools for the same. I was extremely impressed by their Evolve conference as well. Great engineering and great, friendly, responsive people. Kudos!

Mr. Lacker being a double Putnam Fellow (along with various other intellectual accolades on the team) is a big part of why I love working at Parse. Also, he's really good at raising one eyebrow.

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

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.

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.

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.

For what it's worth, this is exactly how Parse's .NET SDK works. Promises in JavaScript go a long way toward improving the experience of async development, but I thoroughly agree that language-level support for this type of construct is immensely helpful.

Ermagerd! Zurb aquers Ferrst!

Ah -- didn't see that. Wasn't so much a criticism (it doesn't take away from the article at all) as it was an observation that something really trivial stuck in my head ;)

"The half-life of a public corporation today is about 30 years: ten half-lives out — 300 years hence — we may expect only one in a million to survive."

Am I the only one who read this and went "Wait, 10 half-lives... that's 1/(2^10)... that would mean about 1 in 1,000 survive -- not 1 in 1,000,000."?

Our previous announcement was for Windows 8 support. This adds support for Windows Phone 8 (whose SDK came out after we launched the Windows 8 version) as well ;)

There are also Android apps listed in the gallery (see, for example, FishPop on the first page).

;) Fair enough. At least we agree that it's a wolf!