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

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

Read the article here.

Just a quick note to let everyone know that we’ve launched Score Mobile for BlackBerry today. Check out the press release when you have a moment, and *definitely* go download the application. Download it here! A lot of hard work went into this, and we’re proud of the end result!

As we outlined, Mobile Web apps have their advantages in terms of cost and broad device reach, however they lose out on the ability to access device hardware and don’t get the presence on App Stores.  There is a compromise that lets you take a bit of both worlds.

1. Develop your mobile web application.  This can be done for as many or as few devices as you’d like.  This application should take advantage of the rich browsers in iPhone/Android, BlackBerry 4.6+, etc. as well as offer a solid WAP experience on feature phones.
2. For each platform you really want to make your application shine, you would develop a native “Shell” application which is nothing more than a window into your Mobile Web site, utilizing the platform’s native web UI component/widget.

This gives you the following benefits:

1. Ability to hook into the native features of the device, such as GPS and Camera, passing information to the mobile web app as suitable.
2. Ability to list your application on the various App Stores, increasing your application’s presence in the market.
3. The flexibility of having a mobile web app – it can be updated on the server in a moments notice without requiring the user to update the installed application on their device.
4. Simple, quick development of a mobile web site, reaching a broad set of devices in advance of having a native application completed for various platforms.
5. Easy transition from mobile web to hybrid app when desired – you can push out the URL for downloading the native shell application when the users open your mobile web site
6. If you’re seeing huge uptake on a particular platform, you can always decide to move the application more towards a conventional full native application – taking advantage of caching, snappier UI changes, animations, etc.

So this is a “Hybrid Application” – a perfect combo of mobile web and mobile app, giving you flexibility and power to develop your application in stages, growing as your number of users does.

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.

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.