Some users reported they are not receiving notifications, I believe it's related to "ErrCode 3 - DeviceSubscriptionExpired" since I find out this in the logs (DeviceToken omitted):
ERROR SDAPI.Notifications - SetResult - ErrCode 3 - DeviceSubscriptionExpired - APA91******
What action my program need to take when get this error?
I'm already updating the DeviceToken using NotificationsRegistrationHandler.
Gx 15 U2 C#
The best way to have Push Notifications up and running with GeneXus, is using GeneXus OneSignal implementation.
We recommend to use OneSignal GeneXus implementation instead of 'SDAPi.Notifications'
Take a look here
Related
Is there any pattern for cross-platform error handling in MvvmCross, mainly Android and iOS?
For example:
In the model a call is made to a webservice. The call fails e.g. due to network not available.
Imagine a text input field that my application checks. When it contains abc, everything is fine. Otherwise an error message shall be shown.
How to propagate the error messages for these cases to the view? How to process the error message in the view?
Can someone provide some best practice samples?
Microsoft AppCenter Crashes has native and Xamarin modules for iOS and Android which will allow you to report and view handled and unhandled exceptions.
Polly can be used to handle automatic retry of web requests.
MvvmCross has a logging system that can be connected to NLog, Serilog, etc. to log errors/information to a log file on the device. You can attach the log file to AppCenter Error Report (although it is currently limited to 7MB file attachments)
FluentValidation can be used to validate objects. You could handle the validation in the ViewModel then use a MvvmCross Interaction to pass the validation errors from the ViewModel to the View. I use this approach and call TextInputLayout.SetError() in the Android view to show the error message next to the input field.
I'm using James Montemagno's Plugin.InAppBilling library for Xamarin to do iOS and Android in-app subscriptions. It has worked mostly correctly so far, except that once in a while, on iOS only, InAppBillingPurchase.PurchaseToken comes back null from calls to PurchaseAsync and GetPurchasesAsync.
For example, in my Restore Purchases logic, I have code similar to this:
var purchases = await CrossInAppBilling.Current.GetPurchasesAsync(ItemType.Subscription);
// Sometimes we receive purchases with no PurchaseToken.
// Can't verify the purchase without a token.
var verifiable = purchases.Where(p => !string.IsNullOrWhiteSpace(p.PurchaseToken));
At this point, verifiable sometimes has a different count (0) than purchases (1).
So far, this has seemed to happen when the user purchased using either store credit or a gift card, and only on iOS.
Also, I'm not sure if this bears on the problem, but I am not using the overloads of PurchaseAsync and GetPurchasesAsync which take IInAppBillingVerifyPurchase, because I use server-side verification exclusively (no client-side verification). My workflow is to make the purchase, add the resulting InAppPurchase object to a queue for processing, and then send it to our server as a separate step, for validation and association with the user's account. However, if this is not a valid workflow or if it is known that sometimes PurchaseToken data will be available via IInAppBillingVerifyPurchase.VerifyPurchase but not attached to the InAppBillingPurchase objects returned from the methods above, I would certainly like to know about that. (For what it's worth, I've read the documentation and don't see anything that suggests this.)
Thanks in advance for any help.
Okay, I think I've learned enough to provide useful information for anyone else dealing with this issue.
First, I've figured out what Apple means by "iOS 6 style" and "iOS 7 style" receipts. These do not refer to the version of iOS that creates the receipts. (My up-to-date iOS 12 device still can and does generate "iOS 6 style" receipts.) Instead, these refer to two different receipt formats that were introduced in the respective iOS versions.
iOS 6 style receipts come from SKPaymentTransaction.transactionReceipt and contain information about one specific transaction. This field is now deprecated by Apple.
iOS 7 style receipts come from the app bundle, via the location named in NSBundle.mainBundle.appStoreReceiptUrl. These receipts contain a full manifest of all purchases ever made by the user. The receipts don't expire either -- you can always send them to Apple for validation (though, obviously, individual transactions contained within might show as expired in the response). These are the receipts you should prefer.
The reason this is important is that if you're using the Plugin.InAppBilling library, the InAppBillingPurchase object you get from calling something like PurchaseAsync contains the deprecated iOS 6 style receipt in its PurchaseToken field.
I'm still not sure why it is sometimes present and sometimes null, but seeing as the underlying source of the data is deprecated, it's probably safe to assume that this can and will happen. Therefore, it probably makes sense to cut over to the iOS 7 style receipts as soon as possible.
Note that when you call PurchaseAsync, if you specify an implementation of IInAppBillingVerifyPurchase, your IInAppBillingVerifyPurchase.VerifyPurchase method will receive the newer iOS7 receipt instead. However, the InAppBillingPurchase object returned by PurchaseAsync still gets an iOS 6 style receipt (if it gets anything at all).
Personally, I like the InAppBillingPurchase object itself. It has useful information packed into a convenient package. Since I want to keep the serialized InAppBillingPurchase objects in a queue so that I can retry validation if there are problems with our servers, connectivity, etc, what I'm doing is immediately replacing the PurchaseToken property with the iOS 7 style receipt that I manually retrieve from the bundle.
If you do this, be sure that your code handles the slightly different formats of the iOS 6 and iOS 7 receipts properly. (Our earlier attempts had some errors stemming from not properly understanding what these terms meant.)
I hope this is useful to someone out there. Good luck!
How can i send custom error report from Xamarin forms application to Hockey?
I am able to get crash reports through hockey sdk integration. I want to handle exceptions and send custom messages
to hockey.
I tried sending reports by this way.
HockeyApp.BITHockeyManager.SharedHockeyManager?.MetricsManager?.TrackEvent("custom error report");
I enabled hockey in app delegate in this way
var hocMgr = BITHockeyManager.SharedHockeyManager;
hocMgr.Configure("appKey");
hocMgr.DisableUpdateManager = true;
hocMgr.StartManager();
hocMgr.Authenticator.AuthenticateInstallation();
You can't just yet (see this recent link from support). HockeyApp is primarily designed for 'hard crashes' and not for event tracking or custom Exception handling. Besides the beta distribution and feedback of course.
With the merge of Xamarin Insights this will come, but it will take some time!
Custom event tracking is in the preseason already. But you'll have to be accepted in the program first.
I'm using the Xtify plug in through Application Craft.
After looking at Xtify's help page: http://developer.xtify.com/display/sdk/PhoneGap+Cordova+for+iOS+Xtify+Integration+Guide
at the section: To Manage the Badge Count
I found a set of functions to control the Badge Number.
But it is not clear from these functions, how can I deduct the Badge Counter by one, after the user reads one of the received notifications. For the moment I can only completely clear all notifications from the Tray (and the Badge Counter disappears).
But if the user has received 4 unread notifications, the badge counter is set to 4.
Then if the user reads one of these notifications, the badge counter is still stuck to "4".
I want to simply reduce the counter by one and remove only that "read" notication from the tray and not ALL notifications.
Any help would be really appreciated.
There are set/get badge javascript methods that will set and get the native iOS badge counts. However, this will only work if the Xtify native objective C plugin class is included in the application craft platform and compiled with the application. The javascript functions interact with the underlying Xtify xCode/obj-c functions.
That would be step 9-14 on this page:
http://developer.xtify.com/display/sdk/PhoneGap+Cordova+for+iOS+Xtify+Integration+Guide
Likely you will have to contact AC directly to support the Xtify native phonegap cordova plugin.
Is anyone now online able to perform receipt validation in a Mac application?
Have you used the ASN generated files in the application?
Are you able to produce a sample receipt by automatic popup of the iTunes authentication?
The best way I know to check receipts is by letting Receigen generate the code - different for each new version. It's probably more secure than what you can develop in a reasonable time.
I have it working, but i am using open source code to do it.
Using this code in your main , and changing your app bundleID/version, it validates the receipt.
In this question you can see the code i used.
Mac App Store Receipt Validation Code?
I've got an example receipt at my question here (Can Purely On-Device In-App Purchase Receipt Validation Be Done With iOS6?). I've generated the ASN files and am trying to use them now. I used the compiler here. I'm not sure if it all works though, just starting testing in earnest now.
Chris.