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

Generic Parceler @FragmentArg does not compile #1950

Open
WonderCsabo opened this issue Feb 2, 2017 · 4 comments
Open

Generic Parceler @FragmentArg does not compile #1950

WonderCsabo opened this issue Feb 2, 2017 · 4 comments
Assignees
Labels

Comments

@WonderCsabo
Copy link
Member

This is a template, please adjust it accordingly to your specific issue.

You may also want to read our issue guide.

AndroidAnnotations version: 4.2.0

Android compile SDK version: 24

Annotated code:

public class MyFragment<T extends MyParcel> extends Fragment {

    @FragmentArg
    T answer;
    
}

Expected:
This should be valid, because the upper bound of the type parameter is indeed a Parcel bean, and its subtypes should be Parcel beans as well.

Actual: AA adds a validation error, because it things it is not Parcel bean.

@WonderCsabo WonderCsabo self-assigned this Feb 2, 2017
@WonderCsabo
Copy link
Member Author

@johncarl81 this is correct that in this case we should consider T as Parcel bean, right?

@johncarl81
Copy link
Contributor

johncarl81 commented Feb 2, 2017

@WonderCsabo, this is a little tricky. Parceler requires the bean in use to be annotated with @Parcel. Extending a bean that is annotated is not enough. I assume your end Fragment would have a concrete implementation to base your generated code on, would checking if a bean passes as a @Parcel annotated bean at that point be appropriate? In that case, I'd suggest looking at the WIP I have here johncarl81/transfuse@9933042 that can be used to resolve generic types to their concrete implementation declaration.

@WonderCsabo
Copy link
Member Author

@johncarl81 thanks for your quick answer, and sorry for my delayed one. Unfortunately in my case, the generic field is annotated, where we do not yet know the actual subclasses. If there is no guarantee if a superclass is a Parcel, then all of its subclasses are parcels as well by some type of contract, i guess we cannot validate this. Maybe Parceler should enforce this in some way?

@johncarl81
Copy link
Contributor

Correct me if I'm wrong, but in your example, there would be a concrete implementation that AA would use to generate the extension class, something like this:

@EFragment
public class ToUseFragment extends MyFragment<RealParcel> {...}

where RealParcel would be an @Parcel annotated bean.

If this is the case we can validate when generating the extension class for ToUseFragment.

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

No branches or pull requests

2 participants