Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 14 09:13
    vxhviet commented #2303
  • Jul 14 08:25
    vxhviet commented #2303
  • Jun 07 12:28
    zizibuba commented #2303
  • May 21 07:48
    DenisFedak84 edited #2303
  • May 21 07:47
    DenisFedak84 edited #2303
  • May 21 07:46
    DenisFedak84 edited #2303
  • May 21 07:43
    DenisFedak84 opened #2303
  • Apr 10 17:46
    WonderCsabo commented #2297
  • Apr 10 17:45
    WonderCsabo commented #2299
  • Apr 10 17:44
    WonderCsabo commented #2301
  • Mar 03 13:04
    WonderCsabo commented #2302
  • Mar 03 12:57
    FilipObornik closed #2302
  • Mar 03 12:57
    FilipObornik commented #2302
  • Mar 03 12:04
    WonderCsabo commented #2302
  • Mar 03 10:55
    FilipObornik opened #2302
  • Jan 28 08:46
    sonfer commented #2031
  • Jan 27 12:17
    krischik commented #2248
  • Jan 27 12:16
    krischik commented #2248
  • Jan 25 08:58
    wmailn commented #1937
  • Jan 08 03:47
    whj33 opened #2301
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
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...
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.
Adrián Rivero
@smaugho
Ok ok.. I'll guess I'll do it as required by AA.. if I'm not happy with it, maybe I finish with a version for us here in the company :sweat_smile: .. but want also to add this plugin to AA, sounds like a good use..

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

Right, in fact, I tried initially to have @EViewModel implemented as a Generating class.. but it doesn't work right now!

Maybe I should have tell you this before.. (and maybe this could be fixed)
Kay-Uwe Janssen
@dodgex
I'm sorry for the inconvinience but well AA is not designed for stuff like that (one of the reasons why i'd like to rewrite most of it :D)
maybe it is worth researching what is required to add new generating classes
Adrián Rivero
@smaugho
public abstract class ModelConstants {

    public static final Option OPTION_CLASS_SUFFIX = new Option("classSuffix", "_");

    private static String generationSuffix = "_";
    private static String classSuffix;

    public static final List<Class<? extends Annotation>> VALID_ENHANCED_VIEW_SUPPORT_ANNOTATIONS = asList(EActivity.class, EViewGroup.class, EView.class, EBean.class, EFragment.class);

    public static final List<Class<? extends Annotation>> VALID_ENHANCED_COMPONENT_ANNOTATIONS = asList(EApplication.class, EActivity.class, EViewGroup.class, EView.class, EBean.class, EService.class,
            EIntentService.class, EReceiver.class, EProvider.class, EFragment.class);

    private ModelConstants() {
    }
This is the issue. As you see, on ModelConstants we have those lists with VALID_ENCHANCED_VIEW and so on.. I can definitely create a Generating class, but then you cannot inject any @Bean or almost any other thing on it!
Also, most of annotations stop working then there, you cannot use most of them, since they make check against this list... mm.. maybe I got it wrong in fact, and I should modify that List from within the plugin?
Kay-Uwe Janssen
@dodgex
maybe it is possible to enhance the plugin api to have a way to extend this list
but some annotations check for certain enhanced classes in validation. not sure if this might be a problem
Adrián Rivero
@smaugho
Most of the injecting annotations use the "InjectHelper", that one makes the check
Kay-Uwe Janssen
@dodgex
i think the inject helper does not check the target class
Adrián Rivero
@smaugho

Aah, not exactly like that:

@Override
    public void validateEnclosingElement(Element element, ElementValidation valid) {
        validatorHelper.enclosingElementHasEnhancedComponentAnnotation(element, valid);
    }

The inject helper calls this method, which then validates

This is for the BeanHandler. Here you check basically then against that list in ModelConstants
public void enclosingElementHasEnhancedComponentAnnotation(Element element, ElementValidation valid) {
        enclosingElementHasOneOfAnnotations(element, VALID_ENHANCED_COMPONENT_ANNOTATIONS, valid);
    }
Kay-Uwe Janssen
@dodgex
hm