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.
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!
I am working on Firefox Addon development, I have successfully built the addon, but it is giving me validation error on submission as "Warning: Your add-on uses an interface which bypasses the high-level protections of the add-on SDK. This interface should be avoided, and its use may significantly complicate your review process." on these lines.
const { Cc, Ci } = require("chrome"),
nsIIOService = Cc["#mozilla.org/network/io-service;1"].getService(Ci.nsIIOService),
nsIStyleSheetService = Cc["#mozilla.org/content/style-sheet-service;1"].getService(Ci.nsIStyleSheetService);
I am able run the addon on my machine, but couldn't submit due to this flagged validation check.
Is there any alternative way?
It is completely acceptable to use that. There is not alternative to some APIs in the SDK. That validation is a warning because those features are not frozen and can change at anytime. Can you post a screenshot of the validation blocking your submission? It should be allowed through.
While not entirely identical in function to nsIStyleSheetService, sdk addons can use page-mod to inject stylesheets into some or all content pages.
I tried to run the Marketplace Test Kit and it failed at Capability Validation with a bunch of calls that Microsoft.Advertising.Mobile.dll was trying to make. This is understandable, but in no instance am I attempting to update the AdControl from the BackgroundAgent. The closest thing I can think of is in this:
public ScheduledAgent()
{
if (!_classInitialized)
{
_classInitialized = true;
// Subscribe to the managed exception handler
Deployment.Current.Dispatcher.BeginInvoke(delegate
{
Application.Current.UnhandledException += ScheduledAgent_UnhandledException;
});
}
}
Is the Application.Current call what is trying to engage the ad control? If so, how can I prevent it from doing so?
Edit: here is the output of one of the error messages:
Unsupported API cannot be used by a background agent. Assembly Microsoft.Advertising.Mobile.dll was trying to use Microsoft.Phone.Tasks.PhoneCallTask::.ctor.
Okay, it wasn't related to the code sample at all. What was the issue is that I was generating my ad controls via a Windows Phone Library I created. This library's Models were being used by the background agent and this apparently made the test kit believe the application was using the Ad logic somehow.
I removed the Ads.cs and migrated the things it was doing into the pages themselves and this resolved the issue.
edit: I think it is safer to say that it wasn't the Marketplace Test Kit thinking that the background agent was using the AdControl's library, but rather it had the ability to do so. I figure that is worth distinguishing.
The Wp7 marketplace result pdf shows in summary "Exception(s) Applied: None". What does this mean. Should I write code to handle unhandled exceptions Or what I am doing is right.
The App is not rejected due to this, but I want to know what this means.
Thanks,
Kanaya
It means that you have not applied for any technical exceptions. These are a request for your application to not be tested against certain market place policy criteria. You can see some details about this on the Certification section of the FAQ (Under sections 3 and 4) as well as how to apply for exceptions.