namespace complexity about android-viewflow HOT 5 CLOSED

I suppose you are talking about attributes like our sidebuffer and the need of defining the namespace like xmlns:app="http://schemas.android.com/apk/res/your.application.package.here" in your layout XML. AFAIK, this is the standard (and only) way of consuming custom XML attributes in Android. Please comment this issue if you believe it could be done elsewise and I'll have it re-opened.

from android-viewflow.

Yeah, that's what I was referring to.

The technique I was thinking of (attrs.getAttributeValue(NS, "your_attr")) does allow for custom namespaces, but seems to bypass the whole theming system (which is bad). I still think it's more complex than it should be for reusable widgets, but it also seems to be standard.

from android-viewflow.

I actually don't think that the xmlns:app thingy is all that bad. And after all, we could add the feature of setting the sidebuffer programmatically as well, just to give an alternative way of defining a side buffer. Would that be satisfying you think?

from android-viewflow.

My main issue with the app-specific namespace is that that it adds a dependency on your app and makes the widget less reusable. Ideally, it should be as easy to use a custom widget as it is to use a MapView (hopefully without all the bugs or special activities). One should be able to put a bit of sample code out that you can copy into your activity without having to adjust a namespace string.

I think this could be accomplished using an Android library for the widget, but I need to investigate further to really understand what's going on. The whole Android style/theming system is a bit of a kludge and it's hard to see how it's intended to be used properly when you aren't the main Android source.

from android-viewflow.

You could very well publish a re-usable code snippet by simply leave out the sidebuffer attribute, thus getting rid of the app specific namespace. It would get a default sidebuffer value assigned to it though, but still, it would be perfectly re-usable without any change needed.

from android-viewflow.