What is "Silent" upgrade with MobileShop? | developer.brewmp.com What is "Silent" upgrade with MobileShop? | developer.brewmp.com

Developer

What is "Silent" upgrade with MobileShop?

Forums:

What is the difference between standard CheckUpgrade via mshop and Silent upgrade?
Could anybody provide an example of usage? some code fragment..etc

Thanks in advance!

"upgradecheck" invokes mShop/MobileShop as a foreground application at the upgrade page for the specified application. This URI is supported in all versions of MobileShop/mShop. "silentupgradecheck" is new for mShop and permits the application to query for the existence of an upgrade without yielding control (suspending).
The idea is that an application can use this to "silently" check for its own upgrade. If it gets the "Upgrade available" status result then it calls again with an UpgradeCheck message to allow the user to action the upgrade. This allows the calling application to provide its own UI to tell the user about available upgrades, and avoids the user being spuriously taken into T-Shop when there is in fact no upgrade to be had.
The SilentUpgradeCheck URL returns status asynchronously to the invoking application by itself invoking a URL. This second URL is specific to the invoking application. In other words the invoking application must register itself as the handler of a certain category of URLs. The SilentUpgradeCheck URL must contain this return URL.
For example if the application "MyApp" with item id 12345 wants to make silent upgrade checks, it must register a unique URL protocol tag (e.g. myapp:). It then invokes the following URL:
cmshop:SilentUpgradeCheck=12345&url=myapp%3AUpgradeAvailable%3D%25d
The second parameter, which is itself a URL, must be URL-encoded as shown above. The unencoded version of the above example is myapp:UpgradeAvailable=%d.
MShop handles this request in the background without visibly starting up, searching for upgrades to the specified application ID (12345 in this example). When it gets the result back, it encodes it according to the following table.
Check failed: 0
Upgrade available: 1
No upgrade available: 2
Suppose that the check succeeds but there is no upgrade available. MShop replaces the %d in the passed URL with the numeric code 2 from the table above. It then invokes the resulting URL - myapp:UpgradeAvailable=2. It is the responsibility of the invoking application to decide how to react to this information. Apart from the processing of %d, mShop places no interpretation on the contents of this URL.

"upgradecheck" invokes mShop/MobileShop as a foreground application at the upgrade page for the specified application. This URI is supported in all versions of MobileShop/mShop. "silentupgradecheck" is new for mShop and permits the application to query for the existence of an upgrade without yielding control (suspending).
The idea is that an application can use this to "silently" check for its own upgrade. If it gets the "Upgrade available" status result then it calls again with an UpgradeCheck message to allow the user to action the upgrade. This allows the calling application to provide its own UI to tell the user about available upgrades, and avoids the user being spuriously taken into T-Shop when there is in fact no upgrade to be had.
The SilentUpgradeCheck URL returns status asynchronously to the invoking application by itself invoking a URL. This second URL is specific to the invoking application. In other words the invoking application must register itself as the handler of a certain category of URLs. The SilentUpgradeCheck URL must contain this return URL.
For example if the application "MyApp" with item id 12345 wants to make silent upgrade checks, it must register a unique URL protocol tag (e.g. myapp:). It then invokes the following URL:
cmshop:SilentUpgradeCheck=12345&url=myapp%3AUpgradeAvailable%3D%25d
The second parameter, which is itself a URL, must be URL-encoded as shown above. The unencoded version of the above example is myapp:UpgradeAvailable=%d.
MShop handles this request in the background without visibly starting up, searching for upgrades to the specified application ID (12345 in this example). When it gets the result back, it encodes it according to the following table.
Check failed: 0
Upgrade available: 1
No upgrade available: 2
Suppose that the check succeeds but there is no upgrade available. MShop replaces the %d in the passed URL with the numeric code 2 from the table above. It then invokes the resulting URL - myapp:UpgradeAvailable=2. It is the responsibility of the invoking application to decide how to react to this information. Apart from the processing of %d, mShop places no interpretation on the contents of this URL.

Hi Max,
What's the minimum mshop version that supports SilentUpgradeCheck?
Is there any way to check (in code) whether SilentUpgradeCheck is supported by mshop?
Thanks!
Jian

Hi Max,
What's the minimum mshop version that supports SilentUpgradeCheck?
Is there any way to check (in code) whether SilentUpgradeCheck is supported by mshop?
Thanks!
Jian

All versions of mShop support silentupgradecheck. Note that mShop and MobileShop are discrete products.

All versions of mShop support silentupgradecheck. Note that mShop and MobileShop are discrete products.

Hi Max,
Thanks for the quick response.
Could you elaborate on "mShop and mobile shop are two discrete products" part?
If I use ISHELL_BrowseURL("cmshop:SilentUpgradeCheck..."), it should work on all BREW devices that has a mobile shop installed. Is this understanding correct?
Thanks,
Jian

Hi Max,
Thanks for the quick response.
Could you elaborate on "mShop and mobile shop are two discrete products" part?
If I use ISHELL_BrowseURL("cmshop:SilentUpgradeCheck..."), it should work on all BREW devices that has a mobile shop installed. Is this understanding correct?
Thanks,
Jian

No. mShop and MobileShop are not the same product. You must have mShop on the device to leverage the silentupgradecheck functionality.

No. mShop and MobileShop are not the same product. You must have mShop on the device to leverage the silentupgradecheck functionality.

Hmm, then the next question is - how do I check whether mshop is installed on the device?
Thanks,
Jian

Hmm, then the next question is - how do I check whether mshop is installed on the device?
Thanks,
Jian

mohlendo wrote:All versions of mShop support silentupgradecheck. Note that mShop and MobileShop are discrete products.
Administartor:
(1) Please kindly tell the difference between mshop and Mobile Shop
(2) How do we verify whether its mshop or Mobile SHop ?
I always thoiught mshop and Mobile SHop is same and we use IShell_BrowseURL
etc interfaces to check for upgrade. When we use this interface, are we assuming that its mshop on the phone that we are trying to access ?
Thanks in advance

mohlendo wrote:All versions of mShop support silentupgradecheck. Note that mShop and MobileShop are discrete products.
Administartor:
(1) Please kindly tell the difference between mshop and Mobile Shop
(2) How do we verify whether its mshop or Mobile SHop ?
I always thoiught mshop and Mobile SHop is same and we use IShell_BrowseURL
etc interfaces to check for upgrade. When we use this interface, are we assuming that its mshop on the phone that we are trying to access ?
Thanks in advance

mShop is basically MobileShop built on top of QUALCOMM's uiOne platform. If you have mShop on the device, the UI will be much more appealing than the traditional MobileShop interface.

mShop is basically MobileShop built on top of QUALCOMM's uiOne platform. If you have mShop on the device, the UI will be much more appealing than the traditional MobileShop interface.

Hi Max,
In your previous post: "All versions of mShop support silentupgradecheck. Note that mShop and MobileShop are discrete products." -
Did you imply "silentupgradecheck might NOT be supported by MobileShop"?
Thanks,
Jian

Hi Max,
In your previous post: "All versions of mShop support silentupgradecheck. Note that mShop and MobileShop are discrete products." -
Did you imply "silentupgradecheck might NOT be supported by MobileShop"?
Thanks,
Jian

That's exactly what I meant -- note my first post, which says "'silentupgradecheck' is new for mShop."

That's exactly what I meant -- note my first post, which says "'silentupgradecheck' is new for mShop."

Got it!
Then back to a previous question - how do I know whether silentupgradecheck can be used on a given device. Is there some kind of runtime check I can do?
Thanks,
Jian

Got it!
Then back to a previous question - how do I know whether silentupgradecheck can be used on a given device. Is there some kind of runtime check I can do?
Thanks,
Jian

I can't think of any runtime check you'd be able to do, but it could be that mShop registers for some new MIME types or something -- I'd have to check into that. One thing is that devices with mShop should have separate PIDs than the same device without mShop (mShop is only available as a preload), so you should be able to determine which devices have mShop in advance.

I can't think of any runtime check you'd be able to do, but it could be that mShop registers for some new MIME types or something -- I'd have to check into that. One thing is that devices with mShop should have separate PIDs than the same device without mShop (mShop is only available as a preload), so you should be able to determine which devices have mShop in advance.

I looked at mShop and it also registers as a MIME handler for the "tshop" MIME type. You could thus deduce programmatically when mShop is present on a device by querying for a MIME handler for this MIME type.

I looked at mShop and it also registers as a MIME handler for the "tshop" MIME type. You could thus deduce programmatically when mShop is present on a device by querying for a MIME handler for this MIME type.