object null reference

[codingL3gend]

Messaging.SharedInstance is null during initialization on iOS in FirebaseCloudMessagingImplementation.RegisterForRemoteNotifications() method. this causes the application to crash and terminate during startup. looking through the library, there are some places where it would benefit from having some try catches to prevent such issues since i do not think these will bubble up into the host application for them to be caught. i tried a few ways to catch it but was not able to so far.

[TobiasBuchholz]

What did you try? Actually it shouldn't be a problem to catch such an exception.

[codingL3gend]

i tried wrapping both of the below individually in a try catch but neither caught the exception. instead once the null pointer is thrown for Messaging.SharedInstance.Delegate = this in FirebaseCloudMessagingImplementation.RegisterForRemoteNotifications because Messaging.SharedInstance is null the app just terminates

events.AddiOS( iOS => iOS.FinishedLaunching( (app, launchOptions) => { CrossFirebase.Initialize( app, launchOptions, CreateCrossFirebaseSettings() ); return false; } ) );

builder.ConfigureLifecycleEvents(events => {

[TobiasBuchholz]

For me the exception gets caught when I'm using the try catch like the following:

events.AddiOS(iOS => iOS.FinishedLaunching((app, launchOptions) => {
    try {
        CrossFirebase.Initialize(app, launchOptions, CreateCrossFirebaseSettings());
    } catch(Exception e) {
        Console.WriteLine("Exception caught - app doesn'nt crash");
    }
    return false;
}));

[codingL3gend]

ok you put yours in a different location. i didnt try to wrap it around the CrossFirebase.Initialize(), will try that.

I am still curious though as to why not put this kind of error handling null checking in the library around objects that can potentially be null?

also in what instances would the Messaging.SharedInstance be null? seems something might be awry with the startup/initialization process in the actual Firebase lib?

[TobiasBuchholz]

If everything is setup correctly, Messaging.SharedInstance is never supposed to be null, so that's why there is no null check, because in this case a crash is the most obvious way to tell the developer there is something wrong.

[codingL3gend]

hmm still think there shouldn't ever be an assumption that something that can be null won't ever be null and to not properly handle it and provide a good error reason to the user. but anyway, it was working before and there were no changes to my project outside of package upgrades so im curious why this started happening. there isn't much insight provided as to why the Messaging.SharedInstance doesn't get properly initialized in order for someone to know what to look into to correct the issue.

this issue is happening with both the community intermediate package version 1.2.6 and the most recent version of this lib 1.3.0. i even pulled down the raw code project and still seeing the same issue.

i guess i'll keep digging to find a solution

[TobiasBuchholz]

Since I haven't heard from you in more than 30 days, I hope this issue is no longer affecting you. If it is, please reopen this issue and provide a sample project so that I can look into it further. Thank you!