BUG: 'Read In App Purchase Information' blueprint node never fires delegates if connection fails on iOS

Hey guys,

So in our level blueprint’s BeginPlay I am fetching the IAP data from the server.

It looks like the following:

In most cases this works correctly, but if we lack an internet connection (Airplane Mode) The ‘On Failure’ node never fires. (neither does the ‘On Success’)

I found that the OnlineStoreInterface on iOS doesn’t have the request:didFailWithError: delegate function implemented, so we don’t handle any native errors. So below is my implementation of it:

// Engine\Source\Runtime\Online\IOS\OnlineSubsystemIOS\Private\OnlineStoreInterfaceIOS.cpp
- (void)request:(SKRequest *)request didFailWithError:(NSError *)error
{
	if (error != nil)
		UE_LOG(LogOnline, Verbose, TEXT("request - didFailWithError: %s"), [[[error userInfo] objectForKey:@"NSLocalizedDescription"] UTF8String]);

	if ([Request isKindOfClass : [SKProductsRequest class]])
	{
		// Direct the response back to the store interface
		[FIOSAsyncTask CreateTaskWithBlock : ^ bool(void)
		{
			IOnlineSubsystem* OnlineSub = IOnlineSubsystem::Get(FName(TEXT("IOS")));
			FOnlineStoreInterfaceIOS* StoreInterface = (FOnlineStoreInterfaceIOS*)OnlineSub->GetStoreInterface().Get();

			StoreInterface->TriggerOnQueryForAvailablePurchasesCompleteDelegates( false );
			return true;
		}];
	}
}

Hope that helps. :slight_smile:

EDIT: I just came across a bug with the snippet I provided. bIsProductRequestInFlight never gets set to false, so any further queries always fail and never fire their nodes correctly.

I ended up adding a helper function to FOnlineStoreInterfaceIOS:

void ClearProductRequestFlag() { bIsProductRequestInFlight = false; }

And I then call this after I trigger the delegate:

StoreInterface->TriggerOnQueryForAvailablePurchasesCompleteDelegates( false );
StoreInterface->ClearProductRequestFlag();

Hey ,

Could you please include your iOS from your device? Please include them as a .txt file format. Also include other types of devices that you’ve tested. When I tested this blueprint example out on an , I did not run into the same issue that you’re describing.

Find the relevant log [HERE][1].
I have confirmed this happening on the following: iOS 8.1.1 (12B436) on an iPad Air 2, iOS 8.4.1 (12H321) on an iPad Gen 2, 9.2 (13C75) on a iPhone 6S.

I can test other devices if needed, but it’s a matter of the current code not handling native errors correctly, so this should be happening across the board.

74358-output.txt (64.5 KB)

I am getting the fail node to fire each time I attempt this. I have tested on an OS version 8.0, an iPhone 5 OS version 8.1 and the OS version 9.2. I am testing this out with your blueprint, not your code.

I did do some additional investigation and I saw that you’ve been able to get around this issue by using the code included at the bottom of your original post?

Is there anything specific that you’re doing that I may not be doing when you’re testing this out? At this time, I am unable to bug anything with a possible fix due to not being able to reproduce the issue.

Thank you!

So I’m attaching a sample project [here][1] in which I was able to reproduce the issue.

It’s possible you didn’t have IAP enabled correctly, as in the engine’s IOSEngine.ini the setting has been misspelled.

It should be:

[OnlineSubsystemIOS.Store]
bSupportsInAppPurchasing=True

NOT:

[OnlineSubsystemIOS.Store]
bSupportInAppPurchasing=True

I forgot to bug this when I found it a while back.

Also make sure you are sending valid ID’s to the server.

Other than that, in the example you should be able to just turn on airplane mode and it should hang on the loading screen.

All the blueprint code is in the level blueprint.

Cheers.

EDIT: The sample project is using 10.0.2 downloaded from the launcher.

74539-iaptest410.zip (375 KB)

Hey,

Thank you for informing me of the typo, I wasn’t aware nor did I find that as a bug in . Good news is that the IOSEngine.ini file has already been corrected in 4.11 Preview 2.

I have submitted UE-25561 to . We will update this thread when this bug has been worked on by a developer.