I have a strange issue for creating a push notification channel uri.
When I try to execute the following code:
receivedChannel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
I catch an exception with the following message:
A notification channel request for the provided application identifier is in progress. (Exception from HRESULT: 0x803E0103)
(nothing special in the call stack)
The problem appeared suddenly while it worked fine.
I tried to restart my phone without success.
Note: I have this issue only on my development mobile. It works fine on others mobiles.
It's properbly not relevant any more, but I had a support call earlier this year with Microsoft. This kind of error message is actually due to an error in the whole push notification framework. The problem has been resolved in the Fall Creator's update released on October 17th, 2017. As a matter of fact I have not encountered the error since then on any of the ~500 devices in my domain.
So, error resolution: Update your device. Hope that helps.
Related
Looking for some clarification as to how one can log caught exceptions using flutter's firebase_crashlytics package.
If I understand correctly (and from running some sample code) Crashlytics.instance.log('text'); will only add logs to the next crash report, rather than send off a non-fatal issue itself.
I'm looking for functionality which is equivalent to Crashlytics.logException(e); on Android, e.g.
try {
throwException();
} catch (e) {
Crashlytics.logException(e);
}
which allows you to log caught exceptions so they appear as non-fatal issues in the Crashlytics dashboard.
Is this currently possible with flutter's firebase_crashlytics package?
Is calling Crashlytics.instance.recordError('text', StackTrace.current) the way to achieve this for now?
Many thanks!
Short answer, yes.
Crashlytics.instance.recordError() is the equivalent of Crashlytics.logException()
If you dig into the Flutter firebase_crashlytics source code, you can actually see what Android APIs are involved.
Flutter’s recordError() invokes the method Crashlytics#onError in the Android library.
And tracing Crashlytics#onError, you’ll see that it goes to Crashlytics.logException(exception);
Additional note, you’ll also notice why Crashlytics.instance.log() ”will only add logs to the next crash report”. These logs are added to a ListQueue<String> _logs which is then packaged into the next call of recordError()
A snippet of Flutter’s invocation of Crashlytics.logException():
_recordError(...) {
...
final String result = await channel
.invokeMethod<String>('Crashlytics#onError', <String, dynamic>{
'exception': "${exception.toString()}",
'context': '$context',
'information': _information,
'stackTraceElements': stackTraceElements,
'logs': _logs.toList(),
'keys': _prepareKeys(),
});
}
And some reference notes for Crashlytics.logException():
To reduce your users’ network traffic, Crashlytics batches logged
exceptions together and sends them the next time the app launches.
For any individual app session, only the most recent 8 logged
exceptions are stored.
To add to the accepted answer, Crashlytics.instance.recordError() has now been deprecated for the new method FirebaseCrashlytics.instance.recordError(exception, stack).
BONUS TIP:
I had this problem where all the logged exceptions are grouped under the same issue in Crashlytics dashboard. These might be different crashes of the same or different code components. Due to this, I had to manually go through each instance of the crash to verify.
From my own testing, I found out the grouping is based on the top-most line in the stack trace you passed into the method above. Luckily, Dart has an easy way to get the current stack trace using StackTrace.current.
So to properly group the issues: get the current stack trace at the time of the exception and pass it in FirebaseCrashlytics.instance.recordError(exception, stack).
Hope this helps someone out there, I looked everywhere on the internet for a similar issue but can't find any.
I came across an error message when running Corda Enterprise. I was able to solve the error. But the link at the end of the error message caught my attention.
[ERROR] 16:28:02+0000 [main] internal.NodeStartupLogging.invoke - Exception during node startup: certificate key must be an instance of java.security.interfaces.RSAPrivateKey or sun.security.mscapi.RSAPrivateKey [errorCode=fnu1lw, moreInformationAt=https://errors.corda.net/ENT/4.0/fnu1lw]
This link is linked to a page that needs a login. And errors.corda.net is a dead link, too. What is the logic behind this link?
When an error occurs, the link that you see will do one of the followings:
try to find a Stack Overflow post that specifically answer to the error code (it is the fnu1lw in your case) and redirect to the page.
take you to the enterprise support site when it can't find a S/O post that is specific to the error code (as it was assumed that Enterprise customers would have a support contract).
Since you are running Corda Enterprise, so it takes you to the login page of Corda enterprise support.
Failed biometric(fingerprint) scan attempts are handled by OnAuthenticationFailed() callback of BiometricPrompt.AuthenticationCallback class.
The behavior I noticed is, it lets the user attempt 5 invalid fingerprint scans (each time the fail callback is invoked) and then the prompt dismisses. Within the next 30 secs, if we try to re-build a BiometricPrompt instance and try to authenticate, it does not show the prompt which I think is the default behavior of BiometricPrompt.
Is there anyway to check if the biometric scanner is available and initialised if the user attempts to re-invoke biometric prompt within the said 30secs?
How can I handle that use case?
xamarin android BiometricPrompt.AuthenticationCallback does not have an override method "onAuthenticationError" to handle error callbacks and thus I'm unable to handle error code "BIOMETRIC_ERROR_TIMEOUT".
If someone has a solution for this, please do let me know your resolution.
I believe that BiometricPrompt is not fully ported to Xamarin yet...
I'm still looking for a source that can double check this info for me, but I haven't found it either.
I would like to configure Push notifications for a Xamarin Forms Windows 8.1 Silverlight project. Originally I was using MPNS but am attempting to switch over to WNS. Switching over I am now running into an error when I am attempting to call the method to register my device to Azures notification hub.
The line im calling that throws the error is:
await App.MobileService.GetPush().RegisterAsync(channel.Uri);
and the error thrown is:
The type name 'MobileService' does not exist in the type 'App'
I have the NuGet package Microsoft.WindowsAzure.MobileServices installed but apparently this doesn't contain the definition.
I am following the following guide to setup my push notifications (Under the section "Add push notifications to your app"):
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-windows-store-dotnet-get-started-push/
I've also looked up how to do this on other sites and I don't see much difference to the instructions, nor do I see what I might be missing...
Anyhow if anyone has any ideas what package or reference I might be missing (or what else might be wrong with that call) I'd appreciate the help! Thanks!
In case anyone runs into this issue I solved this problem adding:
public static MobileServiceClient MobileService = new MobileServiceClient(Utilities.Constants.ApplicationURL, Utilities.Constants.ApplicationKey);
and updating my call like so:
await MobileService.GetPush().RegisterNativeAsync(channelUri);
Hope this helps!
Does anybody know what happened with event-listener for location changed for WI-FI provider. I saw a lot of questions about this but no proper answer.
I'm doing everything fine and it is working for older versions of android, but now I updated my SAMSUNG GALAXY TAB 10.1 to ICS and it is not working anymore. Maybe this is a SAMSUNG (or my mobile provider) bug when they implemented their UI into ICS...
I'm registering eventlistener like this (have in mind that it works good in prevous versions of android and I also enabled all location services in settings):
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, loclistener);
//refresh time and distance are to 0 so it should trigger location change event
After this request I checked if network provider is enabled and it shows like it is.
Code:
if (locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER)) {
Toast.makeText(this, "NETWORK PROVIDER enabled!", Toast.LENGTH_LONG).show();
}
If someone has an idea please help me...
This is known issue:
After device reboot the network location provider works fine but after some time it stops updating.
https://code.google.com/p/android/issues/detail?id=57707
Unfortunately without solution yet.
To track how often the network provider is updating, I modified the onLocationChanged() method to the following:
public void onLocationChanged(Location location) {
dummyText.setText(location.toString() + "\n" + "Elapsed Time (ms): " + (lastTime - location.getTime()));
lastTime = location.getTime();
}
And added:
long lastTime = 0;
...as a global variable.
This will print out the time between updates in milliseconds (after the first fix - first fix will just print the negative time value from the first Location).
I ran the above code on my Samsung Galaxy S3, and the network provider updates around every 20 seconds, so the code seems fine.
I also ran this on a Samsung Dart (from T-mobile, but not activated) on WiFi, and the network provider updates around every 45 seconds.
I also ran this on a Samsung Nexus S 4G (from Sprint, but not activated) on WiFi, and the network provider at first didn't update at all. Restarting the device seemed to fix the problem, and now its updating roughly every 20 seconds.
Based on your comments and my experience, it looks like this issue varies between OEMs and even between device models of the same OEM. It might be another quirk of the lack of the strict enforcement of LocationListener behavior prior to Android Jelly Bean 4.1. Strict enforcement of LocationListener behavior only recently started in Android Jelly Bean 4.1, which is mentioned in the Android developer docs here in under the first requestLocationUpdates method signature:
http://developer.android.com/reference/android/location/LocationManager.html
Prior to Jellybean, the minTime parameter was only a hint, and some location provider implementations ignored it. From Jellybean and onwards it is mandatory for Android compatible devices to observe both the minTime and minDistance parameters.
Also, from my experience, the refresh interval of the NETWORK_PROVIDER location updates on devices that do update is pretty fixed at around 20-30 seconds across many different devices. So, the minTime parameter you pass into the locationManager.requestLocationUpdates() method is likely to be ignored.
Having to reboot the device to get a network provider location is likely due to not getting a response from the Google server that provides this location info. Not sure why rebooting fixes it.
I had the same problem with the NETWORK_PROVIDER. The reason is that when you request for updates, the NETWORK_PROVIDER does not create a callback for the method onLocationChanged(). You also need to call getLastKnownLocation(NETWORK_PROVIDER) in order for it to start updating the location.
The weird thing is that for the GPS_PROVIDER this is not neccessary.
I hope this helps.
Ok. So now I got it working. It is really strange. I restarted all my devices and now it updates. I don't know what happened and I would really like to know what is the reason for this strange behavior. Thank you #barbeau for all your time and help.