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

Developer

Forums

Forums:

Hi,

I am doing a project for our existing apps, which will let the user know if there is a new version available for the old version of the application. More clearley, if the most recent version is available for an app, then the user should get the prompt from server. In other words, the application would fetch this value (the most current version of the application available) from some server and compare it to the running version of the application. If it's discovered that the running application is obsolete, it will then prompt the user to upgrade. I have searched the brew forum and the following link is the only one that I got that matches my problem 100%. But this thread had no further information of the implementation of this.

http://brewforums.qualcomm.com/showthread.php?t=7127&highlight=current+version

Now, my question is, does anybody know that if there is an API in 3.1 SDK or any version of brew that can do this job? Or I have to write my own Upgrader?

Thanks in advance. Pls help me.

Hi there,
Is there anybody to have any suggestion/advice regarding my question above ?:)

Hi there,
Is there anybody to have any suggestion/advice regarding my question above ?:)

No there is no API avaliable for the above task.

No there is no API avaliable for the above task.

Thanks skumar. I appreciate your answer.
Now how can it be done! I am thinking that a function can be written in my application which gets the current app version from MIF using ISHELL_GetAppVersion(). Then It should compare this value with a newer version fetched from the server that we are maintaining. Or, is there any other way?
1. I am looking for any better approach or need to know if I am going towards the right direction. Any ideas??
2. If I am thinking right, then how can I fetch version from the server? Is it from platform ID? Does anybody has any clue for this?
PLS help.... :confused:

Thanks skumar. I appreciate your answer.
Now how can it be done! I am thinking that a function can be written in my application which gets the current app version from MIF using ISHELL_GetAppVersion(). Then It should compare this value with a newer version fetched from the server that we are maintaining. Or, is there any other way?
1. I am looking for any better approach or need to know if I am going towards the right direction. Any ideas??
2. If I am thinking right, then how can I fetch version from the server? Is it from platform ID? Does anybody has any clue for this?
PLS help.... :confused:

Yes, the strategy you described is probably the best option for accomplishing this task.
Your application could query your server, passing in the platform ID. Your server would then reply with the most recent version for that platform ID (you would need to maintain a listing of the most recent versions), and your application could compare the most recent version with the current version and determine whether an upgrade exists.

Yes, the strategy you described is probably the best option for accomplishing this task.
Your application could query your server, passing in the platform ID. Your server would then reply with the most recent version for that platform ID (you would need to maintain a listing of the most recent versions), and your application could compare the most recent version with the current version and determine whether an upgrade exists.

Max,
Thank you so much for your valuable information and clarifying my confusion :) .
I have read in BREW programming concept giude in 3.1 SDK that my application can invoke BREW mobile shop. I am still researching and trying to get this option work from a simple hello world application. If this can be done, then the newer version can be compared with older version of the app, right? I think, ISHELL_GetClassItemID() would have to be used to get the itemID corresponding to the app's class ID. So, the mobile shop will give the user the newer version that is availbale for the app [info got from classid], is this correct?
Thanks in advance.

Max,
Thank you so much for your valuable information and clarifying my confusion :) .
I have read in BREW programming concept giude in 3.1 SDK that my application can invoke BREW mobile shop. I am still researching and trying to get this option work from a simple hello world application. If this can be done, then the newer version can be compared with older version of the app, right? I think, ISHELL_GetClassItemID() would have to be used to get the itemID corresponding to the app's class ID. So, the mobile shop will give the user the newer version that is availbale for the app [info got from classid], is this correct?
Thanks in advance.

BAM 2.0.4+ automatically handles the scenario where a cmshop:ItemID= call is made with an item ID that no longer exists on the server by performing an upgrade check to find later versions of the application. On BAM 2.0.4+ this will be properly handled by MobileShop; however, for devices with BAM versions less than 2.0.4, the workaround described below is required for proper MobileShop behavior when dealing with upgraded applications.
The download item ID is a 32-bit unsigned integer used to identify application packages within the Application Download Server (ADS). The application ID actually consists of the first 24 bits; the final 8 bits represent the version of the application. Any time an upgrade request is made for a given item ID (cmshop:UpgradeCheck=), the ADS makes a check to verify that the version on the server exceeds the version in the upgrade request – if the application version on the server is greater than or equal to the version in the upgrade request, the request will fail. This is significant because an upgrade check request (for the purpose of upgrading licensing from limited to full functionality) will fail to return results if the application version on the device matches the version on the server, preventing MobileShop from allowing the user to purchase additional uses. For this reason, an application cannot blindly perform an upgrade check request with the item ID it fetches through ISHELL_GetClassItemID().
The solution for this problem is to zero out the version number for the upgrade check request through simple logical operations, as demonstrated below:
#define DLITEMID_FAMILY_MASK (0xffffff00l)
uint32 myAppDownloadID; // used to store download ID
// retrieve download ID and zero out the version number
myAppDownloadID = ISHELL_GetClassItemID(pIShell, AEECLSID_MYAPP) & DLITEMID_FAMILY_MASK;
After the version number has been zeroed out, the application can safely make an upgrade check request regardless of the application version on the server – the server will never have a version of the application that is less than that of the preinstall application. Any application intended for a device running a version of BAM less than 2.0.4 should be coded to perform an upgrade check with a zeroed-out version number any time MobileShop is invoked for license upgrading.

BAM 2.0.4+ automatically handles the scenario where a cmshop:ItemID= call is made with an item ID that no longer exists on the server by performing an upgrade check to find later versions of the application. On BAM 2.0.4+ this will be properly handled by MobileShop; however, for devices with BAM versions less than 2.0.4, the workaround described below is required for proper MobileShop behavior when dealing with upgraded applications.
The download item ID is a 32-bit unsigned integer used to identify application packages within the Application Download Server (ADS). The application ID actually consists of the first 24 bits; the final 8 bits represent the version of the application. Any time an upgrade request is made for a given item ID (cmshop:UpgradeCheck=), the ADS makes a check to verify that the version on the server exceeds the version in the upgrade request – if the application version on the server is greater than or equal to the version in the upgrade request, the request will fail. This is significant because an upgrade check request (for the purpose of upgrading licensing from limited to full functionality) will fail to return results if the application version on the device matches the version on the server, preventing MobileShop from allowing the user to purchase additional uses. For this reason, an application cannot blindly perform an upgrade check request with the item ID it fetches through ISHELL_GetClassItemID().
The solution for this problem is to zero out the version number for the upgrade check request through simple logical operations, as demonstrated below:
#define DLITEMID_FAMILY_MASK (0xffffff00l)
uint32 myAppDownloadID; // used to store download ID
// retrieve download ID and zero out the version number
myAppDownloadID = ISHELL_GetClassItemID(pIShell, AEECLSID_MYAPP) & DLITEMID_FAMILY_MASK;
After the version number has been zeroed out, the application can safely make an upgrade check request regardless of the application version on the server – the server will never have a version of the application that is less than that of the preinstall application. Any application intended for a device running a version of BAM less than 2.0.4 should be coded to perform an upgrade check with a zeroed-out version number any time MobileShop is invoked for license upgrading.

Also, as far as your version numbering scheme goes, it's best to use version strings that can be compared with a simple lex comparison (i.e. STRCMP()). This makes it much easier to determine if a version is older or more recent than another version.

Also, as far as your version numbering scheme goes, it's best to use version strings that can be compared with a simple lex comparison (i.e. STRCMP()). This makes it much easier to determine if a version is older or more recent than another version.

Hey MAx,
Thank you so much, Man! It was awesome. So, I already wrote a function like you suggested. My srategy is as below:
-When the application is started then a simple text is shown on top of the screen.
- Then pressing the OK key would bring up the mobile shop and then the version checking would be done using STRCMP().
Now, when I press the OK key i dont see the mobile shop on the screen. I am debugging in the 3.1 simulator and I will probably use a 3.x mobile device later to check this. My code :
void Cversion::InvokeMobileShop(AEECLSID AppId)
{
uint32 itemId;
itemId = ISHELL_GetClassItemID(m_pIShell, AppId);
DBGPRINTF ("Itemid :%d", itemId);
ISHELL_GetHandler(m_pIShell, HTYPE_BROWSE, "cmshop");
ISHELL_BrowseURL(m_pIShell,"cmshop:UpgradeCheck=itemId");
}
Do you have any idea why I cant see the mobile shop screen?
Thanks in advance :)

Hey MAx,
Thank you so much, Man! It was awesome. So, I already wrote a function like you suggested. My srategy is as below:
-When the application is started then a simple text is shown on top of the screen.
- Then pressing the OK key would bring up the mobile shop and then the version checking would be done using STRCMP().
Now, when I press the OK key i dont see the mobile shop on the screen. I am debugging in the 3.1 simulator and I will probably use a 3.x mobile device later to check this. My code :
void Cversion::InvokeMobileShop(AEECLSID AppId)
{
uint32 itemId;
itemId = ISHELL_GetClassItemID(m_pIShell, AppId);
DBGPRINTF ("Itemid :%d", itemId);
ISHELL_GetHandler(m_pIShell, HTYPE_BROWSE, "cmshop");
ISHELL_BrowseURL(m_pIShell,"cmshop:UpgradeCheck=itemId");
}
Do you have any idea why I cant see the mobile shop screen?
Thanks in advance :)

mohlendo wrote:BAM 2.0.4+ automatically handles the scenario where a cmshop:ItemID= call is made with an item ID that no longer exists on the server by performing an upgrade check to find later versions of the application.
By the way... what is BAM? Is it refering to BREW SDK version? Or BREW App Manager :rolleyes:
-Farhana

mohlendo wrote:BAM 2.0.4+ automatically handles the scenario where a cmshop:ItemID= call is made with an item ID that no longer exists on the server by performing an upgrade check to find later versions of the application.
By the way... what is BAM? Is it refering to BREW SDK version? Or BREW App Manager :rolleyes:
-Farhana

Max,
So, when I did ISHELL_GetClassItemID(), I got a "negative" number as itemid. why is that?
Thanks. :confused:

Max,
So, when I did ISHELL_GetClassItemID(), I got a "negative" number as itemid. why is that?
Thanks. :confused:

Hi Max,
My code works on the device :D ...I was looking in the simulator and I wasn't getting anything. But now my app is actually invoking the mobile shop from inside the app. Now I gotta work on version comparison.
Thanks for your help:).

Hi Max,
My code works on the device :D ...I was looking in the simulator and I wasn't getting anything. But now my app is actually invoking the mobile shop from inside the app. Now I gotta work on version comparison.
Thanks for your help:).

If you do ISHELL_GetClassItemID() on any locally generated MIF, you'll get garbage values. This comes from the MIF tail, which is appended to the MIF when the application is loaded to the BDS.
BAM stands for BREW App Manager. BAM version is not synonymous with BREW version -- check the DDS for newer devices to determine the BAM version.

If you do ISHELL_GetClassItemID() on any locally generated MIF, you'll get garbage values. This comes from the MIF tail, which is appended to the MIF when the application is loaded to the BDS.
BAM stands for BREW App Manager. BAM version is not synonymous with BREW version -- check the DDS for newer devices to determine the BAM version.

The reason you weren't seeing anything on the Simulator is that the developer version of the Simulator doesn't come with MobileShop. :)
Be sure your app is not handling EVT_BUSY, or it won't properly suspend (which can prevent MobileShop from launching).

The reason you weren't seeing anything on the Simulator is that the developer version of the Simulator doesn't come with MobileShop. :)
Be sure your app is not handling EVT_BUSY, or it won't properly suspend (which can prevent MobileShop from launching).

mohlendo wrote:If you do ISHELL_GetClassItemID() on any locally generated MIF, you'll get garbage values. This comes from the MIF tail, which is appended to the MIF when the application is loaded to the BDS.
BAM stands for BREW App Manager. BAM version is not synonymous with BREW version -- check the DDS for newer devices to determine the BAM version.
Max,
Thank you very much for your help. I really appreciate. Now I got another problem. My code works for brew 2.1.3. But when I build that in brew 2.0.1 [the brew version which I am supposed to get my task done ], then ISHELL_GetClassItemID() is missing cause its not in that SDK version. So then how can the task [invoking mobile shop from app in brew 2.0.1] be done in 2.0.1?
Thanks in advance.
PS: any advice from anybody will also be appreciated :)

mohlendo wrote:If you do ISHELL_GetClassItemID() on any locally generated MIF, you'll get garbage values. This comes from the MIF tail, which is appended to the MIF when the application is loaded to the BDS.
BAM stands for BREW App Manager. BAM version is not synonymous with BREW version -- check the DDS for newer devices to determine the BAM version.
Max,
Thank you very much for your help. I really appreciate. Now I got another problem. My code works for brew 2.1.3. But when I build that in brew 2.0.1 [the brew version which I am supposed to get my task done ], then ISHELL_GetClassItemID() is missing cause its not in that SDK version. So then how can the task [invoking mobile shop from app in brew 2.0.1] be done in 2.0.1?
Thanks in advance.
PS: any advice from anybody will also be appreciated :)

mohlendo wrote:If you do ISHELL_GetClassItemID() on any locally generated MIF, you'll get garbage values. This comes from the MIF tail, which is appended to the MIF when the application is loaded to the BDS.
BAM stands for BREW App Manager. BAM version is not synonymous with BREW version -- check the DDS for newer devices to determine the BAM version.
Max,
Could you please clarify what do you mean by locally generated MIF? I always get classid from Qualcomm website and create the MIF file. So I understand that I can get the classitemid from the app which is already loaded to BDS. This is exactly what I am trying to do.
Thanks.

mohlendo wrote:If you do ISHELL_GetClassItemID() on any locally generated MIF, you'll get garbage values. This comes from the MIF tail, which is appended to the MIF when the application is loaded to the BDS.
BAM stands for BREW App Manager. BAM version is not synonymous with BREW version -- check the DDS for newer devices to determine the BAM version.
Max,
Could you please clarify what do you mean by locally generated MIF? I always get classid from Qualcomm website and create the MIF file. So I understand that I can get the classitemid from the app which is already loaded to BDS. This is exactly what I am trying to do.
Thanks.

farhana wrote:Max,
Thank you very much for your help. I really appreciate. Now I got another problem. My code works for brew 2.1.3. But when I build that in brew 2.0.1 [the brew version which I am supposed to get my task done ], then ISHELL_GetClassItemID() is missing cause its not in that SDK version. So then how can the task [invoking mobile shop from app in brew 2.0.1] be done in 2.0.1?
Thanks in advance.
PS: any advice from anybody will also be appreciated :)
You can't get the item ID in 2.0. I guess you would need to modify your server so that it sends the item ID to the application as well (you would know the item ID of the application after it has passed TBT). As a whole, upgrades are difficult to implement in 2.0.

farhana wrote:Max,
Thank you very much for your help. I really appreciate. Now I got another problem. My code works for brew 2.1.3. But when I build that in brew 2.0.1 [the brew version which I am supposed to get my task done ], then ISHELL_GetClassItemID() is missing cause its not in that SDK version. So then how can the task [invoking mobile shop from app in brew 2.0.1] be done in 2.0.1?
Thanks in advance.
PS: any advice from anybody will also be appreciated :)
You can't get the item ID in 2.0. I guess you would need to modify your server so that it sends the item ID to the application as well (you would know the item ID of the application after it has passed TBT). As a whole, upgrades are difficult to implement in 2.0.

farhana wrote:Max,
Could you please clarify what do you mean by locally generated MIF? I always get classid from Qualcomm website and create the MIF file. So I understand that I can get the classitemid from the app which is already loaded to BDS. This is exactly what I am trying to do.
Thanks.
I mean a MIF that didn't come out of the BDS. Any time you have a MIF you create, the MIF tail will not be properly populated.

farhana wrote:Max,
Could you please clarify what do you mean by locally generated MIF? I always get classid from Qualcomm website and create the MIF file. So I understand that I can get the classitemid from the app which is already loaded to BDS. This is exactly what I am trying to do.
Thanks.
I mean a MIF that didn't come out of the BDS. Any time you have a MIF you create, the MIF tail will not be properly populated.

Max,
Cool. Thanks a lot for all the valuable infos.

Max,
Cool. Thanks a lot for all the valuable infos.