-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Add support for new method signature of findViewById in Android O #2008
Add support for new method signature of findViewById in Android O #2008
Conversation
|
So, what is the status of the PR? |
|
@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. |
WonderCsabo
left a comment
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. :(
There was a problem hiding this comment.
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. :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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() ?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. 👍
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
string -> CanonicalNameConstants.ACTIVITY
|
I just updated the PR with a total rewrite of the fix. should be much better now. :) |
|
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)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things:
- type cast is not needed on Android O .
- You can remove the cast for other places, since the type will be inferred with this signare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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?
- Done.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
@dodgex it turns out the cast is needed for return ((contentView_ == null)?null:contentView_.findViewById(id));Because using ternary operator and not calling the |
|
@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? |
|
Okay.
…On Jun 10, 2017 18:10, "Kay-Uwe Janssen" ***@***.***> wrote:
@WonderCsabo <https://github.com/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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2008 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAdU5dw3YBnsQWsvU3NuheYQE4a7tGivks5sCsAAgaJpZM4NoEnP>
.
|
|
check is gone. we should be good now =) |
|
I ran the test suite with |
|
Nice work, @dodgex ! |
|
👍 |
This PR allows to build against Android-O and fixes #2001 by adding an updated version of the view changed notfication code.