Repository navigation
IllegalStateException with AndroidAnnotations 4.1 and @EViewGroup / @OrmLiteDao #2048
Description
Activity
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.OrmLiteDaohttps://github.com/androidannotations/androidannotations/wiki/4.0.0-migration-guide
@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).
I found what is wrong (maybe).
Lines 68 to 75 in 1847f70
private void injectReleaseInOnDestroy(JFieldVar databaseHelperRef) { if (holder() instanceof HasLifecycleMethods) { JBlock destroyBody = ((HasLifecycleMethods) holder()).getOnDestroyBeforeSuperBlock(); destroyBody.staticInvoke(getJClass(OrmLiteClasses.OPEN_HELPER_MANAGER), "releaseHelper"); destroyBody.assign(databaseHelperRef, _null()); } } This code seems to call below.
Lines 176 to 179 in 1847f70
@Override public JBlock getOnDestroyBeforeSuperBlock() { return receiverRegistrationDelegate.getOnDestroyBeforeSuperBlock(); } Lines 97 to 99 in 1847f70
public JBlock getOnDestroyBeforeSuperBlock() { throw illegalStateException; } How can I avoid this?
(Sorry for my poor English...😢)
@dodgex i found what is the issue.
private void injectReleaseInOnDestroy(JFieldVar databaseHelperRef) { if (holder() instanceof HasLifecycleMethods) { JBlock destroyBody = ((HasLifecycleMethods) holder()).getOnDestroyBeforeSuperBlock(); destroyBody.staticInvoke(getJClass(OrmLiteClasses.OPEN_HELPER_MANAGER), "releaseHelper"); destroyBody.assign(databaseHelperRef, _null()); } }
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?
EViewshould not extendHasLifecycleMethodsin 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 atViewGroup.addView()/removeView(), andonDetachedFromWindow()is also called atActivity.onDestroy()if the view was not removed before.- added a commit that references this issue
on Oct 31, 2017 - added 2 commits that reference this issue
on Oct 31, 2017
I have the same issue as #1887.
I updated #1887, but there is no response maybe due to issue status(closed).
I cannot upgrade AA to 4.x because of upgration cost with this issue...
(many many views are using OrmLiteDao annotations in my product...)
Maybe you can reproduce with these simple sources.
(My AA version is 4.3.1 but reproduced with 4.1)
TestDao.java
TestEntity.java
TestView.java
DBHelper.java