Repository navigation
Annotations for fragments #3
Description
Activity
Of course, the Fragment wiki page will have to be updated.
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...
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 :)
- Pretty much everything that currently works in an activity should work in a fragment, too.
- Be able to lookup fragments similar to views
- Could be able to annotate a method as being run in a fragment transaction (possibly)
- Could be able to easily inject (add) fragments into an activity
- Could be able to easily inject the (typecast) activity into the fragment as a callback
Would also like to see that. That would be the last step for using the framework for my released apps
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 ?
Search for the Google IO App. I think this is a good example. It is open
sourcedAm Dienstag, 14. Februar 2012 schrieb Pierre-Yves Ricau <
reply@reply.github.com:
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 ?
Reply to this email directly or view it on GitHub:
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
The first link is actually quite convincing. Thank you!
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)
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
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?
@mariusgreve Unless a major obstacle arise, I should be able to implement it this week, probably on thursday.
- added a commit that references this issue
on May 27, 2012 6 remaining items
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.
A lot of fragments are stateless so it's not as common as you think to need the Bundle savedInstanceState parameter.
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.
And so, @davidjorgensen, the answer is now yes: you can do
@EFragment(R.layout.myView)you are a machine.. ^^
Kick ass work
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.2EDIT 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)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.
Great. Glad to help.
- added a commit that references this issue
on 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.
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.
@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.