Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Sometime after we get our first version of an application certified and on the BREW deck, suppose that we update the application, create a new version, get it certified and replace the original one on the BREW deck. How can we upgrade users who had already downloaded the first version? Does BREW support the ability to automatically download the client with the latest version the next time they log in? If not, does BREW provide a mechanism for the user to be notified of or check for the new version and download it when available?.

There are two types of upgrades:
Normal Upgrade
cmshop:UpgradeCheck=%u - Checks for upgrades to the application with the specified ItemID. If upgrades are available, the price list will be displayed. Otherwise, there will be a dialog indicating that no upgrades are available.
Silent Upgrade Check
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.
Implementation is as follows:
1. Register for a unique MIME type. One way to do this is to register for the name of your app. Let’s assume our app is called “frog”, so we would register for the “frog” mime type through the MIF file. Let’s also assume our appID is 0x12345.
2. Next, we can throw a URL to start the upgrade check. For example:
ISHELL_BrowseURL (pMe->pIShell, "SilentUpgradeCheck=0x12345&url=frog%3AUpgradeAvail%3D%25d");
The second parameter, being itself a URL, must be URL-encoded as shown above. The un-encoded version of the above example is frog:UpgradeAvailable=%d.
After this URL is sent, mShop will silently check for the existence of the upgrade. Once completed, it will send the URL back to the app and change the trailing %d to on of the following:
Check failed 0
Upgrade available 1
No upgrade available 2
3. The App then must handle EVT_APP_POST_URL. The dwParam will contain the updated URL returned by mShop. The app can then inspect the trailing digit to see if the upgrade exists or not.
-Tony
BREW Support

There are two types of upgrades:
Normal Upgrade
cmshop:UpgradeCheck=%u - Checks for upgrades to the application with the specified ItemID. If upgrades are available, the price list will be displayed. Otherwise, there will be a dialog indicating that no upgrades are available.
Silent Upgrade Check
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.
Implementation is as follows:
1. Register for a unique MIME type. One way to do this is to register for the name of your app. Let’s assume our app is called “frog”, so we would register for the “frog” mime type through the MIF file. Let’s also assume our appID is 0x12345.
2. Next, we can throw a URL to start the upgrade check. For example:
ISHELL_BrowseURL (pMe->pIShell, "SilentUpgradeCheck=0x12345&url=frog%3AUpgradeAvail%3D%25d");
The second parameter, being itself a URL, must be URL-encoded as shown above. The un-encoded version of the above example is frog:UpgradeAvailable=%d.
After this URL is sent, mShop will silently check for the existence of the upgrade. Once completed, it will send the URL back to the app and change the trailing %d to on of the following:
Check failed 0
Upgrade available 1
No upgrade available 2
3. The App then must handle EVT_APP_POST_URL. The dwParam will contain the updated URL returned by mShop. The app can then inspect the trailing digit to see if the upgrade exists or not.
-Tony
BREW Support

Can you provide details on how catalog id's are assigned to BREW applications that are NSTL certified? Is the catalog version in the BDS specific for each device type and do updated versions of app get different catalog ids.

Can you provide details on how catalog id's are assigned to BREW applications that are NSTL certified? Is the catalog version in the BDS specific for each device type and do updated versions of app get different catalog ids.

Application IDs map to submission packages. If there's a new submission package, a new ID is assigned.

Application IDs map to submission packages. If there's a new submission package, a new ID is assigned.

If i got reply that indicates that i have an updated version in the catalog, what do i do next?
I use ISHELL_BrowseURL(pMe->m_pIShell, "cmshop:catalog");
and get in the catalog...
Can i go directly to my specific application, or start downloading automatically?
Gal

If i got reply that indicates that i have an updated version in the catalog, what do i do next?
I use ISHELL_BrowseURL(pMe->m_pIShell, "cmshop:catalog");
and get in the catalog...
Can i go directly to my specific application, or start downloading automatically?
Gal

Quote:There are two types of upgrades:
Normal Upgrade
cmshop:UpgradeCheck=%u - Checks for upgrades to the application with the specified ItemID. If upgrades are available, the price list will be displayed. Otherwise, there will be a dialog indicating that no upgrades are available.
Silent Upgrade Check
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.
Implementation is as follows:
1. Register for a unique MIME type. One way to do this is to register for the name of your app. Let’s assume our app is called “frog”, so we would register for the “frog” mime type through the MIF file. Let’s also assume our appID is 0x12345.
2. Next, we can throw a URL to start the upgrade check. For example:
ISHELL_BrowseURL (pMe->pIShell, "SilentUpgradeCheck=0x12345&url=frog%3AUpgradeAvail%3D%25d");
The second parameter, being itself a URL, must be URL-encoded as shown above. The un-encoded version of the above example is frog:UpgradeAvailable=%d.
After this URL is sent, mShop will silently check for the existence of the upgrade. Once completed, it will send the URL back to the app and change the trailing %d to on of the following:
Check failed 0
Upgrade available 1
No upgrade available 2
3. The App then must handle EVT_APP_POST_URL. The dwParam will contain the updated URL returned by mShop. The app can then inspect the trailing digit to see if the upgrade exists or not.
-Tony
BREW Support
:eek: :eek: :eek:
If i got reply that indicates that i have an updated version in the catalog, what do i do next?
I use ISHELL_BrowseURL(pMe->m_pIShell, "cmshop:catalog");
and get in the catalog...
Can i go directly to my specific application, or start downloading automatically?
Gal

Quote:There are two types of upgrades:
Normal Upgrade
cmshop:UpgradeCheck=%u - Checks for upgrades to the application with the specified ItemID. If upgrades are available, the price list will be displayed. Otherwise, there will be a dialog indicating that no upgrades are available.
Silent Upgrade Check
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.
Implementation is as follows:
1. Register for a unique MIME type. One way to do this is to register for the name of your app. Let’s assume our app is called “frog”, so we would register for the “frog” mime type through the MIF file. Let’s also assume our appID is 0x12345.
2. Next, we can throw a URL to start the upgrade check. For example:
ISHELL_BrowseURL (pMe->pIShell, "SilentUpgradeCheck=0x12345&url=frog%3AUpgradeAvail%3D%25d");
The second parameter, being itself a URL, must be URL-encoded as shown above. The un-encoded version of the above example is frog:UpgradeAvailable=%d.
After this URL is sent, mShop will silently check for the existence of the upgrade. Once completed, it will send the URL back to the app and change the trailing %d to on of the following:
Check failed 0
Upgrade available 1
No upgrade available 2
3. The App then must handle EVT_APP_POST_URL. The dwParam will contain the updated URL returned by mShop. The app can then inspect the trailing digit to see if the upgrade exists or not.
-Tony
BREW Support
:eek: :eek: :eek:
If i got reply that indicates that i have an updated version in the catalog, what do i do next?
I use ISHELL_BrowseURL(pMe->m_pIShell, "cmshop:catalog");
and get in the catalog...
Can i go directly to my specific application, or start downloading automatically?
Gal

Also, if i want to check if upgrade exists, i can use ISHELL_BrowseURL with "cmshop:UpgradeCheck=".
Something isn't working for me:
At the end i get : "cmshop:UpgradeCheck=0x0104f868"
And i use ISHELL_BrowseURL(iSell, "cmshop:UpgradeCheck=0x0104f868");
the app connects the mShop but always return some kind of error message.

Also, if i want to check if upgrade exists, i can use ISHELL_BrowseURL with "cmshop:UpgradeCheck=".
Something isn't working for me:
At the end i get : "cmshop:UpgradeCheck=0x0104f868"
And i use ISHELL_BrowseURL(iSell, "cmshop:UpgradeCheck=0x0104f868");
the app connects the mShop but always return some kind of error message.

gal_k wrote:Also, if i want to check if upgrade exists, i can use ISHELL_BrowseURL with "cmshop:UpgradeCheck=".
Something isn't working for me:
At the end i get : "cmshop:UpgradeCheck=0x0104f868"
And i use ISHELL_BrowseURL(iSell, "cmshop:UpgradeCheck=0x0104f868");
the app connects the mShop but always return some kind of error message.
That's not an itemID, that's a class ID. The two are totally different, but you can get the item ID from the class ID using ISHELL_GetClassItemID().

gal_k wrote:Also, if i want to check if upgrade exists, i can use ISHELL_BrowseURL with "cmshop:UpgradeCheck=".
Something isn't working for me:
At the end i get : "cmshop:UpgradeCheck=0x0104f868"
And i use ISHELL_BrowseURL(iSell, "cmshop:UpgradeCheck=0x0104f868");
the app connects the mShop but always return some kind of error message.
That's not an itemID, that's a class ID. The two are totally different, but you can get the item ID from the class ID using ISHELL_GetClassItemID().

I try to check for upgrade in mShop.
Class id is: 0x0104f868
I use ISHELL_BrowseURL(ishell, "cmshop:UpgradeCheck=0104f868");
And get message that "No Items Found"...
What am i doing wrong?

I try to check for upgrade in mShop.
Class id is: 0x0104f868
I use ISHELL_BrowseURL(ishell, "cmshop:UpgradeCheck=0104f868");
And get message that "No Items Found"...
What am i doing wrong?

Hi,
Is there any way to reliable test the upgrade process bfore an app is submitted?
I have an app that is nearing completion and I know that it will be upgraded in the future, so I want to build the functionality in now.
Thanks
Adrian

Hi,
Is there any way to reliable test the upgrade process bfore an app is submitted?
I have an app that is nearing completion and I know that it will be upgraded in the future, so I want to build the functionality in now.
Thanks
Adrian

Anyone have any idea how to test this mechanism? I've developed a new application which I'll potentially need to update in the future but I can't find any clear and thorough documentation regarding how to test this process if you don't already have an application in the mshop.
Further more the documentation here:
https://brewx.qualcomm.com/bws/content/dx/docs/developercontent/AppUpgra...
seems to contradict the process described earlier in this post for application upgrades.
Any help is greatly appreciated.

Anyone have any idea how to test this mechanism? I've developed a new application which I'll potentially need to update in the future but I can't find any clear and thorough documentation regarding how to test this process if you don't already have an application in the mshop.
Further more the documentation here:
https://brewx.qualcomm.com/bws/content/dx/docs/developercontent/AppUpgra...
seems to contradict the process described earlier in this post for application upgrades.
Any help is greatly appreciated.

You cannot test upgrade mechanism, it needs ADS.
Application can be upgraded in following ways:
1. Upgrade through application: described earlier in this thread (normal & silent upgrade using cmshop commnads)
2. Manual upgrade using Brew app manager options: Needs to provide new version as upgrade to existing app with new version.
3. Forced upgrade: done by ADS, total operator work.
I don't think doc mentioned above contradicts this process. It gives guidelines about 2 above, I guess.

You cannot test upgrade mechanism, it needs ADS.
Application can be upgraded in following ways:
1. Upgrade through application: described earlier in this thread (normal & silent upgrade using cmshop commnads)
2. Manual upgrade using Brew app manager options: Needs to provide new version as upgrade to existing app with new version.
3. Forced upgrade: done by ADS, total operator work.
I don't think doc mentioned above contradicts this process. It gives guidelines about 2 above, I guess.

Thanks Atul -- I'm quite new to BREW development and I'm finding if rather difficult to find authoritative resources on some of these topics. While technical implementation details about upgrading through the application is described above it's not clear to me how I can test that this process works before launching my application to market. How would I test this if I don't already have my application in the mobile shop?

Thanks Atul -- I'm quite new to BREW development and I'm finding if rather difficult to find authoritative resources on some of these topics. While technical implementation details about upgrading through the application is described above it's not clear to me how I can test that this process works before launching my application to market. How would I test this if I don't already have my application in the mobile shop?

Unfortunately you cannot test this unless you have access to ADS. APA cmshop commands are concerned you can check if command is going to mobileshop.

Unfortunately you cannot test this unless you have access to ADS. APA cmshop commands are concerned you can check if command is going to mobileshop.