New IAP release / Changes between 0.3.1 and 3.23.7

[derconny]

Hi,

until now I was using IAP 0.3.1. Today I got a comment from the Nokia Store people that I should switch to 3.23.7. I did so and discovered a couple of changes:

• New UI
• Password needs to be entered less often
• My app crashes after a purchase

So my question is: What exactly has changed? Where is the changelog? Have there been other releases in between (quite a jump in version numbers)? Where was the release announced (where will future releases be announced)?

Thanks!
Conny

[symbianyucca]

Not certain on the change log, anyway, I know two things which would help on getting to know what is going wrong in there:
1. Get the panic code for the crash: http://www.developer.nokia.com/Commu...ded_panic_code
2. find out which line of code is causing the crash

[izinin]

Hi

Please describe your application crash: error case scenario , log if available. In 3.23.7 there was defect about request number -- concurrent application client requests were handled incorrectly. But except that there weren't more major issues.

By the way your application will get new IAP Runner because of Smart Installer. Please check new version, this is released today to Smart Installer. SDK download update is coming pretty soon

[derconny]

Hi and sorry for the late reply. I forgot to subscribe to this thread. What is the version of the updated IAP? The smart installer wiki site still only mentions 3.23.7.

[derconny]

Problems I have so far:

1) I'm showing a QML BusyIndicator while loading IAPClient(). After loading it the animation of the busy indicator freezes. On the console I get:
[Qt Message] QAbstractAnimation::resume: Cannot resume an animation that is not paused
Even setting 'running' to true afterwards does not start the animation again.
After testing a bit more it turned out, that tapping the screen enables the animation again. I guess IAPClient() is stealing the focus of the active window or something. Not nice.

2) Running IAPClient() can still take a lot of time. Sometimes its about 2 seconds, but often I have seen more than 6 seconds. Guys, this is a constructor - it should be fast. Once with deactivated Wifi it even hung forever. The next line after the constructor was never reached. It wasn't even possible to quite my app using the task switcher. Only turning the phone off helped.

BTW the original error was that I randomly didn't got data from getProductData(). An extra check helped.

[derconny]

1) I'm showing a QML BusyIndicator while loading IAPClient(). After loading it the animation of the busy indicator freezes. On the console I get:
[Qt Message] QAbstractAnimation::resume: Cannot resume an animation that is not paused
Even setting 'running' to true afterwards does not start the animation again.
After testing a bit more it turned out, that tapping the screen enables the animation again. I guess IAPClient() is stealing the focus of the active window or something. Not nice.

Some more observations: UI-blocking doesn't end as soon as the constructor returns. It blocks the UI a couple of seconds longer. If I send signals from C++ to QML in this time, nothing happens. Instead QML will receive them a couple of seconds later. However if I tap the screen first, the events go through at once. So I think this is not a focus issue but something deeper.

Here is some example code to make my point.

IAPClient *iap = new IAPClient();
emit sendHello();
qDebug() << "C++ signal was send";

Connection {
    target: backend
    onSendHello: console.log("QML signal received")
}

Without tapping the screen the result on the console is:

C++ signal was send
< 3 seconds pause >
QML signal received

With tapping it is:

C++ signal was send
QML signal received

AMAZING

[izinin]

Hi Cornelius

IAP client 3 seconds pause during object construction is due to synchronous socket operation in IAP. That pause duration depends on network conditions. That ...hmmm design is not new in IAP but exists from very first IAP version.

Another related problem arises when you try to purchase a product right after IAP construction. The most of the time i got "Purchasing service unavailable" error message. My workaround was to make request to fetch product metadata (getProduct) first and then purchase product. It seems IAP has some problem with its internal application states.

So finally what i can say -- we have to live with what we have. At least there are some workarounds available : don't use your own busy indicator

By the way if you take Analytic API it suffers from the same problem -- using syncronous operation with sockets that causes UI freezing. I used splash screen , check this https://projects.developer.nokia.com/fifteenpuzzle

[derconny]

Hi izinin,

thanks for your reply.

Hi Cornelius

IAP client 3 seconds pause during object construction is due to synchronous socket operation in IAP. That pause duration depends on network conditions. That ...hmmm design is not new in IAP but exists from very first IAP version.

Yes, I know it is an old problem, but that doesn't fix it Actually I've reported it 4 month ago here: http://projects.developer.nokia.com/iap/ticket/2

The reason I'm writing here is
a) the assumption that an update might have fixed that problem.
b) giving more information in the hope to accelerate a fix or at least to find a workaround

An interesting thing is that the constructor is not purely synchronous. It also creates a huge amount of events that have to be processed by the event loop which also has to process UI stuff. For example try this:

IAPClient *iap = new IAPClient(this);
qDebug() << "ping";
QApplication::processEvents();
qDebug() << "ping";

You will notice a huge delay between the first and the second "ping".

Another related problem arises when you try to purchase a product right after IAP construction. The most of the time i got "Purchasing service unavailable" error message. My workaround was to make request to fetch product metadata (getProduct) first and then purchase product. It seems IAP has some problem with its internal application states.

Thanks for this info. It's actually not a problem I currently have because I'm always doing getProductData() first to show the price. However I share your suspicion that IAP sometimes confuses its internal states. Seen with other wired behaviour.

So finally what i can say -- we have to live with what we have. At least there are some workarounds available : don't use your own busy indicator

I'm not sure what "own busy indicator" means. I'm using the one provided by Symbian Qt Components. Its bad enough to show a frozen busy indicator with the message "please wait". Even worse it would be to show nothing at all.

The situation is actually that bad the Nokia Store QA team failed my last upload because it "freezes after startup". As there is nothing I can do about this I did another upload hoping to get a reviewer who has less strict timing requirements.

By the way if you take Analytic API it suffers from the same problem -- using syncronous operation with sockets that causes UI freezing. I used splash screen , check this https://projects.developer.nokia.com/fifteenpuzzle

That's really comforting to know

Anyways, I know you're not the guy to blame - you just get all the heat here and I appreciate that you're replying here.
So just tell me that the responsible developers know about those problems and that they are doing everything they can to fix them and I will be happy. Make them understand that because of their bad code other developers are suffering.

Thanks,
Cornelius

[izinin]

Hi Cornelius

I've reopened ticket for that bug. Thank you for your comments on that release.

Try to instantiate IAP client on application starting. If it appropriate , display a splash screen and then instantiate IAP -- frozen UI during displaying splash screen is not such noticeable by users.

there is an example for Symbian CServer2 implementation with Qt that serves client application IAP requests. You need project located in "trunk/qt_iap_bridge" directory of the source code. Maybe that solution is too heavy but it will fix the problem completely.

[derconny]

Hi Cornelius

I've reopened ticket for that bug. Thank you for your comments on that release.

Thanks a lot

Try to instantiate IAP client on application starting. If it appropriate , display a splash screen and then instantiate IAP -- frozen UI during displaying splash screen is not such noticeable by users.

I've tried that but it simply takes too long. IAP takes time, Qt Components take time, etc. All in all it sometimes took more than 10s to start. That's too long for my taste. Also IAP is not always needed, only if you buy something new which is not the only use-case.

there is an example for Symbian CServer2 implementation with Qt that serves client application IAP requests. You need project located in "trunk/qt_iap_bridge" directory of the source code. Maybe that solution is too heavy but it will fix the problem completely.

Thank you, I've never heard of that before. I will have a closer look at it.

Cheers,
Cornelius