johncarl81
commented
6 years ago Hmm, do you have a class that you've annotated with @Parcel that has generics defined?
Open doniwinata0309 opened 6 years ago
johncarl81
commented
6 years ago Hmm, do you have a class that you've annotated with @Parcel that has generics defined?
doniwinata0309
commented
6 years ago Hi @johncarl81, does generic defined means is generic on the base class or generic on the field ?
We only have generic on the field:
protected LinkedHashMap<String, String> promo;
this class annotated with @Parcel and used as viewmodel for databinding.
johncarl81
commented
6 years ago Could you share the full details of that class? I wonder if changing LinkedHashMap<..> to just Map<...> would make a difference.
doniwinata0309
commented
6 years ago This is the example of full class:
@Parcel
public class TestParcel extends BaseObservable {
protected LinkedHashMap<String, String> promo;
public TestParcel() {
promo = new LinkedHashMap<>();
}
@Bindable
public LinkedHashMap<String, String> getPromo() {
return promo;
}
public void setPromo(LinkedHashMap<String, String> promo) {
this.promo = promo;
notifyPropertyChanged(BR.promo);
}
}We use so many LinkedHashMap on the other class as well, do you think LinkedHashMap could be the problem here ?
johncarl81
commented
6 years ago Ah, I think it's tripping up on something in BaseObservable. Would you try the following configuration:
@Parcel(analyze = TestParcel.class)
public class TestParcel extends BaseObservable {
protected LinkedHashMap<String, String> promo;
public TestParcel() {
promo = new LinkedHashMap<>();
}
@Bindable
public LinkedHashMap<String, String> getPromo() {
return promo;
}
public void setPromo(LinkedHashMap<String, String> promo) {
this.promo = promo;
notifyPropertyChanged(BR.promo);
}
}In general I opt for using the most general interface I can - typically using the interface over the implementation. In this case LinkedHashMap is an implementation of Map. Parceler does handle LinkedHashMap though, so that's not an issue.
doniwinata0309
commented
6 years ago I just added analyze on the top of the class but cannot see any difference from the log or error trace, what analyze use for ?
johncarl81
commented
6 years ago analyze is used to explicitly indicate which classes for Parceler to process (Javadocs)
johncarl81
commented
6 years ago Any success on this one @doniwinata0309 ?
doniwinata0309
commented
5 years ago hi @johncarl81 , apologize for the late reply. I just put all @Parcel annotation with analyze parameter, but the error remain the same. do you have other suggestion ?
doniwinata0309
commented
5 years ago I just check the documentation again, is it mandatory for these points after 1.1.6 ?
doniwinata0309
commented
5 years ago Hi @johncarl81, I just checked the version 1.1.17 -1.1.9 also failed with the same error. Then the version 1.1.10 has different error with 1.1.7, but the same with 1.1.11.
johncarl81
commented
5 years ago Hi @doniwinata0309, could you produce a quick sample app to demonstrate the issue? That would help me greatly in debugging.
doniwinata0309
commented
5 years ago sure, i will try to repro this from new project if possible.
By the way, after checking the build folder, i just found out that the @Parcel class is not generated with this scenario.
ex:
@Parcel
public class class1 {
protected String id;
protected myInnerClass myClass2;
@Parcel
public static class myInnerClass{
....
}
}Is this behaviour expected ?
johncarl81
commented
5 years ago johncarl81
commented
5 years ago @doniwinata0309, still having issues with this? If not, I'd like to close.
doniwinata0309
commented
5 years ago Yes we still facing the error, but i think we can close it for now. Aplogise for slow response. Thanks @johncarl81
doniwinata0309
commented
5 years ago By the way, do you have advice how to debugging the error ? I have no idea which file causing this null error. So far i know which module that causing the error, but it contains like hundred of classes with parceler annotation. It would be nice if we can pointing specific file that causing it.
johncarl81
commented
5 years ago quite alright... I dont know, but I've heard of similar problems recently in Kotlin... are you trying to set up an @Parcel on a sealed class?
johncarl81
commented
5 years ago Ping @doniwinata0309
doniwinata0309
commented
5 years ago Hi @johncarl81 , no we didn't use sealed class at all. I just checked my code, seems like it is different issue.
doniwinata0309
commented
5 years ago hi @johncarl81 , we have found 2 files that causing error. it is something like this:
@Parcel
public class ExampleClass<T extends Serializable> {
protected String titleExample;
//remove this, build success
protected List<ParcelableClassExample<T>> testList;
public List<ParcelableClassExample<T>> getChangeItems() {
return null;
}
public void setChangeItems(List<ParcelableClassExample<T>> changeItems) {
testList = changeItems;
}
public String getChangeTitle() {
return titleExample;
}
public void setChangeTitle(String changeTitle) {
titleExample = changeTitle;
}
}
Do you know what might be wrong here ? Removing list object will not causing error. I am still working to make sample, don't know why it cannot be repro on the sample.
johncarl81
commented
5 years ago Ah, it's because Parceler doesn't know what to do with the generic type here... it's undefined in terms of this particular class. Do you marshall (call Parcels.wrap/unwrap) ExampleClass directly or do you marshal subclasses of it?
johncarl81
commented
5 years ago Ah, interesting, it seems it's failing on lookup up the generic for the collection type:
List<ParcelableClassExample<T>>Now, I think this is something to fix...
doniwinata0309
commented
5 years ago Thanks @johncarl81, we marshal the class directly.
doniwinata0309
commented
5 years ago Hi @johncarl81 , this object also causing the same error on our project
List<T> itemList;
johncarl81
commented
5 years ago For the time being, you can get around this issue by subclassing your class with generic parameters, specifying the concretes:
@Parcel
public class StringExampleClass extends ExampleClass<String> {}This has its limitations - particularly when dealing with multiple classes in an object graph. But, I hope it would be a crutch for this issue until we can figure out a fix.
doniwinata0309
commented
5 years ago Thank for your suggestion @johncarl81 ! Will try wether we can pass specifying object or not in our case. Hopefully it will fixed soon since we need to use AGP 3.3, it requires parceler 1.1.12 because of androidX migration. let me know if i can do something to help you.
johncarl81
commented
5 years ago If you could test a potential fix, I'd greatly appreciate it! I hope to spend some timr on it this weekend.
On Fri, Jan 11, 2019, 8:08 PM doniwinata0309 <notifications@github.com wrote:
Thank for your suggestion @johncarl81 https://github.com/johncarl81 ! Will try wether we can pass specifying object or not in our case. Hopefully it will fixed soon since we need to use AGP 3.3, it requires parceler 1.1.12 because of androidX migration. let me know if i can do something to help you.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/johncarl81/parceler/issues/355#issuecomment-453714648, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKMqY8UfuJcDXyXxlMZ_LFnA9eMiFDwks5vCVG_gaJpZM4XDWSd .
doniwinata0309
commented
5 years ago It is working perfectly @johncarl81 . i just trying your suggestion, so we put @parcel on subclass instead of the main class right ? so far it is good, but will need to test them on monday.
doniwinata0309
commented
5 years ago hi @johncarl81 , do you have plan to do fix about this issue ?
Hi, I got this error after updating to parceler 1.1.11, while it is working fine on parceler 1.1.6
Android gradle plugin : 3.1.2 Kotlin: 1.2.40 androidSupport : 27.1.1 Databinding compiler: 27.1.1
Here some error log from logcat and please let me know if you need additional information. do you know what might be wrong with this ? thank you