Layout with ListFragment

[Lochnair]

This is the code AA generates for my fragment. Now if you extend Fragment that's fine, but when you extend ListFragment it's not, because the ListFragment implementation of onCreateView doesn't return null, like the Fragment implementation does.

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    contentView_ = super.onCreateView(inflater, container, savedInstanceState);
    if (contentView_ == null) {
        contentView_ = inflater.inflate(layout.simple_list, container, false);
    }
    return contentView_;
}

Currently I'm using this to make it work, though one could say it destroys the whole point of doing the layout the AA way.

@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
    return null;
}

If this was a design decision, why not add an optional boolean field to the annotation where you can tell AA to ignore super implementations.

[DayS]

This is related to #542

We could imagine a field like forceLayoutInjection on the annotation, but I'm not sure it's the best solution. Any ideas ?

[Lochnair]

Referring to @naixx comment on #542 (comment).
If I understand him right, it's the annotated class we care about, not whatever class it extends.

So couldn't we add a check when generating the AA code, where we see if the annotated class has a onCreateView method or not. That way we could add the null check if it does, or let AA handle it if it doesn't.

[naixx]

Hello @MysteriooN!
What check do you mean and what the generated code should look like?

[Lochnair]

I'm talking about the null check in the onCreateView method in a generated fragment class:

contentView_ = super.onCreateView(inflater, container, savedInstanceState);
if (contentView_ == null) {
    contentView_ = inflater.inflate(layout.simple_list, container, false);
}
return contentView_;

So what I'm saying is if that the annotated class doesn't have a onCreateView method, the generated code should look like this:

contentView_ = inflater.inflate(layout.simple_list, container, false);
return contentView_;

[naixx]

What about subclassing in this solution? ListFragment is an example of this case, but there could be large hierarchy of abstract classes. So empty onCreateView can not be the point. So, if developer uses additional attribute forceLayoutInjection, he will see explicit and no hidden behavior.
As for me, I don't know if it is good to provide such API or not instead of current workaround.

[Lochnair]

I said that assuming you meant only the annotated class, and not it's hierarchy in your comment. If you take the whole hierarchy into perspective, this won't work of course.

Right now it seems to me like an additional attribute is the best solution, I'm guessing it's pretty easy to implement, and it leaves the behavior to the developer.

[DayS]

Let's go for the forceLayoutInjection attribute in @EFragment then.
However, this will be implemented in AA 3.1

[naixx]

@DayS Only in @EFragment? I haven't checked, but what behavior will be in, for example, ListActivity?

[DayS]

There is no check on super.onCreate(...) result for @EActivity, so this problem doesn't exists on this annotation.

[voidrob]

Thanks @MysteriooN for your workaround, it works!

Is it possible to getDeclaringClass() for onCreateView(), and force injection if the class equals to android.support.v4.app.ListFragment or android.app.ListFragment?

[WonderCsabo]

We even can detect the supertype at compile time and generate the necessary injection code.
But i am not sure, maybe the forceLayoutInjection injection attribute would be cleaner, since we can never know what supertype the client will use, which can eventually return other than null and our layout injection breaks.