AndroidAnnotations/androidannotations

Kay-Uwe Janssen

@dodgex

i'd not use such technologies

i'd check the transform apis google provides for android builds

http://tools.android.com/tech-docs/new-build-system/transform-api

Adrián Rivero

@smaugho

mmm.. have to check that

Kay-Uwe Janssen

@dodgex

but i think it also is pretty complex

i recently tried to read up on kotlin compiler plugins. but that shit is pretty complex with working partly on byte code level for added/generated code

Adrián Rivero

@smaugho

Kay-Uwe Janssen

@dodgex

and its damn hard to find (recent) docs or samples

Adrián Rivero

@smaugho

BTW, I mentioned something above that I could try to do on my company.. I have several devs under my management.. I've seriously been thinking in start instructing one to let him contributing to AA, plugins or whatever is need it.. we need it in our company anyway.

I already started once, but he was too stressed with this "type of programming" :sweat_smile: ... Well, I think I'll give it another shot in near future..

Kay-Uwe Janssen

@dodgex

yeah

that annotation processing and code generation stuff is not that easy :D

i think just compiler stuff (like GWT) is more complex :D

okay, there might be much more in between. ;)

Adrián Rivero

@smaugho

Yeap.. well, I've get till "Java Tree" level, not deeper

but you can do pretty cool thing with the Java Trees API

Kay-Uwe Janssen

@dodgex

Tree api?

you mean stuff like TreeSet?

Adrián Rivero

@smaugho

No no, Trees API, you applies a Scanner over an Element, and you can get all the code under a method for instance

And do stuff there

https://docs.oracle.com/javase/7/docs/jdk/api/javac/tree/com/sun/source/tree/Tree.html

Kay-Uwe Janssen

@dodgex

ah okay

Adrián Rivero

@smaugho

Compiler Tree API I think. In fact, it can solve issues in AA :), like being able to inject the classes like it is in the code, since you can get all the Imports

that is tricky in the current implementation

Kay-Uwe Janssen

@dodgex

yeha

Adrián Rivero

@smaugho

but it would make AA dependent on that API, which I'm not sure is that good

Kay-Uwe Janssen

@dodgex

i assume it is not good :D

it is com.sun so it should be avoided if possible :D

Adrián Rivero

@smaugho

 protected void onCreate(@Nullable Bundle savedInstanceState) {
        mFragments.attachHost(null /*parent*/);

        super.onCreate(savedInstanceState);

        NonConfigurationInstances nc =
                (NonConfigurationInstances) getLastNonConfigurationInstance();
        if (nc != null) {
            mViewModelStore = nc.viewModelStore;   //HERE IS THE ISSUE
        }

I found in Android code why the ViewModelProvider should be called after the super.onCreate the mViewModelStore is the issue

it is com.sun so it should be avoided if possible :D

Yeap

Kay-Uwe Janssen

@dodgex

this is androidx/support-lib Activity?

Adrián Rivero

@smaugho

no, it is the normal support one, not AndroidX

Kay-Uwe Janssen

@dodgex

well recent support lib should be the same as androidx

just diffrent package

afaik <-

Adrián Rivero

@smaugho

Well, I think there is a solution to that :).. I should basically override an instance called ViewModelStoreOwner

probably on @EActivity and @EFragment...

Kay-Uwe Janssen

@dodgex

https://github.com/androidannotations/androidannotations/blob/develop/AndroidAnnotations/androidannotations-core/androidannotations/src/main/java/org/androidannotations/holder/EActivityHolder.java#L131

this one should return the onCreate after super.onCreate()

so you could do your view model injection at that point

Adrián Rivero

@smaugho

What I'm trying to do, is to "abstract' the ViewModel logic.. so that everything continues working the same. If I manage to do it, basically nothing changes in AA, you simply includes the Plugin, and you ensure that all the ViewModels injected with @Bean works as expected. I'm not really fan of creating more and more annotations

Kay-Uwe Janssen

@dodgex

but this is how AA plugin system is designed to work ;)

to add new annotations or support thirdparty annotations (like the otto plugin)

Adrián Rivero

@smaugho

If not, I'll have to do this:

Create @EViewModel to place over the Beans implementing ViewModel
Create @ViewModel to inject those beans
Create the method you suggested: @AfterViewModel

:sweat_drops:

but this is how AA plugin system is designed to work ;)

Just a question, as dev :), would you prefer to have to learn and use those 3 new Annotations?, or simply insert the plugin on your Graddle, and everything keeps working (with the new enhancements).

So that your @EBean which implement ViewModel when they are injected normally with Bean they simply, "work", no extra change?

Just to know :), I think I will do the @AfterViewModel.. I have done the @EViewModel and @ViewModel BTW, but I'm not pleased with it, hehehe. cause right now @EViewModel is placed over @EBean, and basically, you could try to inject it with @Bean, and then nothing works.

Kay-Uwe Janssen

@dodgex

I'm not sure if i would allow to have @EViewModel together with @EBean

but I'm not sure what is required to have stuff injected in your enhanced class then

Adrián Rivero

@smaugho

@EBean
@EViewModel
public class MainViewModel extends ViewModel implements LifecycleObserver {

    private static final long PERIODIC_UPDATES_TIME = 5 * 60 * 1000L;

    @RootView
    MainViewPresenter presenter;

    @Bean
    ArchivesManager archivesManager;

   .....

This is how it is done right now.. then you should inject with

@ViewModel
MainViewModel viewModel;

Kay-Uwe Janssen

@dodgex

and i'm ok with "learning" new annotations.

Where communities thrive

People

Repo info

Activity