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

Developer

Forums

Forums:

Is there any reason a BREW 3.x preinstalled application cannot start with a 'Number of Uses' license for a trial and then switch to 'Number of Days' for a purchase?

A carrier told us that the preinstall price method *must* match the purchase price method(except the preinstall would have a DAP of $0) . However, this doesn't allow the application to keep the license within its control during a trial period. Why can't the preinstall price method be different from the purchase price method in a price plan to allow this?

Because you can't switch between license types unless the app has expired -- different license types are filtered out by MobileShop and not displayed.

Because you can't switch between license types unless the app has expired -- different license types are filtered out by MobileShop and not displayed.

Hello Max -
We set a new price plan, however, we're still not achieving the desired effect;
1. As I understand it the license type can change from LT_USES (as the intial preinstall license) to a monthly subscription. However, when we try to purchase a monthly subscription from the application we get the message "This application is already installed, you will be charged an additional ...".
Any enlightment appreciated.

Hello Max -
We set a new price plan, however, we're still not achieving the desired effect;
1. As I understand it the license type can change from LT_USES (as the intial preinstall license) to a monthly subscription. However, when we try to purchase a monthly subscription from the application we get the message "This application is already installed, you will be charged an additional ...".
Any enlightment appreciated.

We've done a trace and the license type returned after using the 'Monthly' purchase option in Mobile Shop is a numerical 5. This isn't even a valid license type per the BREW documentation. Any ideas?

We've done a trace and the license type returned after using the 'Monthly' purchase option in Mobile Shop is a numerical 5. This isn't even a valid license type per the BREW documentation. Any ideas?

Instance wrote:We've done a trace and the license type returned after using the 'Monthly' purchase option in Mobile Shop is a numerical 5. This isn't even a valid license type per the BREW documentation. Any ideas?
5 = LT_MAX. In BREW 2.x, this was returned as the license type for subscription apps. Is this a 2.x device?

Instance wrote:We've done a trace and the license type returned after using the 'Monthly' purchase option in Mobile Shop is a numerical 5. This isn't even a valid license type per the BREW documentation. Any ideas?
5 = LT_MAX. In BREW 2.x, this was returned as the license type for subscription apps. Is this a 2.x device?

Yes, it is a BREW 2.x device (I guess we're now in the wrong forum). I thought, per the BREW app note, subscription was supposed to be 'number of days'?

Yes, it is a BREW 2.x device (I guess we're now in the wrong forum). I thought, per the BREW app note, subscription was supposed to be 'number of days'?

Yes, for BREW 3.x a subscription license is represented with PT_SUBSCRIPTION, LT_DAYS, expiration 0xFFFFFFFF. In BREW 2.x, subscription licensing was PT_SUBSCRIPTION, LT_MAX, expiration 0. However, I'd like to point out that the license type and expiration value should be pretty much irrelevant as soon as you determine that the purchase type is subscription -- in other words, the more you code your application to make expectations on license types and expiration values when it's not necessary (subscription licensing is handled entirely by BREW), the more likely things are to break. ;)

Yes, for BREW 3.x a subscription license is represented with PT_SUBSCRIPTION, LT_DAYS, expiration 0xFFFFFFFF. In BREW 2.x, subscription licensing was PT_SUBSCRIPTION, LT_MAX, expiration 0. However, I'd like to point out that the license type and expiration value should be pretty much irrelevant as soon as you determine that the purchase type is subscription -- in other words, the more you code your application to make expectations on license types and expiration values when it's not necessary (subscription licensing is handled entirely by BREW), the more likely things are to break. ;)

Agreed ... top order we should just be checking for the subscription.
There's still one problem remaining. When you purchase the Monthly subscription from Mobile Shop it displays the following message “This application is already installed. You will be charged $9.99 for the additional purchase.”
Do you know why we're getting this message? Is it becuase the BDS assumes you've already purchased it since it has a preinstall license? (We're using LT_USES with a DAP of $0 for the preinstall method)

Agreed ... top order we should just be checking for the subscription.
There's still one problem remaining. When you purchase the Monthly subscription from Mobile Shop it displays the following message “This application is already installed. You will be charged $9.99 for the additional purchase.”
Do you know why we're getting this message? Is it becuase the BDS assumes you've already purchased it since it has a preinstall license? (We're using LT_USES with a DAP of $0 for the preinstall method)

Well, I guess the question is why you're expecting the behavior to be different, and what you'd expect it to be. Fundamentally a $0 DAP preinstall is a totally different price plan, so when the user purchases a subscription, they should be charged for the purchase.

Well, I guess the question is why you're expecting the behavior to be different, and what you'd expect it to be. Fundamentally a $0 DAP preinstall is a totally different price plan, so when the user purchases a subscription, they should be charged for the purchase.

Yes, we want them to be charged for the subscription purchase -- just without the 'additional purchase' message.
Essentially we're giving them a trial via LT_USES and they can purchase a subscription if they wish. I haven't seen this message with other production app's going from trial to purchase though. The carrier indicated they hadn't seen it on other preinstalls either.
It seems like it should be preinstalled as a demo. However, there isn't an option for demo under preinstall pricing methods (and the carrier told us we could not select a demo ... it must be preinstall with a zero DAP). How are other developers configuring it to get avoid this message?

Yes, we want them to be charged for the subscription purchase -- just without the 'additional purchase' message.
Essentially we're giving them a trial via LT_USES and they can purchase a subscription if they wish. I haven't seen this message with other production app's going from trial to purchase though. The carrier indicated they hadn't seen it on other preinstalls either.
It seems like it should be preinstalled as a demo. However, there isn't an option for demo under preinstall pricing methods (and the carrier told us we could not select a demo ... it must be preinstall with a zero DAP). How are other developers configuring it to get avoid this message?

Yeah, that message is pretty much displayed any time you have an app on the phone that's not licensed under PT_DEMO and the user purchases additional licensing. While it is true that you don't have the option to choose a PT_DEMO preinstall on the web site for a preinstall, some carriers have an arrangement with QUALCOMM to allow us to create PT_DEMO preinstall packages. You might want to double-check to see if this is an option.

Yeah, that message is pretty much displayed any time you have an app on the phone that's not licensed under PT_DEMO and the user purchases additional licensing. While it is true that you don't have the option to choose a PT_DEMO preinstall on the web site for a preinstall, some carriers have an arrangement with QUALCOMM to allow us to create PT_DEMO preinstall packages. You might want to double-check to see if this is an option.

thx ... that's exaclty what we needed to know.
To the original thread topic, I have a final question about your statement regarding the price plan settings in relation to the license. We understand from your previous post that the preinstall and purchase pricing method must match in the price plan. So we selected LT_USES for both preinstall and purchase methods. However, we set LT_USES to '1' for preinstall and LT_USES to 'Unlimited' for the purchase. We find empircally that after a purchase it returns a license of LT_USES = 1 instead of the expected 'Unlimited' license. Is this becuase they also must match in the price plan?

thx ... that's exaclty what we needed to know.
To the original thread topic, I have a final question about your statement regarding the price plan settings in relation to the license. We understand from your previous post that the preinstall and purchase pricing method must match in the price plan. So we selected LT_USES for both preinstall and purchase methods. However, we set LT_USES to '1' for preinstall and LT_USES to 'Unlimited' for the purchase. We find empircally that after a purchase it returns a license of LT_USES = 1 instead of the expected 'Unlimited' license. Is this becuase they also must match in the price plan?

Not sure I follow. If the preinstall and the server version are properly coordinated, when you purchase the unlimited licensing price option from the server, the licensing should be updated in the preinstall MIF to an unlimited expiration value (BV_UNLIMITED).

Not sure I follow. If the preinstall and the server version are properly coordinated, when you purchase the unlimited licensing price option from the server, the licensing should be updated in the preinstall MIF to an unlimited expiration value (BV_UNLIMITED).