Open nau-dwb opened 9 months ago
I downloaded your sample, ran it on an iPad simulator, and the list shows up on the first load... could you test again, with an updated version of .net and maui ?
@StephaneDelcroix - Sorry, I'd posted about some issues getting the maui workloads installed on the Mac but I resolved that.
I did want to confirm whether you updated the sample to .NET8 or just ran it with the latest .NET installed on the machine.
@StephaneDelcroix I was finally able to update to the latest version of the .NET 8 SDK and install the workloads. I ran into the issue trying to pair from Windows to Mac noted here but the workaround of copying the workload sub folder finally got past that. Why is it so incredibly painful to try to be productive with this?
Anyway, after all that I'm still able to repo my issue. Again, the actual project is still targeting net7.0-ios - please let me know if you changed that to target .NET8 but from your post I interpreted it as you downloaded and ran it without changes.
I have a screen shot of the versions installed on Mac and Windows below:
Additional Info:
@StephaneDelcroix - I changed the sample project to target net8.0-ios and can confirm I still experience the issue. The first time I go to the list page, I see no items. Tap back, navigate again, and the three entry items display.
Since I last commented I had to update to xCode 15.1and when I list SDKs on Windows it's at 8.0.204 instead of .203 but otherwise everything else in my prior screen shot is accurate for versions.
@StephaneDelcroix - Following up from my last post where I'm still able to repro on .NET8 and the listed version of the workload. Is anyone else able to repro?
The main issue here is that we aren't assigning a Window
to the MAUI controls.
We have a workaround for this in our samples https://github.com/dotnet/maui-samples/blob/main/8.0/PlatformIntegration/NativeEmbeddingDemo/NativeEmbeddingDemo.Library/EmbeddedWindowHandler.cs
That will fix this scenario, we are hoping to have this resolved in net9
Description
This is a truly odd bug and took me awhile to figure out exactly how to reproduce it. I have not seen this behavior in Android, only iOS. We're migrating from a Xamarin Android and Xamarin iOS with embedded Xamarin Forms app to .NET Android and .NET iOS with embedded MAUI and this is but one of a number of things that no longer works.
A little background. As we're using MAUI embedded, we render the pages to native iOS controllers or Android Fragments and then navigate to them through the native navigation stack. Due to this, we hide the native navigation bar and create our own navigation bar layout that we include on the page.
To reduce duplicated XAML code and make development quicker, we created a navigation bar control backed by a view model that controls how the custom navigation bar looks and operates (title text, whether to show Back or Action buttons, commands to fire when buttons pressed, etc.).
To make it easy to include this navigation bar control in every Page, we had created a ControlTemplate similar to
Then, in our Resource Dictionary containing common styles, we create an implicit style for ContentPage to use this template like so:
The end result is each page displays the custom navigation bar and the XAML content of each page displays in place of the ContentPresenter in the template.
This all worked great in Xamarin Forms. In MAUI, I started to notice a weird issue where sometimes, none of the bindings on a page seemed to work. If I navigated backwards, and the navigated to the applicable page again, everything displayed correctly and I never would see the broken binding behavior again. I finally tracked down how to repro this.
So take the navigation pattern of Native iOS Controller -> Maui Page One -> Maui Page Two. Now, presume that before navigating to Maui Page One an alert was displayed communicating we were loading some data before navigating. In this scenario, the bindings on MAUI Page One work OK. When then navigating to MAUI Page Two from MAUI Page One, none of the bindings will work on MAUI Page Two - no data is displayed, no commands work on tap, etc. If we navigate back to Maui Page One and then to Maui Page Two, then all the bindings work fine and we see the data on the page we would expect. I should note the navigation bar was fine on MAUI Page Two, just the expected content of the actual page failed to display.
This ONLY happens on that first navigation to MAUI Page Two from MAUI Page One and ONLY if some form of Modal Dialog controller was displayed first on the Native iOS controller prior to navigating to MAUI Page One.
Steps to Reproduce
Please note I set this up so you can see it repros the failure when:
The code is also set up to demonstrate the failure does not repro when:
Using the provided code in the repo:
simple-maui-binding-issue
In the
ButtonEventDemoViewController
class, assign one of the constants for a failing path to the variabledemoPathToRun
:Expected: The bindings on the second page should work and content displays on the first navigation to it.
Actual: The bindings are broken initially on the second page and only work correctly the second time through.
General Steps
Link to public reproduction project repository
https://github.com/nau-dwb/maui-embedded-use-issues/tree/main
Version with bug
Unknown/Other
Is this a regression from previous behavior?
Yes, this used to work in Xamarin.Forms
Last version that worked well
Unknown/Other
Affected platforms
iOS, I was not able test on other platforms
Affected platform versions
iOS 14.2+ with .NET 7
Did you find any workaround?
No. As noted, this does not seem to be an issue unless the native IOS controller displayed a modal like an alert first, but we have a pretty common pattern of displaying an alert dialog while we load data or make some service call prior to navigating to an embedded MAUI page.
Another option might be to not use the control template and include the custom control on each page though I have not tried that and it's not really an option for us as that drastically reduces the maintainability of the app and increases duplication.
Relevant log output
No response