OS version 4.4 (KitKat) and 5 (Lollipop) onVisibilityChanged Listener Not Firing
I have looked online for an answer to this, but have not found the root cause of this issue.
I have an application with a view, that listens in on onVisibilityChanged and onWindowVisibilityChanged. What I have noticed is that on Android devices with either KitKat (API 19) or Lollipop (API 22), when the view gets attached to the main layout, onVisibilityChanged is never fired, only onWindowVisibilityChanged.
I am guessing this issue originates with a native API change that occurred from KitKat up to Lollipop, but have not found any documentation or reference to this. When I checked my application on Marshmallow (API 23), it did not happen.
I would just like to know if this is a known issue or if there is some sort of way to fix this behavior.
Thanks.
android view visibility
asked Nov 10 '18 at 9:16
tomerpacific
360118
|
show 9 more comments
I have looked online for an answer to this, but have not found the root cause of this issue.
I have an application with a view, that listens in on onVisibilityChanged and onWindowVisibilityChanged. What I have noticed is that on Android devices with either KitKat (API 19) or Lollipop (API 22), when the view gets attached to the main layout, onVisibilityChanged is never fired, only onWindowVisibilityChanged.
I am guessing this issue originates with a native API change that occurred from KitKat up to Lollipop, but have not found any documentation or reference to this. When I checked my application on Marshmallow (API 23), it did not happen.
I would just like to know if this is a known issue or if there is some sort of way to fix this behavior.
Thanks.
android view visibility
asked Nov 10 '18 at 9:16
tomerpacific
360118
post your code snippet
– Pemba Tamang
Dec 1 '18 at 9:06
@PembaTamang - Cannot post code snippet as it is intricate code with company logic. In respect to the View classes, the two listeners, onVisibilityChanged and onWindowVisibilityChanged are implemented as is. They should be called normally (as happens in OS versions after 5.1).
– tomerpacific
Dec 1 '18 at 16:53
could you de couple the business logic and post the code ??
– Pemba Tamang
Dec 2 '18 at 14:48
its the only way you'll find a good answer
– Pemba Tamang
Dec 2 '18 at 14:49
@PembaTamang - I understand what you are saying, but in regards to the visibility listeners, they are implemented vanilla wise. There is no special logic there. Just overriding the methods from the parent view class. There should not be an issue if they are working on newer operating system versions.
– tomerpacific
Dec 2 '18 at 15:26
|
show 9 more comments
I have looked online for an answer to this, but have not found the root cause of this issue.
I have an application with a view, that listens in on onVisibilityChanged and onWindowVisibilityChanged. What I have noticed is that on Android devices with either KitKat (API 19) or Lollipop (API 22), when the view gets attached to the main layout, onVisibilityChanged is never fired, only onWindowVisibilityChanged.
I am guessing this issue originates with a native API change that occurred from KitKat up to Lollipop, but have not found any documentation or reference to this. When I checked my application on Marshmallow (API 23), it did not happen.
I would just like to know if this is a known issue or if there is some sort of way to fix this behavior.
Thanks.
android view visibility
asked Nov 10 '18 at 9:16
tomerpacific
360118
I have looked online for an answer to this, but have not found the root cause of this issue.
I have an application with a view, that listens in on onVisibilityChanged and onWindowVisibilityChanged. What I have noticed is that on Android devices with either KitKat (API 19) or Lollipop (API 22), when the view gets attached to the main layout, onVisibilityChanged is never fired, only onWindowVisibilityChanged.
I am guessing this issue originates with a native API change that occurred from KitKat up to Lollipop, but have not found any documentation or reference to this. When I checked my application on Marshmallow (API 23), it did not happen.
I would just like to know if this is a known issue or if there is some sort of way to fix this behavior.
Thanks.
android view visibility
android view visibility
asked Nov 10 '18 at 9:16
tomerpacific
360118
asked Nov 10 '18 at 9:16
tomerpacific
360118
edited Nov 11 '18 at 7:23
asked Nov 10 '18 at 9:16
tomerpacific
360118
asked Nov 10 '18 at 9:16
tomerpacific
360118
asked Nov 10 '18 at 9:16
tomerpacific
360118
360118
post your code snippet
– Pemba Tamang
Dec 1 '18 at 9:06
@PembaTamang - Cannot post code snippet as it is intricate code with company logic. In respect to the View classes, the two listeners, onVisibilityChanged and onWindowVisibilityChanged are implemented as is. They should be called normally (as happens in OS versions after 5.1).
– tomerpacific
Dec 1 '18 at 16:53
could you de couple the business logic and post the code ??
– Pemba Tamang
Dec 2 '18 at 14:48
its the only way you'll find a good answer
– Pemba Tamang
Dec 2 '18 at 14:49
@PembaTamang - I understand what you are saying, but in regards to the visibility listeners, they are implemented vanilla wise. There is no special logic there. Just overriding the methods from the parent view class. There should not be an issue if they are working on newer operating system versions.
– tomerpacific
Dec 2 '18 at 15:26
|
show 9 more comments
post your code snippet
– Pemba Tamang
Dec 1 '18 at 9:06
@PembaTamang - Cannot post code snippet as it is intricate code with company logic. In respect to the View classes, the two listeners, onVisibilityChanged and onWindowVisibilityChanged are implemented as is. They should be called normally (as happens in OS versions after 5.1).
– tomerpacific
Dec 1 '18 at 16:53
could you de couple the business logic and post the code ??
– Pemba Tamang
Dec 2 '18 at 14:48
its the only way you'll find a good answer
– Pemba Tamang
Dec 2 '18 at 14:49
@PembaTamang - I understand what you are saying, but in regards to the visibility listeners, they are implemented vanilla wise. There is no special logic there. Just overriding the methods from the parent view class. There should not be an issue if they are working on newer operating system versions.
– tomerpacific
Dec 2 '18 at 15:26
post your code snippet
– Pemba Tamang
Dec 1 '18 at 9:06
post your code snippet
– Pemba Tamang
Dec 1 '18 at 9:06
@PembaTamang - Cannot post code snippet as it is intricate code with company logic. In respect to the View classes, the two listeners, onVisibilityChanged and onWindowVisibilityChanged are implemented as is. They should be called normally (as happens in OS versions after 5.1).
– tomerpacific
Dec 1 '18 at 16:53
@PembaTamang - Cannot post code snippet as it is intricate code with company logic. In respect to the View classes, the two listeners, onVisibilityChanged and onWindowVisibilityChanged are implemented as is. They should be called normally (as happens in OS versions after 5.1).
– tomerpacific
Dec 1 '18 at 16:53
could you de couple the business logic and post the code ??
– Pemba Tamang
Dec 2 '18 at 14:48
could you de couple the business logic and post the code ??
– Pemba Tamang
Dec 2 '18 at 14:48
its the only way you'll find a good answer
– Pemba Tamang
Dec 2 '18 at 14:49
its the only way you'll find a good answer
– Pemba Tamang
Dec 2 '18 at 14:49
@PembaTamang - I understand what you are saying, but in regards to the visibility listeners, they are implemented vanilla wise. There is no special logic there. Just overriding the methods from the parent view class. There should not be an issue if they are working on newer operating system versions.
– tomerpacific
Dec 2 '18 at 15:26
@PembaTamang - I understand what you are saying, but in regards to the visibility listeners, they are implemented vanilla wise. There is no special logic there. Just overriding the methods from the parent view class. There should not be an issue if they are working on newer operating system versions.
– tomerpacific
Dec 2 '18 at 15:26
|
show 9 more comments
1 Answer
1
active
oldest
votes
It looks like the Android team did indeed change this behavior in Android 23 - Marshmallow. If you look at the source code for View.java in Android 23, you can see that they added a call to onVisibilityChanged inside of dispatchAttachedToWindow.
Here is the commit to AOSP where this change happened.
Here is the diff for that change.
Given that you are unable to post your code, I cannot offer a better solution than to point you to the change.
If you are trying to track view attaches to the window, I would suggest the onAttachedToWindow API.
Note that the method that calls onVisibilityChanged in Android 23 is most likely dispatchAttachedToWindow. This method also calls onAttachedToWindow, so you could theoretically listen for this and check the visibility manually.
// Override inside your custom view
override fun onAttachedToWindow()
super.onAttachedToWindow()
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.M)
// Check for visibility here, but note that onVisibilityChanged initially gets called with View.GONE
// Unless the view is inside of a ViewGroup. See the source code for ViewRootImpl.java for more details.
Otherwise, you will need to special case your logic for Android 22 and below such that you listen to the onWindowVisibilityChanged more instead of onVisibilityChanged.
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53237535%2fos-version-4-4-kitkat-and-5-lollipop-onvisibilitychanged-listener-not-firing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It looks like the Android team did indeed change this behavior in Android 23 - Marshmallow. If you look at the source code for View.java in Android 23, you can see that they added a call to onVisibilityChanged inside of dispatchAttachedToWindow.
Here is the commit to AOSP where this change happened.
Here is the diff for that change.
Given that you are unable to post your code, I cannot offer a better solution than to point you to the change.
If you are trying to track view attaches to the window, I would suggest the onAttachedToWindow API.
Note that the method that calls onVisibilityChanged in Android 23 is most likely dispatchAttachedToWindow. This method also calls onAttachedToWindow, so you could theoretically listen for this and check the visibility manually.
// Override inside your custom view
override fun onAttachedToWindow()
super.onAttachedToWindow()
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.M)
// Check for visibility here, but note that onVisibilityChanged initially gets called with View.GONE
// Unless the view is inside of a ViewGroup. See the source code for ViewRootImpl.java for more details.
Otherwise, you will need to special case your logic for Android 22 and below such that you listen to the onWindowVisibilityChanged more instead of onVisibilityChanged.
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
add a comment |
It looks like the Android team did indeed change this behavior in Android 23 - Marshmallow. If you look at the source code for View.java in Android 23, you can see that they added a call to onVisibilityChanged inside of dispatchAttachedToWindow.
Here is the commit to AOSP where this change happened.
Here is the diff for that change.
Given that you are unable to post your code, I cannot offer a better solution than to point you to the change.
If you are trying to track view attaches to the window, I would suggest the onAttachedToWindow API.
Note that the method that calls onVisibilityChanged in Android 23 is most likely dispatchAttachedToWindow. This method also calls onAttachedToWindow, so you could theoretically listen for this and check the visibility manually.
// Override inside your custom view
override fun onAttachedToWindow()
super.onAttachedToWindow()
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.M)
// Check for visibility here, but note that onVisibilityChanged initially gets called with View.GONE
// Unless the view is inside of a ViewGroup. See the source code for ViewRootImpl.java for more details.
Otherwise, you will need to special case your logic for Android 22 and below such that you listen to the onWindowVisibilityChanged more instead of onVisibilityChanged.
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
add a comment |
It looks like the Android team did indeed change this behavior in Android 23 - Marshmallow. If you look at the source code for View.java in Android 23, you can see that they added a call to onVisibilityChanged inside of dispatchAttachedToWindow.
Here is the commit to AOSP where this change happened.
Here is the diff for that change.
Given that you are unable to post your code, I cannot offer a better solution than to point you to the change.
If you are trying to track view attaches to the window, I would suggest the onAttachedToWindow API.
Note that the method that calls onVisibilityChanged in Android 23 is most likely dispatchAttachedToWindow. This method also calls onAttachedToWindow, so you could theoretically listen for this and check the visibility manually.
// Override inside your custom view
override fun onAttachedToWindow()
super.onAttachedToWindow()
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.M)
// Check for visibility here, but note that onVisibilityChanged initially gets called with View.GONE
// Unless the view is inside of a ViewGroup. See the source code for ViewRootImpl.java for more details.
Otherwise, you will need to special case your logic for Android 22 and below such that you listen to the onWindowVisibilityChanged more instead of onVisibilityChanged.
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
It looks like the Android team did indeed change this behavior in Android 23 - Marshmallow. If you look at the source code for View.java in Android 23, you can see that they added a call to onVisibilityChanged inside of dispatchAttachedToWindow.
Here is the commit to AOSP where this change happened.
Here is the diff for that change.
Given that you are unable to post your code, I cannot offer a better solution than to point you to the change.
If you are trying to track view attaches to the window, I would suggest the onAttachedToWindow API.
Note that the method that calls onVisibilityChanged in Android 23 is most likely dispatchAttachedToWindow. This method also calls onAttachedToWindow, so you could theoretically listen for this and check the visibility manually.
// Override inside your custom view
override fun onAttachedToWindow()
super.onAttachedToWindow()
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.M)
// Check for visibility here, but note that onVisibilityChanged initially gets called with View.GONE
// Unless the view is inside of a ViewGroup. See the source code for ViewRootImpl.java for more details.
Otherwise, you will need to special case your logic for Android 22 and below such that you listen to the onWindowVisibilityChanged more instead of onVisibilityChanged.
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
edited Dec 5 '18 at 5:55
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
answered Dec 5 '18 at 5:43
Kevin Marlow
531311
531311
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
add a comment |
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
Thank you very much. This is what I was suspicious of. Major kudos!
– tomerpacific
Dec 5 '18 at 6:28
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53237535%2fos-version-4-4-kitkat-and-5-lollipop-onvisibilitychanged-listener-not-firing%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
post your code snippet
– Pemba Tamang
Dec 1 '18 at 9:06
@PembaTamang - Cannot post code snippet as it is intricate code with company logic. In respect to the View classes, the two listeners, onVisibilityChanged and onWindowVisibilityChanged are implemented as is. They should be called normally (as happens in OS versions after 5.1).
– tomerpacific
Dec 1 '18 at 16:53
could you de couple the business logic and post the code ??
– Pemba Tamang
Dec 2 '18 at 14:48
its the only way you'll find a good answer
– Pemba Tamang
Dec 2 '18 at 14:49
@PembaTamang - I understand what you are saying, but in regards to the visibility listeners, they are implemented vanilla wise. There is no special logic there. Just overriding the methods from the parent view class. There should not be an issue if they are working on newer operating system versions.
– tomerpacific
Dec 2 '18 at 15:26