You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
IllegalStateException with AndroidAnnotations 4.1 and @EViewGroup / @OrmLiteDao #2048
@TomWangTW
Hi. Thanks for reply.
These dependencies are already added.
I can use @OrmLiteDao with @EActivity, @efragment, @ebean classes, but, can't use only with @eviewgroup due to IllegalStateException(like #1887, the error appears in compile time).
So OrmLiteHolder calls getOnDestroyBeforeSuperBlock because it needs to release the helper there. But EViewHolder simply delegates to ReceiverRegistrationDelegate, which always throws an exception.
I think there is a bad design here. EView should not extend HasLifecycleMethods in the first place. And for these kind of registrations, it should return onAttach/onDetach in separate delegates.
Another thing maybe: should we allow these kind of things in views at all? I am not so familiar with the onAttach/onDetach lifecycle, can we rely on it?
EView should not extend HasLifecycleMethods in the first place.
I totally agree.
Another thing maybe: should we allow these kind of things in views at all? I am not so familiar with the onAttach/onDetach lifecycle, can we rely on it?
Unfortunately i have no idea if we can rely on the onAttach/onDetach lifecycle. For convinience reasons I'd say we should keep support for these kind of things, but I'm not sure if it is worth the effort to ensure that those features work as expected, and even more important do not leak resources during runtime...
regarding convinience: at least for this specific case of having database access directly in a view I'd say we could ignore the convinience aspect and say that there should be some kind of MVPish pattern that feeds the view with data.
It seems View.onAttachedToWindow() / onDetachedFromWindow() is reliable. It is called at ViewGroup.addView() / removeView() , and onDetachedFromWindow() is also called at Activity.onDestroy() if the view was not removed before.
Activity
TomWangTW commentedon Sep 22, 2017
Hi,
Have you try this?
For using OrmLiteDao, addd these new dependencies in your build.gradle:
compile "org.androidannotations:ormlite-api:4.0.0"
apt "org.androidannotations:ormlite:4.0.0"
Change your imports to
org.androidannotations.ormlite.annotations.OrmLiteDao
https://github.com/androidannotations/androidannotations/wiki/4.0.0-migration-guide
ytakahashi1981 commentedon Sep 22, 2017
@TomWangTW
Hi. Thanks for reply.
These dependencies are already added.
I can use @OrmLiteDao with @EActivity, @efragment, @ebean classes, but, can't use only with @eviewgroup due to IllegalStateException(like #1887, the error appears in compile time).
ytakahashi1981 commentedon Oct 3, 2017
I found what is wrong (maybe).
androidannotations/AndroidAnnotations/androidannotations-ormlite/ormlite/src/main/java/org/androidannotations/ormlite/holder/OrmLiteHolder.java
Lines 68 to 75 in 1847f70
This code seems to call below.
androidannotations/AndroidAnnotations/androidannotations-core/androidannotations/src/main/java/org/androidannotations/holder/EViewHolder.java
Lines 176 to 179 in 1847f70
androidannotations/AndroidAnnotations/androidannotations-core/androidannotations/src/main/java/org/androidannotations/holder/ReceiverRegistrationDelegate.java
Lines 97 to 99 in 1847f70
How can I avoid this?
(Sorry for my poor English...😢)
WonderCsabo commentedon Oct 30, 2017
@dodgex i found what is the issue.
So
OrmLiteHoldercallsgetOnDestroyBeforeSuperBlockbecause it needs to release the helper there. ButEViewHoldersimply delegates toReceiverRegistrationDelegate, which always throws an exception.I think there is a bad design here.
EViewshould not extendHasLifecycleMethodsin the first place. And for these kind of registrations, it should return onAttach/onDetach in separate delegates.Another thing maybe: should we allow these kind of things in views at all? I am not so familiar with the onAttach/onDetach lifecycle, can we rely on it?
dodgex commentedon Oct 30, 2017
I totally agree.
Unfortunately i have no idea if we can rely on the onAttach/onDetach lifecycle. For convinience reasons I'd say we should keep support for these kind of things, but I'm not sure if it is worth the effort to ensure that those features work as expected, and even more important do not leak resources during runtime...
dodgex commentedon Oct 30, 2017
regarding convinience: at least for this specific case of having database access directly in a view I'd say we could ignore the convinience aspect and say that there should be some kind of MVPish pattern that feeds the view with data.
WonderCsabo commentedon Oct 31, 2017
It seems
View.onAttachedToWindow()/onDetachedFromWindow()is reliable. It is called atViewGroup.addView()/removeView(), andonDetachedFromWindow()is also called atActivity.onDestroy()if the view was not removed before.Fix IllegalStateException for @OrmLiteDao in view
Fix IllegalStateException for @OrmLiteDao in view
Fix IllegalStateException for @OrmLiteDao in view