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

Conversation

@dodgex
Copy link
Member

@dodgex dodgex commented May 26, 2017

This PR allows to build against Android-O and fixes #2001 by adding an updated version of the view changed notfication code.

@dodgex dodgex requested a review from WonderCsabo May 26, 2017 21:20
@naixx
Copy link
Contributor

naixx commented Jun 5, 2017

So, what is the status of the PR?

@dodgex
Copy link
Member Author

dodgex commented Jun 6, 2017

@WonderCsabo was not yet able to review this PR. Yesterday he told me that he will try to get review this and the other PR asap.

Copy link
Member

@WonderCsabo WonderCsabo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we could still optimize the generated code by generating generic findViewById in @EFragment and @EBean. And also remove type casts when finding the views.

I am not sure how much work it would take. The current code should compile on Android O.

*/
package org.androidannotations.api.view;

public interface OnViewChangedListener2 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this class and OnViewChangedNotifier2 necessary? We can create HasViewsBase interface, and let HasViews and HasViews2 extend that. And reference HasViewsBase from OnViewChangedListener and OnViewChangedNotifier.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How could HasViewsBase look like? It would need to have a findViewById with a signature that is compatible to the other two versions. Or do i miss something in your suggestion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, we call findViewById() on HasViews, for some reason i assumed we just call this.findViewById().

Ah we really should have dropped @EBean view support and the whole HasViews ceremony. :(

Copy link
Member Author

@dodgex dodgex Jun 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately yes. So we need this stuff. :/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and do you guys have a name suggestion? (I'm pretty bad in naming stuff)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to use the generic variant, then we must use type cast in the implementing if compileSdkVersion < O. But that would be elegant, we could drop all the individual type casts. So go for it if you think.

Naming is very hard. What about findViewByIdentifier() ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for now i used internalFindViewById after i asked. if thats ok I'll keep it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it, keep it. 👍

Copy link
Contributor

@naixx naixx Jun 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's most probably won't clash with any user defined findViewById

resetPreviousNotifier(initBlock.blockSimple(), previousNotifier);
}

private boolean useGenerigFindViewById() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

useGenericFindViewById

}

private boolean useGenerigFindViewById() {
TypeElement activityType = environment.getProcessingEnvironment().getElementUtils().getTypeElement("android.app.Activity");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

string -> CanonicalNameConstants.ACTIVITY

@dodgex
Copy link
Member Author

dodgex commented Jun 10, 2017

I just updated the PR with a total rewrite of the fix. should be much better now. :)

@dodgex
Copy link
Member Author

dodgex commented Jun 10, 2017

I have not yet tested it in an Android O build, but for initial review of the changes it should be okay.


JVar idParam = findViewById.param(codeModel.INT, "id");
IJExpression findViewByIdExpression = holder.getFindViewByIdExpression(idParam);
findViewById.body()._return(JExpr.cast(genericType, findViewByIdExpression));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things:

  1. type cast is not needed on Android O .
  2. You can remove the cast for other places, since the type will be inferred with this signare

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I wanted to not have to check the Android version (or the presence of the generic method) here. Can change that if you want. Not sure if casts have a perf impact?
  2. Done.

Copy link
Member Author

@dodgex dodgex Jun 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional Note to 1: It looks like the AppCompatActivity does not yet have the generic findViewById so the cast would be needed on android O + appcompat activity.

i checked the code in android-o-preview-2 and master branches.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it would be nice to gain something from this new signature, if we doing so much work because of it. 😆 Since you already have the check code, i guess you can add it now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, they are overriding findViewById(), great... Then leave the cast here for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i just found that com.android.support:appcompat-v7:26.0.0-beta2 has the new signature.

Copy link
Member

@WonderCsabo WonderCsabo Jun 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. Then try to remove the cast with O.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cast is now gone for Android O. But it now requires to be on appcompat 26.0.0-beta2 (maybe beta1 works too; alpha1 does not).

}

public IJExpression getFindViewByIdExpression(JVar idParam) {
return _null();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe getFindViewByIdExpression should be an abstract method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was considering this. Then we'd have the return _null() in EBeanHolder. I decided to keep it this way, but with no solid reason. If you prefer to have this abstract I can change it.

@WonderCsabo
Copy link
Member

@dodgex it turns out the cast is needed for Fragments even on Android O. 😢

return ((contentView_ == null)?null:contentView_.findViewById(id));

Because using ternary operator and not calling the findViewById() directly, the compiler cannot deduce type T.

@dodgex
Copy link
Member Author

dodgex commented Jun 10, 2017

@WonderCsabo well while i think it would be nice to not have the cast in the generated code i think the code in AA required to get the cast when we it is needed and not have it when not needed is not worth the benefit. therefore I'd remove the check again and cast always... wdyt?

@WonderCsabo
Copy link
Member

WonderCsabo commented Jun 10, 2017 via email

@dodgex
Copy link
Member Author

dodgex commented Jun 10, 2017

check is gone. we should be good now =)

@WonderCsabo
Copy link
Member

I ran the test suite with compileSdkVersion = O, and everything passed.

@WonderCsabo WonderCsabo merged commit 621a577 into androidannotations:develop Jun 10, 2017
@WonderCsabo WonderCsabo added this to the 4.4 milestone Jun 10, 2017
@WonderCsabo
Copy link
Member

Nice work, @dodgex !

@dodgex dodgex deleted the 2001_support_android_o_findviewbyid branch June 10, 2017 17:47
@ghost
Copy link

ghost commented Jul 24, 2017

👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MainActivity_ is not abstract and does not override abstract method findViewById(int) in HasViews

3 participants