Skip to content
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
This repository was archived by the owner on Feb 26, 2023. It is now read-only.

Introducing Scopes #352

@pyricau

Description

@pyricau

This issue relates to #331, #205, #207 and probably a few others

AndroidAnnotations' current injection model works fine, but it has some drawbacks:

  • You can't inject the same bean instance multiple times unless you make it a singleton (which is not always desirable)
  • You can't inject fragment views in a fragment dependency (@EBean)
  • You are not guaranteed that @RootContext and view injection / binding will work fine in beans, if a parent bean in the object graph is a singleton. Worst then that, it doesn't fail early, it just skips the injection.

I think this comes from the fact that AndroidAnnotations doesn't have any hierarchy of scopes. The basic idea with scopes is that a child scope may access beans from a parent scope, but not the contrary.

I hacked around this idea and came up with a proof of concept: https://github.com/pyricau/androidannotations-scoping . This is a simple eclipse project that doesn't have any dependency on Android / AA, is just simulates the expected behavior.

From a user point of view, here is what the changes would look like :

  • We would remove the @RootContext, @App and @Bean annotations, and replace them all with an @Inject annotation.
  • @EBean would take an optional value parameter that would correspond to the scope of this bean. When set, this beans is visible within the whole corresponding scope. For instance, if an A has a dependency on B and C, B and C have a dependency on D, and D is in A scope (@EBean(A.class)), then the same D would be injected in both.
  • The most used scope will probably be Activity, but in fact it can be any class, to fit the user needs.

This change will also need to take the specific combination of @NonConfigurationInstance and @Bean into account, and maybe find a new way to reproduce this feature (basically being able to keep bean instances on activity configuration changes).

Also note that this change will break backward compatibility quite much. So I think that would be a good opportunity to do other hard changes, such as renaming the packages from com.googlecode.androidannotations (we're on GitHub now!) to org.androidannotations, change the maven packages, and introduce AndroidAnnotations 3.0.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions