Repository navigation
Annotations for fragments #3
Description
@pyricau, Apr 13, 2011
It would be nice to see if we can generate subclass for fragments, so support annotations such as @ViewById, @click and others in fragments. The fragments would be annotated @efragment.
We need to see if that's feasible, and how it would work. The generated code will have to work with 3.0 and pre 3.0 (ie support jar). To do so, we'll have to check the annotated fragment package, and see if it's "support" or android 3.0 package.
Fragments are created based on layout.xml files, so those layout will have to be updated to include the generated fragment instead of the original one. Which mean we may also add some checks (compile errors) to see if an original fragment is recorded instead of the generated one.
@fjjonesjr, Dec 22, 2011
Personally I think this priority should be high. This is a great framework, but of little use to modern implementations until fragment support is available. ICS exacerbates this greatly.
@pyricau, Dec 26, 2011
You are right, and it is indeed of high priority. I want this to be part of the next release.
Activity
pyricau commentedon Jan 10, 2012
Of course, the Fragment wiki page will have to be updated.
krisread commentedon Feb 10, 2012
Any news on this?
We want to adopt Android Annotations but our whole app is fragments, it just doesn't make sense until you get fragment support - at the very least ViewById type lookups, maybe FragmentTransaction stuff as well would be nice...
pyricau commentedon Feb 11, 2012
We really want it too, and I'd to add that for the next release. But first we need to describe the behavior and features. I don't have much experience with fragments yet. Maybe you could start by listing the features you'd want, the expected behavior, etc :)
krisread commentedon Feb 11, 2012
ludwigm commentedon Feb 13, 2012
Would also like to see that. That would be the last step for using the framework for my released apps
pyricau commentedon Feb 14, 2012
Do you guys know any open source Android App with "real life" usages of fragments ? Not "getting started" stuff, but real cases where we could understand how to do this properly ?
ludwigm commentedon Feb 14, 2012
Search for the Google IO App. I think this is a good example. It is open
sourced
Am Dienstag, 14. Februar 2012 schrieb Pierre-Yves Ricau <
reply@reply.github.com
pyricau commentedon Feb 15, 2012
I actually read parts of the code of Ioshed some time ago, and couldn't quite understand how "better" the code was after using fragments. Seems like a lot of work, when there are other ways to handle multiple layouts / components based on the display.
I'm not saying fragments are bad, just that I am not able yet to understand their beauty :) .
Anyway, it's here : http://code.google.com/p/iosched
ludwigm commentedon Feb 15, 2012
I found that stackoverflow questions:
http://stackoverflow.com/questions/5695408/so-what-are-the-exact-advantages-of-fragments-in-android-3-0
http://stackoverflow.com/questions/8617696/what-is-the-benefit-of-using-fragments-in-android-rather-than-views
pyricau commentedon Feb 15, 2012
The first link is actually quite convincing. Thank you!
davidjorgensen commentedon May 23, 2012
I was just about to change my entire application to use the annotations, until I found out that it doesn't work on fragments (yet).
Cant wait for it to work on fragments.
In regards to "why" and "when" to use fragments: In my case i have made my own tabbar (as a fragment) and a header fragment, along with a "content" fragment between (talking normal phones, not tablets).
By doing this I have my code seperated into the fragments, and more than this, I can open new fragments within the same "tab" (since i am adding the fragment to the content fragment).
Correct me if I am wrong, but I am not sure you can open an activity from a tabhost activity? Well, you can, but it will be a "full screen" activity instead of being inside the tabhost (so the tabbar is always visible)
mariusgreve commentedon May 24, 2012
I'm also very eager to use annotations for fragments. Any update on this or at least an estimate on when it'll be available? This is an absolute must I would say
pyricau commentedon May 27, 2012
Ok, so I've been reading the docs, reading implementations, and reading RoboGuice source for fragment support.
We're are going to start small with limited fragment support, and we'll add more features when needed.
There will be a new
@EFragmentannotation, to put on a class that extendsFragment. This class may extend support v4 fragments or Honeycomb + native fragment. We should be able to handle both cases and generate the appropriate code with appropriate packages. In case we can't do that easily, we'll start with support v4 fragments.Users will have to use the generated subclass of the fragment (e.g.
MyFragment_) in their xml layouts. When creating fragments programmatically, they'll have to call the generated subclass constructor (e.g.new MyFragment_()).Later on, we should add the equivalent to
@Extrawith fragment arguments, which would automatically add a builder method with those arguments in the generated subclass.We will create two new annotations:
@FragmentByIdand@FragmentByTag. The first may hold an int parameter (the fragment id), the second may hold a String parameter (the fragment tag). When the parameter is not set, the field name is used.These two annotations will lead to the call of
activity.getFragmentManager().findFragmentById()/activity.getFragmentManager().findFragmentByTag()when the components will be created, and inject the corresponding fragments if available.We may add features related to fragment transactions, but not as part of the first steps.
General injection in fragments will be done by overriding
onCreate(), doing the injection and then callingsuper.onCreate().View injection and event listener binding in fragments will be done by overriding
onCreateView(), callingsuper.onCreateView()and callingfindViewById()on the returned View. This means that fragments won't be able to be injected views from other fragments / from their parent activity. Please yell if you think that's inappropriate. We could go the other way (callinggetActivity().findViewById()), but this wouldn't work very well if you have multiple instances of the same fragment in your UI.@EBeanwill keep callingactivity.findViewById(), so this may lead to surprising results when injecting@EBeans in fragments.We could otherwise go with a fragment specific annotations, such as
@FragmentViewByIdand@FragmentOnClick, but I don't really like this.We could add a layout parameter to
@EFragment, and calllayoutInflater.inflate()inonCreateView()in such a case. I guess it depends on how much customization power you need when creating your fragment views.Thoughts?
pyricau commentedon May 27, 2012
@mariusgreve Unless a major obstacle arise, I should be able to implement it this week, probably on thursday.
Added @efragment annotation, works with support and native fragments.…
6 remaining items
davidjorgensen commentedon May 28, 2012
Makes sense. an onCreateView that have to return null doesn't seem natural.
A quick side question if you'll indulge me: All of those Resource annotations ie: @stringres. Wouldn't using a @stringres and assigning it to a TextView actually use more memory than just assigning a R.string.text directly to the TextView (the extra String)? I think the use of @stringres is quite clever. I am just not sure why i'd use it.
krisread commentedon May 28, 2012
A lot of fragments are stateless so it's not as common as you think to need the Bundle savedInstanceState parameter.
pyricau commentedon May 28, 2012
Ok @krisread, you convinced me, see above reference :) .
@davidjorgensen : you are right. Use cases are rare, but IIRC some parts of the Android API have methods that take String but not int. There are also cases where you want to retrieve a string from the resources, but not for any View related purpose.
pyricau commentedon May 28, 2012
And so, @davidjorgensen, the answer is now yes: you can do
@EFragment(R.layout.myView)davidjorgensen commentedon May 28, 2012
you are a machine.. ^^
Kick ass work
davidjorgensen commentedon May 29, 2012
I've now tried converting my fragment activity along with one of my fragments to use androidannotations.
Changing the fragment activity was simple enough, but i get this on the fragment itself.
(btw.. this fragment is loaded by doing a "new FragmentName()") Well, actually i never get this far.
I get this
Unexpected error. Please report an issue on AndroidAnnotations, with the following content: java.lang.NullPointerException
at com.googlecode.androidannotations.helper.ValidatorHelper.extendsOneOfTypes(ValidatorHelper.java:661)
at com.googlecode.androidannotations.helper.ValidatorHelper.extendsFragment(ValidatorHelper.java:541)
at com.googlecode.androidannotations.validation.EFragmentValidator.validate(EFragmentValidator.java:59)
at com.googlecode.androidannotations.validation.ModelValidator.validate(ModelValidator.java:53)
at com.googlecode.androidannotations.AndroidAnnotationProcessor.validateAnnotations(AndroidAnnotationProcessor.java:396)
at com.googlecode.androidannotations.AndroidAnnotationProcessor.processThrowing(AndroidAnnotationProcessor.java:348)
at com.googlecode.androidannotations.AndroidAnnotationProcessor.process(AndroidAnnotationProcessor.java:323)
at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:139)
at org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.round(RoundDispatcher.java:121)
at org.eclipse.jdt.internal.compiler.apt.dispatch.BaseAnnotationProcessorManager.processAnnotations(BaseAnnotationProcessorManager.java:159)
at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:134)
at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:809)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:428)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:321)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:301)
at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:134)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:193)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
EDIT:
btw.. i am using the android.support.v4.app.Fragment library on Android 2.2
EDIT 2:
Thought it happened because i had private Views getting annotated with @ViewById, but now i have an empty fragment with just the @efragment annotation and it still happens. It happens with both @efragment and @efragment(R.layout.mylayout)
pyricau commentedon May 29, 2012
Ok, I think I know what's going on. It's trying to load the "android.app.Fragment" class in the processor, to check if your annotated class extends from it. In your case, this class isn't available (Android 2.2), so the helper method returns null => NPE. #FAIL .
I'll fix that ASAP.
davidjorgensen commentedon May 29, 2012
Great. Glad to help.
Bugfix for NPE when processing @efragment if android.app.Fragment not…
pyricau commentedon May 29, 2012
Thank you for the feedback, it really helps :) .
You may download the 2.6-SNAPSHOT again as soon as this build is complete.
davidjorgensen commentedon May 29, 2012
So far it seems to be working. It is working excellent. :)
I'll let you know if something changes.. :)
Thanks for the super fast update. Much appreciated.