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.
Related
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'm using DotNetKit 1.2.6.5 and SagePayIntegration.Validation() is rejecting a customer email that uses the new .online domain (eg: foo#bar.online) with
CustomerEMail is invalid.
Is this fixed in 1.2.6.7 or is the source code for SagePay.IntegrationKit.DotNet.dll available somewhere so I can fix it?
Despite access to the source code (many thanks to #DavidG) SagePay Support have confirmed that the actual Gateway does not support all these new domains - so even if I modified the DotNetKit it would still be rejected by the Gateway.
SagePay support were very helpful but ultimately the
"... email domain foo#bar.online is not yet supported on our gateway.
We run development sprints continuously and although there are some
domains we may not yet support, we look to in future, dependent on
impact and demand..."
The SagePay Integration Kit uses this regex to validate email addresses:
[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*#(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+(?:[a-zA-Z]{2,4})\b
Which does unfortunately not allow extra long TLDs. Fortunately I have the source code for the kit and I've added it to my GitHub account (along with a bug fix which is why I had to get it in the first place as SagePay are not updating it). You can find it here:
https://github.com/WiredUK/SagePay.IntegrationKit
And the Regex you need to edit is this file:
https://github.com/WiredUK/SagePay.IntegrationKit/blob/801f61cf965c391a98a025aa632949719084cef0/ApiRegex.cs
For info, you need to edit the very last part of the expression from 2,4 (which matches 2 to 4 characters in the TLD) to allow more, for example 2,30.
Edit: And just because I can, I opened an issue and fixed it.
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've tried to compile .NET project and this CA appears, however I can't find any information about it on MSDN, do you know how to fix it?
The documentation can be found here:
https://msdn.microsoft.com/en-us/library/dn621098.aspx
Rule Description
To use security critical types, the code that references the type must be either security critical or security safe critical. This is true even if the reference is indirect. For example, when you reference a transparent field that has a critical type, your code must be either security critical or security safe. Therefore, having a security transparent or security safe critical field is misleading because transparent code will still be unable to access the field.
How to Fix Violations
To fix a violation of this rule, mark the field with the SecurityCriticalAttribute attribute, or make the type that is referenced by the field with security transparent or safe critical.
In the Error List you can click the underlines CA2151 link or right click the line and select Show Error Help. Both actions will launch the MSDN overview of code analysis violations. From here you can find a link to the description of CA2151 and how to fix it.
I tried publish my app: http://pomidoro.codeplex.com/ on Windows Store and certification failed because:
'Your app doesn't meet requirement 1.1.
Comment from tester: This app didn't appear to provide value or didn't seem useful to the reviewer.'
Is that means that I do not have any chances to publish it anymore?
No, you can make some tweaks and publish again. Here are some thoughts:
It may be an issue of marketing, and modifying the description that you submit with your application will fix the issue. Your description at http://pomidoro.codeplex.com is pretty good, but maybe you could add some data around how it helps you work more efficiently in case the reviewers aren't familiar with Pomodoro. There are tips on writing a good description/app listing here.
Otherwise, you could add some extra features to the app so it's more than just a timer. Can the user record their whole To Do list in the app, and then choose what to focus on during the pomodoro from that? Or, allow them to rank each pomodoro as effective/not effective after the timer goes off and keep historical data so they can see what times of day they are most effective? And so on...
Here is the first post in a blog post series on common certification failures for the Windows Store and how to fix them which might also be useful.
Good luck!