The folks at Globe & Mail did a nice piece on The Score Mobile this morning. Check it out below.

http://www.theglobeandmail.com/sports/blackberry-wired-to-thescore/article1347673/

According to Distmo, The Score Mobile for BlackBerry was the top downloaded application in BlackBerry App World for the month of September, beating out popular applications such as Facebook and Pandora.

We expect October to be a great month as well, with the start of the NHL and NBA season!

http://www.time.com/time/magazine/article/0,9171,1916291-2,00.html

Some of you may have already seen this, but this is an excellent article about a developer’s first experience with BlackBerry development. A definite read if you’re an aspiring developer or looking to build something on the BlackBerry platform.

Of course if this developer had contacted us, we could have answered most of these questions up front

Read the article here.

Gizmodo did an excellent review of the different Smartphone App Stores that exist in the market place. The chart below describes the similarities and differences between the various platform storefronts as of April 7th, 2009. The full article can be found here.

Having been in the mobile space for a number of years, I’m often asked by prospective customers whether they should develop a mobile website or create a downloadable application that runs on the handsets. The short answer is, it depends on what your trying to accomplish.

Developing for the Mobile Web

Web development on mobile phones has long suffered from a very rigid platform and the inability for mobile browsers to keep up with current web technologies. This is slowly changing, partially due to the recent spikes in Smartphone handset sales. With many handset manufacturers attempting to clone the iPhone’s usability and appeal, a larger focus has been placed on the content on mobile phones, which in turn, requires better software to render this content. For example, both the iPhone and Blackberry Bold browsers can view HTML pages and process JavaScript. Technologies such as Flash have been rumored to be coming in the near term, but it will take some time before its supported on a large number of devices.

The “Pros” for Developing Mobile Web Applications

• The cost of supporting a mobile web application is relatively cheap in comparison to a downloadable application
• Accordingly, the speed at which a mobile website can be created is relatively quick
• If you have an existing high traffic web destination, developing a mobile version makes sense as your site already has a brand attached to it and a loyal following
• Higher-end devices are beginning to support existing desktop browser capabilities thus making the delta between your mobile and desktop browser experience smaller
• Deployment of a mobile website is quite simple
• The mobile web allows you to develop on a single platform and target the broadest set of launched across all handsets

The “Cons” for Developing Mobile Web Applications

• Currently, mobile websites are unable to take advantage of device specific features
• Ex: For the same reasons you can’t use a website to burn a CD, you cannot use a mobile website to access your phone’s contact list
• This is why high traffic sites such as Facebook will create both a mobile website and downloadable application
• Relatively speaking, interfaces on mobile websites are quite poor and clunky resulting in a less than desirable user experience
• Currently, support for AJAX and DHTML technologies is quite limited
• Despite developing for a single platform, developers must take into account mobile device idiosyncrasies across different handsets, firmware versions and operators
• Users must be connected at all times… there is no concept of an “offline mode”
• With the increase in mobile handset vendors, there has also been an increase in browser fragmentation
• On the web, typically developers are focused on Firefox, Opera, Internet Explorer and Safari
• In the mobile space, there are 10+ relevant browsers and many more in development
• Mobile website owners must rely heavily on 3rd party sources such as Device Atlas to understand device characteristics

Developing Mobile Applications

Similar to the mobile web, the native capabilities of handsets have improved and so have the associated SDKs. If you’re watching how Apple markets the iPhone, its all about letting users know that their device is more than just a phone. Specifically, they showcase applications created for the handset that leverage it’s unique capabilities. In general, Apple has done a fantastic job of making users feel comfortable in downloading content to their handsets. It’s not only helped them, but it’s opened up the floodgates across other platforms.

The “Pros” for Developing Mobile Applications

• Mobile applications can interact directly with the device obtaining useful information such as location, contact lists, accelerometer functions, etc. This is critical for a “mobile” application
• Having the ability to control exactly what is displayed on screen allows for customized (and optimized), rich user interfaces directly on the device
• User interactions can also be directly controlled via the possible inputs (touch, voice, keyboard, etc)
• In your mobile application, you are able to store reasonable amounts of data directly on the handset in a secure manner as opposed to storing everything on a remote server (slow!)
• Performance can typically be optimized for each handset and platform
• Mobile (Smartphone) development platforms are improving quite rapidly
• Developers can create a consistent look and feel throughout their application
• Measurement in terms of how users interact with an application is possible

The “Cons” for Developing Mobile Applications

• Unless proper design measures are taken, upkeep and continued portability of your application is difficult to maintain.  This happens to be something we specialize in
• There are 5-6 relevant mobile application development platforms to choose from, and understand which ones best suit your needs can be confusing
• Within these platforms, additional fragmentation exists at a per device, firmware and operator level
• Typically, developing rich mobile applications is more costly than creating a mobile website
• Mobile applications may require porting to additional platforms and this takes up front consideration
• A single, publicly available source for data across all mobile handset characteristics and attributes as they relate to the individual SDKs does not exist
• Testing can be time consuming and costly as mobile applications must be tested on the physical handset
• One needs to understand the various carrier requirements if an “on deck” strategy is preferred

In conclusion, it very much depends on your organization’s goals with regards to the mobile application. If it’s simply an extension of your mobile website, is heavily content focused and does not require an interactive user experience, then the mobile web may be a better choice. If one requires access to device functionality such as location or the contact list and have an appropriate development and porting strategy formed (either internally, or through a partner) that will help minimize the effects of device fragmentation, then developing a mobile application makes sense.

While I lived in California, I was a frequent attendee at the then fledgling Mobile Monday groups. I even spoke at one in LA during the E3 expo (remember that?) a few years back. After moving back to the frigid North, I was quite pleased to find a flourishing local chapter in Toronto. If you’re interested in the wireless space, I highly recommend you come out. It’s a great place to network with individuals from all areas of the mobile eco-system.

Yesterday marked the first meeting of 2009, and to kick things off, Tyler Lessard (Director of the ISV Alliances partner program at RIM) was the guest speaker. His presentation’s core focus was around the upcoming launch of the BlackBerry App Store and some of the launch logistics.

A few things that piqued my interest:

• RIM has partnered with PayPal to facilitate billing for their App Store
• Older BlackBerrys (i.e. without trackball) will not be supported. Time to buy a Bold!
• Developers will have the ability to specify unique or identical builds across a set of carriers, operating system and firmware versions for their application
• RIM will be launching a PUSH API in the near term

My first reaction after hearing about the integration with PayPal was to groan. My initial fear was that all users would have to go through a PayPal sign-up process when they attached a credit card to their account and as a result, would have to wait a few days before being able to make their first purchase. After talking with Jeff, I realized this was not the case, as PayPal can act purely as a payment processor direct from a credit card.

The crowd was buzzing when Tyler mentioned that RIM would be allowing PUSH capabilities via an API. This has long been a desired feature across all mobile platforms. For those who don’t know, PUSH allows for the delivery of data to a handset without the handset having to submit requests for it. Currently, true PUSH support is sporadic at best and is certainly one of the remaining challenges that developers face. In the past, BES/MDS was required for push on BlackBerry, but this newer API does away with that requirement, opening up the possibility of broad push support across the platform. Some general information around this API can be found here.

If you’ve got an application that could benefit from this, you should consider signing up for the beta program.