I chose the "do it yourself" approach and parse the layout.xml by
myself. The simple part (reading the element names and building the
widget tree) works quite well. Then I wrote an own implementation of
android.util.AttributeSet which wraps a org.w3c.dom.NamedNodeMap. When
I try to instantiate a View class with my own AttributeSet
implementation I get hit by a ClassCastException. After a short
investigation I found the following code.
When can I expect this to be fixed?
android.content.res.Resources.Theme
public TypedArray obtainStyledAttributes(AttributeSet set,
int[] attrs, int defStyleAttr, int defStyleRes) {
int len = attrs.length;
TypedArray array = getCachedStyledAttributes(len);
// XXX note that for now we only work with compiled XML
files.
// To support generic XML files we will need to manually
parse
// out the attributes from the XML file (applying type
information
// contained in the resources and such).
XmlBlock.Parser parser = (XmlBlock.Parser)set;
<--- NOT GOOD FOR MY OWN AttributeSet implementation
AssetManager.applyStyle(
mTheme, defStyleAttr, defStyleRes,
parser != null ? parser.mParseState : 0, attrs,
array.mData, array.mIndices);
array.mRsrcs = attrs;
On Mar 24, 2:59 pm, Daniel <[email protected]> wrote:
> Thanks for your response. My use case is as follows:
> We have a server application which allows to be extended by plugins.
> Each plugin contributes a "view" and some logic. Until now, the only
> client we support is a web client. Every plugin contributes a jsf
> based xhtml page plus some java beans.
> What we want to do now is to support a native android client. A part
> of its user interface should be fixed, another part should be provided
> by the mentioned plugins. By adding a new plugin on the server, the
> user should be able use the new functionality immediately. To make
> that working, a plugin needs to provide a kind of an android user
> interface description. And of course, the android client needs to be
> able to render this user interface description, register generic
> listeners on the given ui and handle events appropriately (by sending
> a response to a web service for instance).
>
> The point is now: Android already has this user interface description
> (layout.xml) and the code which inflates such a description (in
> preprocessed form) to a user interface. It would be awesome to reuse
> this code!
>
> Thanks.Daniel
>
> On Mar 23, 6:25 pm, droozen <[email protected]> wrote:
>
> > We might have to know why you want to build this way. There could be
> > other possibilities, including using a much simpler xml that you could
> > parse yourself and add UI elements programmatically. Or have a variety
> > of layouts available that you could set, depending on a value you've
> > downloaded, though I get the feeling you want something more dynamic
> > than that.
>
> > On Mar 23, 2:10 am,Daniel<[email protected]> wrote:
>
> > > Hi all,
>
> > > Q: What is the recommended way to build user interfaces on the device
> > > based on layouts provided by a server at runtime?
>
> > > I am aware of this:
> > > <snip source="http://developer.android.com/reference/android/view/
> > > LayoutInflater.html">
> > > For performance reasons, view inflation relies heavily on pre-
> > > processing of XML files that is done at build time. Therefore, it is
> > > not currently possible to use LayoutInflater with an XmlPullParser
> > > over a plain XML file at runtime; it only works with an XmlPullParser
> > > returned from a compiled resource (R.something file.)
> > > </snip>
>
> > > I could imagine these possibilities:
> > > - Parse XML by myself and build the ui tree. (Seems inappropriate to
> > > me since there is already maintained code which is able to do this.)
>
> > > - Transform XML on server to a simpler format which is cheaper to
> > > parse on the device. (Inappropriate as above.)
>
> > > - Preprocess the XML layout on the server the same way the build does.
> > > Transmit it to the client, and then try to load it. But how?
> > > android.content.res.XMLBlock is hidden (@hide) and I don't know how
> > > to
> > > classify the stuff in package com.android.layoutlib.bridge.
>
> > > Any help would be appreciated.
> > >Daniel
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
