Repository navigation
Layout with ListFragment #741
Description
Activity
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.
Hello @MysteriooN!
What check do you mean and what the generated code should look like?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_;
What about subclassing in this solution? ListFragment is an example of this case, but there could be large hierarchy of abstract classes. So empty
onCreateViewcan not be the point. So, if developer uses additional attributeforceLayoutInjection, 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.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.
Let's go for the
forceLayoutInjectionattribute in@EFragmentthen.
However, this will be implemented in AA 3.1There is no check on
super.onCreate(...)result for@EActivity, so this problem doesn't exists on this annotation.Thanks @MysteriooN for your workaround, it works!
We even can detect the supertype at compile time and generate the necessary injection code.
But i am not sure, maybe theforceLayoutInjectioninjection attribute would be cleaner, since we can never know what supertype the client will use, which can eventually return other thannulland our layout injection breaks.7 remaining items
@nbelikov I agree with you, really. But the problem with the solution you're suggesting is what @WonderCsabo said before, if you extend anything other than ListFragment that overrides onCreateView and returns a non-null value, our injection will break.
Edit: That's why I want the parameter, because it'll work in all cases.
contentView_ = super.onCreateView(inflater, container, savedInstanceState); forceLayoutInjection_ = true; if ((contentView_ == null)||(forceLayoutInjection_ == true)) { contentView_ = inflater.inflate(layout.fragment_main, container, false); }
If
forceLayoutInjectionis true, the injection takes place regardless to the nullness of the returnedViewfrom the superclass. So to make this working in your case, you have to add this parameter to the@EFragmentannotation on yourListFragmentsubclass.@WonderCsabo Yep that's what @DayS and I agreed on a year ago, but unfortunately it wasn't implemented in the 3.1 release as planned.
BTW, @Lochnair, this would be more efficient (and maybe more correct):
forceLayoutInjection_ = ...; if (!forceLayoutInjection) { contentView_ = super.onCreateView(inflater, container, savedInstanceState); } if ((contentView_ == null) || (forceLayoutInjection_ == true)) { contentView_ = inflater.inflate(layout.fragment_main, container, false); }
@WonderCsabo True, I'll edit it to do that.
Also i think we should handle this at generation time, and only generate the necessary calls, so in case of forcing we should just generate the inflation and return, etc.
Agreed, I'll see if I can get it to work.
Alright, now it generates either this
contentView_ = inflater.inflate(layout.fragment_main, container, false); return contentView_;
or this
contentView_ = super.onCreateView(inflater, container, savedInstanceState); if (contentView_ == null) { contentView_ = inflater.inflate(layout.fragment_main, container, false); } return contentView_;
See commit fd66f6a for the changes.
Why don't you create a PR?
Implemented.
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.
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.
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.