Thanks for contributing that !

• I'm still wondering if inflate is really the way to do it. Inflating only works for XML, and that's why we have to resort to such hacks.. But I don't know if there's anything else we could do.
• the getInflatedInstance() method name sounds strange, when you're not using XML you're not actually inflating anything :) Inflating is about blowing into a flat XML to create a view with volume :)
• A test would be nice ;)

• I'm not sure I understand what you mean. Inflating XML doesn't look like a hack to me, as it's exactly what the doc says, along with the other way, which is to create the view programmatically. But AA can't do much work if it's used this way.

The usual starting point is a Layout of some kind, so create a class that extends a Layout. Perhaps in the case of a Combo box we might use a LinearLayout with horizontal orientation. Remember that other layouts can be nested inside, so the compound component can be arbitrarily complex and structured. Note that just like with an Activity, you can use either the declarative (XML-based) approach to creating the contained components, or you can nest them programmatically from your code. Source

• I wasn't considering the case of "not using XML", but true, I guess it could be used this way. I'll work on it next week. BTW, what would you use for the factory method name ? Actually getInstance reminds the singleton pattern which is not used here. What about create() or make() ?
• Yeah I know, I was a little bit in a hurry because I wanted to do this before the DevCamp. :P

What I'm saying is that we are doing stuff in onFinishInflate() that is not specific to XML inflate.

You're right about getInstance() feeling like singleton retrieving...

I wasn't considering the case of "not using XML"

Well, in issue #101, you wrote :

@EActivity(R.layout.main)
public class CustomFrameLayoutActivity extends Activity {
...
    CustomFrameLayout layout = CustomFrameLayout_.getInflatedInstance(this, 2);
... 
}

Isn't that not using XML ?

No it's not "not using XML" (weird sentence). CustomFrameLayout_ is still inflated through an XML file. I though what you were referring as "not using XML" was an @EViewGroup without a layout id, and creating programmatically its childrens.

CustomFrameLayout_ is still inflated through an XML file

Not it's not ;) !

It's one thing to inflate its children, it's another thing to be inflated. CustomFrameLayout_ would be inflated if you added it inside a layout file :)

I was confused indeed ! Now I see why getInflatedInstance() is weird.
What do you think of create(), build() or make() ?

Humm... whatever will suit you best :) I'd probably go for create(), build() or newInstance() :)

Working on it now. What about @eview ? It should work exactly the same way, did you forget about that annotation :) ?

You mean a static constructor for classes annotated with @EView ?
I guess it would be good for consistency, but that's all, because I don't recall any need to call onFinishInflate() on a view (new MyView_(); is enough), am I wrong ?

Yeah :)

Basically, the structure is identical. @EView can be used on a ViewGroup. And anyway, any @AfterView method must work in @EView, and we call that from onFinishInflate(). @EViewGroup is just a specialization of @EView, that adds the ability to automatically add children to a ViewGroup from an XML.