Not every app that makes use of the payment service will want or need to display a price to users in the actual app interface. Many apps rely on the payment confirmation window to retrieve the price of the digital good from the BlackBerry World server then display this information to the end user, which is a perfectly acceptable option. If you are creating an application where you have a long list of digital goods and would like to display the prices for these then I have a nice little optimization you are going to be interested in!
Today all calls to the Payment Service must be done sequentially and every call you make to retrieve the price of a digital good follows this pattern:
The key issue with the above process is the inherent latency experienced if trying to retrieve the price of many digital goods at once. Wouldn’t it be great if the Payment Service on the device would just grab all those prices at once and cache them all rather than requiring repeated network calls? Of course it would, and the dev team behind the Payment Service has added a really simple feature to do just that! All that is needed is one minor code (if you’d even call it that) change.
Here’s a quick example using the Cascades PaymentManager calls that shows how a price is retrieved without caching:
As you can see the only change we made was to prepend the SKU with “CACHE:”, that’s all, everything else is handled for you by the system. Similar logic will work across all languages on BlackBerry 10 (HTML5 WebWorks, Native, AIR). Let’s take a look at what the above “code” change has achieved for us in our app:
Now the Payment Server is responding to the Payment Service with the entire list of SKU-price pairs. The Payment Service caches these prices locally then responds back to the client app with just the price requested. All subsequent calls to the SKU price requests will have the values pulled from the Payment Service cache and returned to your application almost instantly:
You just need to make sure that you keep all SKUs prepended with “CACHE:” to make use of the price caching and the Payment Service will handle the rest. The prices will get cached locally for 30 minutes after which they are purged. One other thing to note is that this caching mechanism is not compatible with the Content ID, only the SKU, so if your app is passing the Content ID today you would need to change it over to use the SKU instead.
This feature is very helpful if you know you will be retrieving a bulk of SKU prices all at once, but at the same time this can add some overhead to the call if you only need one price, so be wise in your implementation.
Picture by MTSOFan
