DeviceDisplay.Current.MainDisplayInfoChanged not fired if app is in background (Android)

[AlleSchonWeg]

Description

If an app, which registered the DeviceDisplay.MainDisplayInfoChanged event, is in background and you rotate the device the event is not fired. Even if the app comes to foreground again. As a result you can't adapt the UI. The problem also exists in the XF Essentials

iOS works as expected.

Steps to Reproduce

See description.

Link to public reproduction project repository

No response

Version with bug

8.0.6

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[ghost]

Hi @AlleSchonWeg. We have added the "s/needs-repro" label to this issue, which indicates that we require steps and sample code to reproduce the issue before we can take further action. Please try to create a minimal sample project/solution or code samples which reproduce the issue, ideally as a GitHub repo that we can clone. See more details about creating repros here: https://github.com/dotnet/maui/blob/main/.github/repro.md

This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[AlleSchonWeg]

You must joking. Repro an event registration.

[drasticactions]

That event is not fired because of, I believe, how Android works.

https://github.com/dotnet/maui/blob/d749dc779531dcf491746fd2f190382db4f18e0d/src/Essentials/src/DeviceDisplay/DeviceDisplay.android.cs#L103-L115

That API uses an OrientationEventListener, which requires the current Android Application Context. The app needs to be alive for that to be listening. Otherwise, it would be running at all times no matter if your user was in the app or not (which wouldn't be great for Battery life if every app had to do that). So that's expected behavior. So when the app resumes, no event will be fired because no event has occurred.

IMO, if you're basing UI decisions around screen rotations, I would suggest using something like Visual States instead, as they should be calculated when your app is brought back. Also, as Android apps can run inside of their own windows (On Chrome OS and Windows Subsystem for Android, among others), basing UI around full screens and device rotations would probably limit what you want to do.

So in short, I'm not sure there's a bug here. This seems like the expected use of those APIs for the running platform.

@jonathanpeppers Is what I'm saying about the Android stuff correct? If so, are there ways to handle this?

[AlleSchonWeg]

Hi @drasticactions , thanks for your reply. Visual States are nice, but it only works for basic things. If the layout becomes complex and you have to change gid columns, rows or you need additional data from a web api it becomes more difficult.

One way to handle this is listen to the OnConfigurationChanged Activity event: https://stackoverflow.com/a/5726776/4506984. This is fired when the app comes back to foreground. There are another solutions on SO or in the WWW. Like this: https://stackoverflow.com/questions/8248274/android-detect-orientation-changed?answertab=scoredesc#tab-top

[drasticactions]

Handling that activity event to update the orientation of the screen for that specific MAUI API seems like overkill to be added to the product.

It's already handled in the MauiActivity for Android so you should be able to override that method yourself if you wish in your application.

But for that specific device API in MAUI, as far as I'm aware, you can't do that safely inside of MAUI Essentials. That said, maybe that API is meant to update in the background and it is a bug, I leave that to someone on the MAUI team to know (I'm not on the MAUI Team, just a member of .NET)

Handling it yourself for your own app should be fine though to me.

[AlleSchonWeg]

I know thats already handled in MAUI. And i have my own logic to handle this. But i thought if Maui Essentials has such a event i can use it without implementing my own platfom code for android. Perhaps there are other solutions to handle this. If actual behaviour is expected than the docs should be updated that the event works only if app is in foreground.

[jonathanpeppers]

@AlleSchonWeg I would compare the other platforms and see if the behavior differs between iOS & Android, for example.

If it does differ, Maui.Essentials could consider firing the event when activities are resumed (and the orientation changed).

I think the main goal for these APIs, is you get the same behavior on different platforms. But they just surface what each platform provides.

[AlleSchonWeg]

Hi @jonathanpeppers As I wrote in OP and in linked issue iOS work's. To be clear: The event is fired when a iOS app is in background then rotate the device and open the app again to foreground. Thanks

[jfversluis]

You must joking. Repro an event registration.

Definitely not: https://github.com/dotnet/maui/blob/main/.github/repro.md a lot of people will think its only just that piece of code, a lot of times there is more moving parts to make something happen and the way they discover that is by putting together a reproduction.

Additionally, when a reproduction is attached we can later verify with a newer version, when we revisit this, if the behavior is now changed and thus probably fixed.

Lastly, it makes it very easy for us to lift your code into a test so we make sure we don't regress.

Anyway, this seems to be due to differences on the OS level, not much we can do about it. Thanks everyone!