Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calendar view in maui causes crash on physical android device #67

Open
sfoslund opened this issue Sep 23, 2022 · 9 comments
Open

Calendar view in maui causes crash on physical android device #67

sfoslund opened this issue Sep 23, 2022 · 9 comments
Labels
awaiting-author Awaiting a respose from the author bug Something isn't working

Comments

@sfoslund
Copy link

Describe the bug
When including a CalendarView in a maui android app the app crashes, presumably because the calendar view is taking so long to load. My app is running fine (but noticeably slowly) on an android emulator but as soon as I install it on a physical device it crashes.

Expected behavior
Calendar view renders without crash

Steps to reproduce OR link to code
Repro project: https://github.com/sfoslund/DailyCheckinApp/blob/main/DailyCheckinApp/Views/CalendarView.xaml#L17

Xamarin Forms or .NET MAUI (If related to UI)
.NET MAUI

Device Info (Optional)
Device Model: Google Pixel 4A
Android Version: 12
IOS Version: N/a
Windows Version: N/a

@sfoslund sfoslund added the bug Something isn't working label Sep 23, 2022
@ME-MarvinE ME-MarvinE added the good first issue Good for newcomers label Sep 23, 2022
@ME-MarvinE
Copy link
Owner

ME-MarvinE commented Sep 23, 2022

Testing

When ran from debug on a Huawei Mate 20 lite, start-up took on average18-19 seconds (Ran 4 times) and rendered this:

View Screenshot

Screenshot_20220923_201349_sfoslund dailycheckinapp

However when not running with the debugger, start-up took on average 3-4 seconds (Ran 4 times) and crashed each time.

When ran from debug on a Samsung A52s, start-up took on average 9-10 seconds (Ran 4 times) and rendered this:

View Screenshot

Screenshot_20220923-202027

However when not running with the debugger, start-up took on average 2 seconds (Ran 4 times) and crashed each time.

After some more testing, I found that the crash is caused by the Style property of the CalendarView, NavigationView, and DayView being set to static resources which I couldn't find anywhere in the project:

  • Line 26: Style="{StaticResource DefaultCalendarViewStyle}"
  • Line 34: Style="{StaticResource DefaultNavigationViewStyle}"
  • Line 58: Style="{StaticResource DefaultDayViewStyle}"

Either remove these lines or define the resources somewhere in a parent view, such as in the ContentPage:

<ContentPage.Resources>
    <Style x:Key="DefaultCalendarViewStyle" TargetType="{x:Type xcViews:CalendarView}">
        <Setter Property="BackgroundColor" Value="#505050"/>
    </Style>

    <Style x:Key="DefaultNavigationViewStyle" TargetType="{x:Type xcViews:NavigationView}">
        <Setter Property="BackgroundColor" Value="Red"/>
    </Style>

    <Style x:Key="DefaultDayViewStyle" TargetType="{x:Type xcViews:DayView}">
        <Setter Property="CurrentMonthTextColor" Value="Green"/>
    </Style>
</ContentPage.Resources>
View Screenshot

Screenshot_20220923-213143

Thanks for using the plugin!

@sfoslund
Copy link
Author

@ME-MarvinE thanks for your quick and thorough response! I tried removing those lines from the app and I'm still seeing the crash, do you have any further recommendations for debugging this?

@ME-MarvinE ME-MarvinE reopened this Sep 23, 2022
@ME-MarvinE
Copy link
Owner

ME-MarvinE commented Sep 23, 2022

It looks like I reverted my changes to the XAML to the original code but not the ViewModel. Now it only works if you don't remove the lines and define the styles.

If you suspect it is performance related, try to reduce the resources it uses to see if it still crashes.
Set the Calendar's AutoRows property to false
Set the Calendars Rows property to 1
Set the CalendarView's DayTemplate property to just be a simple Label with it's Text bound to DateTime.

If the app doesn't crash, then I don't think I can do anything about performance as I've tried to refine the XAML plenty of times, and may be due to MAUI issues such as:

dotnet/maui#6317
dotnet/maui#7237

If the app still crashes, then it probably isn't performance related, though you could go further by binding the Days property to a collection with only one day in it instead of using the Days property of the Calendar.

For debugging, what I do is:

  • Try removing properties until the app doesn't crash.
  • There are default values for the content of CalendarView's template properties internally. Try setting them to simple controls like a Label to see if it's something wrong with templating or one of the default controls.
  • The CalendarView is made up of default controls: NavigationView, DaysView, and DayView (There is no control for DayNames). Try using them on their own to try to isolate the issue to a smaller scope with less code to test.
  • Try using a Calendar with the default class CalendarDay as a generic parameter instead of your custom type.

@ME-MarvinE
Copy link
Owner

ME-MarvinE commented Sep 23, 2022

@sfoslund I missed some style references in ViewHabitsView:

Line 26: Style="{StaticResource DefaultCalendarViewStyle}"
Line 34: Style="{StaticResource DefaultNavigationViewStyle}"
Line 54: Style="{StaticResource DefaultDayViewStyle}"

If you haven't already, try removing those lines along with the ones previously mentioned:

* Line 26: `Style="{StaticResource DefaultCalendarViewStyle}"`

* Line 34: `Style="{StaticResource DefaultNavigationViewStyle}"`

* Line 58: `Style="{StaticResource DefaultDayViewStyle}"`

There were no crashes after I did that.

@sfoslund
Copy link
Author

Now it only works if you don't remove the lines and define the styles.

I've tried defining the styles as well and that also doesn't make a difference for me.

I used VS's FindAll with 'solution' scope to find lines where I missed the undefined style references.

Yes, I noticed those as well and removed them in my original testing.

Thanks for those debugging tips! I will likely take a break from this project for a while and come back to it in a few weeks, but once I do I will update here if I find the issue.

atamietti added a commit to atamietti/XCalendar that referenced this issue Mar 17, 2023
ME-MarvinE#67 Calendar view in maui causes crash on physical android device bug Something isn't workinggood first issue
ME-MarvinE#64 upgrading from version 3 to 4 breaks the application awaiting-author Awaiting a respose from the authorquestion
@atamietti
Copy link

Hi Guys, This PR might fix it.

@ME-MarvinE
Copy link
Owner

@sfoslund Have you looked into this recently, are you still experiencing the issue?

@ME-MarvinE ME-MarvinE added the awaiting-author Awaiting a respose from the author label Mar 11, 2024
@JianpingCAI
Copy link

JianpingCAI commented Jun 23, 2024

I've found that it crashes if my .net maui app starts with a device in horizontal screen mode, but it does not crash in vertical screen mode. The issue can be reproduced on multiple Android devices, including physical and Emulators.

@JianpingCAI
Copy link

I've found that it crashes if my .net maui app starts with a device in horizontal screen mode, but it does not crash in vertical screen mode. The issue can be reproduced on multiple Android devices, including physical and Emulators.

It turns out that the above issue is not caused by XCalendar but might be a bug in .net MAUI.
In my xaml file, there is a layout defined as below, where the CalendarView as the last row of the grid takes too much space of the height, which causes the inferred height of the 3rd row to be a very large number (guess it is unsigned integer type), leading to Java.Lang.OutOfMemoryError.

<Grid>
            <Grid.RowDefinitions>
                <RowDefinition Height="auto" />
                <RowDefinition Height="auto" />
                <RowDefinition Height="*" />
                <RowDefinition Height="auto" />
            </Grid.RowDefinitions>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-author Awaiting a respose from the author bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants