Skip to content
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
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

Description

@ytakahashi1981

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

public class TestDao extends BaseDaoImpl<TestEntity, Integer> {
	protected TestDao(ConnectionSource connectionSource, Class<TestEntity> dataClass) throws SQLException {
		super(connectionSource, dataClass);
	}
}

TestEntity.java

@DatabaseTable(tableName = "Test", daoClass = TestDao.class)
public class TestEntity {
}

TestView.java

@EViewGroup
public class TestView extends FrameLayout {

	@OrmLiteDao(helper = DBHelper.class)
	TestDao testDao;

	public TestView(@NonNull Context context) {
		super(context);
	}

}

DBHelper.java

public class DBHelper extends OrmLiteSqliteOpenHelper {
	public DBHelper(Context context) {
		super(context, "test.db", null, 1);
	}

	@Override
	public void onCreate(SQLiteDatabase database, ConnectionSource connectionSource) {}

	@Override
	public void onUpgrade(SQLiteDatabase database, ConnectionSource connectionSource, int oldVersion, int newVersion) {}
}

Activity

  1. TomWangTW commented on Sep 22, 2017

    @TomWangTW

    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

  2. ytakahashi1981 commented on Sep 22, 2017

    @ytakahashi1981
    Author

    @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).

  3. ytakahashi1981 commented on Oct 3, 2017

    @ytakahashi1981
    Author

    I found what is wrong (maybe).

    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.

    @Override
    public JBlock getOnDestroyBeforeSuperBlock() {
    return receiverRegistrationDelegate.getOnDestroyBeforeSuperBlock();
    }

    How can I avoid this?

    (Sorry for my poor English...😢)

  4. WonderCsabo commented on Oct 30, 2017

    @WonderCsabo
    Member

    @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 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?

  5. dodgex commented on Oct 30, 2017

    @dodgex
    Member

    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...

  6. dodgex commented on Oct 30, 2017

    @dodgex
    Member

    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.

  7. WonderCsabo commented on Oct 31, 2017

    @WonderCsabo
    Member

    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.

  8. self-assigned this
    on Oct 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions