In most cases when a carrier partnership agreement is achieved, the billing and/or authentication is done using the cell phone number of the BlackBerry smartphone.  Traditionally, this requirement meant that you’d call Phone.getDevicePhoneNumber(boolean format) to retrieve the user’s BlackBerry smartphone cell number.  However, if the user is using BlackBerry® Mobile Voice System (BlackBerry MVS), getDevicePhoneNumber() will not return their cell phone number, but instead will return the phone number used for BlackBerry MVS.  Uh-oh, did your app just create a support incident?  If you’ve been keeping up with platform features, the answer is no.

When a user is connected to BlackBerry MVS, the whole point is to use it as much as possible, thus getting its maximum benefit.  Thus, the user’s work number / the number associated with BlackBerry MVS now becomes the user’s default phone number – which is exactly what will be returned by getDevicePhoneNumber().  This new default phone number might cause a problem for the billing and/or authentication of your application through the carrier, since your application might be expecting the user’s cell number to be returned – not the BlackBerry MVS number.

So how do you handle this situation?

Option A: Make the user do it.

Since the user does have the ability to manually set which phone number to use, you could take a hard-nosed stance and make the user do all the work.  In order for the user to change this setting, they need to go into the Phone application, select “Options” from the menu, select “Work line,” then select “Line and Network Preferences,” and finally choose the right number using the drop down box labelled “Default line for outgoing calls.”  Save this change and you’re done.  With no change required to your app, getDevicePhoneNumber() now returns the cell number to you.  However, you’ve now just put a ton of onus on the user, reduced the effectiveness of BlackBerry MVS, and likely still generated a support call.

Option B: Take advantage of new platform features and use the new APIs.

Use the following API functionality added in BlackBerry Device Software 5.0:

int[] lineIds = Phone.getLineIds();
String phoneNumber = null;
for( int i=0; i < lineIds.length; i++ ) {
if(Phone.getLineType(lineIds[i]) == Phone.MOBILE_TYPE) {
//found the user’s cell number
phoneNumber = Phone.getLineNumber(lineIds[i]);
} else if Phone.getLineType(lineIds[i] == Phone.PBX_TYPE) {
//found the number used for BlackBerry MVS
}
}

With less than 10 lines of code, your app is more robust, BlackBerry MVS friendly, and can reliably provide the cell phone number to the carrier.  Personally, I like my carrier relationships, so I’ll go with option B.  But the choice is yours!

Have you tried out this tip? Let us know how it went in the comments!

• BlackBerry® Bold™ 9700 BlackBerry Smartphone Simulator (v5.0.0.337)
• BlackBerry® Storm™ 9550 BlackBerry Smartphone Simulator (v5.0.0.334)
• BlackBerry® Curve™ 8530 BlackBerry Smartphone Simulator (v5.0.0.337)
• Networking Transports II (Video)

Tune in next week for more Developer Resource Friday fun, and don’t forget to post a comment about your favorite article and articles you would like to see!

With the recent announcement of the BlackBerry® Storm2™ smartphone, I wanted to provide you with an overview of the device from the perspective of the developer to help you understand what opportunities this new smartphone opens up for you.

The BlackBerry Storm2 is the first BlackBerry® smartphone to ship with the new BlackBerry® Device Software v 5.0, which includes a variety of new enhancements for end users.  For developers, there are substantial improvements across the board which we have been covering on the blog for some time now.

For Java, you can find a great post outlining all of the new APIs and features in BlackBerry Device Software v5.0.

For Widgets, check out this great post introducing this new technology and stay tuned for additional posts that will dive deeper on the power of widgets on the BlackBerry platform.

Like the original BlackBerry® Storm™, there are two models of the Storm2 – one designed for North American CDMA networks and one for the rest of the world.  Both products support GSM/GPRS/EDGE/UMTS/HSPA with the CDMA product also supporting CDMA/EVDO.  This means the product supports 3G networks worldwide. From a developer’s perspective, here is what you need to know about the new BlackBerry Storm2.

• Navigation with SurePress™ touch screen
• 480 x 360 screen resolution
• 3.2 MP Camera with Auto Focus
• Location Support with Assisted and Autonomous GPS
• Wi-Fi® Support – 802.11b/g
• 256MB Flash Memory (Application Space), 2GB embedded MMC, and microSD™ Support (up to 16GB today and supporting the specification for 32GB cards when they become available)

We are really excited about the launch of the BlackBerry Storm2 smartphone and the new applications that are possible on the platform.  Get started now by checking out the developer tools on our beta website!

What matters is the experience and how users experience the web on a mobile device is starting to evolve in interesting ways beyond the request/response-oriented sit-down-at-your-PC-and-surf model, whether that be inside a browser or in a stand-alone application.

I see this evolution characterized by four key themes:

• Web-content targeted to mobile form-factor without a reduction in richness. This is already happening. We just need content developers to step–up and accelerate the upward trend!
• Deep integration into the on-device experience. My BlackBerry smartphone knows more about me than my PC ever will! This opens the door for compelling interactions via the integration of data and applications.
• Accelerated change in web content production-consumption model. A mobile device is a much better conduit to fulfill the Web 2.0 promise of an Architecture of Participation. The bar for users to add value can be much lower!
• Breaking free of the request/response interaction model. Delivering high-value content to users through subscriptions and notifications, and changing the way content and service providers are able to engage their audience to anywhere, anytime.

I’ll leave further exploration of these themes for a subsequent post but consider this: the way people connect to and consume the web is fundamentally changing. A recent FierceWireless report on wireless Internet use shows that more and more people are connecting to the web using a mobile device every day. I see it in my own behaviour. The amount of time I spend on the web on my Mac at home is diminishing; I don’t need to login to Facebook when I’ve been live all day on my BlackBerry smartphone (I use the Facebook® for BlackBerry® smartphones application). This is the promise that the next generation mobile web brings.

Post a comment and let us know how you feel about the next generation of the mobile web.