This issue still isn't resolved - can you provide guidance please.
That's effectively what I did to get it to run; however it would be nice to understand why SecureStorage doesn't work in a clean ABP suite generated application (8.2.2)
#define USE_PREFERENCES
using Volo.Abp.DependencyInjection;
namespace BrightServe.Maui.Shared.Storage;
public class DefaultStorage : IStorage, ITransientDependency
{
public async Task<string> GetAsync(string key)
{
#if USE_PREFERENCES
return Preferences.Get(key, string.Empty);
#else
return await SecureStorage.Default.GetAsync(key);
#endif
}
public async Task SetAsync(string key, string value)
{
if (value.IsNullOrEmpty())
{
await RemoveAsync(key);
return;
}
#if USE_PREFERENCES
Preferences.Set(key, value);
#else
await SecureStorage.Default.SetAsync(key, value);
#endif
}
public Task RemoveAsync(string key)
{
#if USE_PREFERENCES
Preferences.Remove(key);
#else
SecureStorage.Default.Remove(key);
#endif
return Task.CompletedTask;
}
}
As for the use of AsyncHelpers.RunSync
my experience is that when being called frequently (especially from methods that themselves are async) a deadlock can result. I've had this a few times both using .Result and my own code which was almost identical to what AsyncHelper.RunSync
does (see https://github.com/aspnet/AspNetIdentity/blob/main/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs); however I don't think that this the cause of this problem.
Using AsyncHelper.RunAsync is possibly not a good idea as I think it could lead to deadlocks; however I cannot prove that this is happening.
The last comment in the thread https://abp.io/support/questions/6409/Mobile-MAUI-Android-Release-build-stuck-on-splash said "we'll update the template according to this information, thanks for this key point" and yet 8 months later GetClaimsPrincipal still isn't async.
After much debugging and experimentation it appears that SecureStorage is the problem; if I change the DefaultStorage.cs module to use SecureStorage instead of Preferences then the debug app also locks up; not sure why but possibly because it is called too early in the startup sequence or maybe because it is called from GetClaimsPrincipal which is not an async method and using AsyncHelper.RunSync(() =>
is probably not a safe way of using an async method.
I think it is therefore sensible to change GetClaimsPrincipal to be async.
I've tried on different Android versions, API 27 and API 30
we already tried that; in our LabMauiModule we #define DEBUG at the top
So I don't think this is the fixed
I will investigate this thanks for the link