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

Why do we need a class to be enhanced component to use Background and UiThread #2257

Open
chpasha opened this issue Jan 23, 2020 · 2 comments

Comments

@chpasha
Copy link

chpasha commented Jan 23, 2020

I'm trying to merry AA with android view models and the only problem I cannot solve cleanly is a view models with @background methods and saved state (which requires to have constructor with SavedStateHandle parameter). The EBean annotation will obviously complain about missing constructor with context as only parameter, but actually I don't need either EBean or dependency from context, I just want to use Background/UI which is not possible for now because of the validation that requires any class to be enhanced component. I don't know the internal implementation very good, is there any reasons why @background, @UiThread and maybe some more stuff cannot be used without enhanced components?

@dodgex
Copy link
Member

dodgex commented Jan 25, 2020

There are like two kinds of annotations:

  • Those who tell AA that it should enhance a class (EActivity, EBean, EView, etc)
  • Those who tell AA HOW it should enhance stuff (Background, UiThread, injections, etc)

every non-enhancing annotation needs to be in an enhanced class as only enhanced classes get a class that the code for the other features can be generated to.

BUT: There is a way for you to indirectly use the background/uithread features in non enhanced classes. Just make an enhanced class that uses the annotation how you would like to have it in your other class, build the project and open the generated class (eg if you enhance MyFancyBean you need to open MyFanceBean_ (note the _)) there you find the code we generate and can copy it to your non enhanced class.

The code uses BackgroundExecutor and UiThreadExecutor to do the actual work so you can directly use this classes instead of the annotations.

@chpasha
Copy link
Author

chpasha commented Jan 25, 2020

thank you for the answer. I've looked into the code and figured out the same myself. Unfortunately the solution with coping the code from generated classes won't suite - of course I know what code is generated and how to use it directly but the whole point is getting rid of boilerplate, not creating it. I've ended up creating an own enhanced component which is not bound to context and doesn't have to have a parameter-less constructor or constructor with context parameter. Of course it's usefulness is limited, but Background, UI, AfterInject and anything else that doesn't require context can be used now allowing custom constructors at the same time. So now one can create a bean like this

@EBeanLite
class MyViewModel extends ViewModel {
    MyViewModel(SavedStateHandle handle) {}

  @Background
   doSomeStuff() {}
}

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants