A common struggle with mobile devices is the small size applications are allowed to be. Feature phones in particular only allow a few hundred KB to MB for each application. Large applications also impact your wallet when you have to download them. Smartphones and cheaper data plans are helping relieve this problem, however if you need your application to support a wide variety of phones there are some good practices you should follow.

Java ME handsets have the most issues with images, so following some easily automatable rules will make your images work on a broad set of handsets. PNG images are the most common, since it’s the only required image format for the platform. According to the Java ME specification, most PNG features should work, but in reality a number of them do not. Specifically 8-bit transparency is not implemented on all devices. Some devices dislike some of the extra data chunks in PNG files that are not strictly necessary, some other devices will ignore other chunks — for example, the gAMA (Gamma) chunk is often ignored.

So the goods – here’s how we process our images – it makes our apps work better across Java ME handsets, and it makes downloads faster for Smartphones.

• Avoid 8-bit transparency as many devices have little or no support for it. If you need it for a rich user interface, such as on QVGA devices, just understand that you’ll need non 8-bit transparency images for smaller screen devices
• PNG files should be indexed, not RGB. This allows you to shrink the image size by minimizing the number of colors. Eyeball the images as you lower the number of colors and you’ll frequently be able to shrink the file size
• Remove extra data chunks aside from the 4-5 necessary ones. Anything other than IHDR, PLTE, TRNS, IDAT, IEND should be removed. Extremely rarely, a device has been known to require PHYS or BKGD to work properly – these cases are rare enough to handle manually when required
• Ensure the transparent colors are at the beginning of the palette
• Transparency color should ideally be Black, White or Pink. Pink is a usual choice as it is in the middle of the RBG spectrum. Black or white are ideal to minimize transparency problems when background hue is generally known
• Transparent color should not be numerically close (within 0×0F) to a non transparent color – some devices will either render all “close” colors transparent, or not render the transparent pixels as transparent
• Absolutely no duplicate colors should exist in the palette

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.

As we’re all aware, the iPhone represents an exciting innovation in the mobile space. Developers finally have a platform to distribute content that has a widespread audience of techies and casual users. One of the major draws to the platform is the perceived lack of device fragmentation that exists given that one is developing for a very small set of devices in the iPhone and iTouch.

While Apple has done a tremendous job in limiting the level of fragmentation, its inevitable that developers will run into issues as they create content. Keeping some of the suggestions we’ve provided in mind when designing and developing your application will help make your code more portable across the different platforms.

1. Device Simulator vs. Actual Hardware

Its incredibly difficult to create an accurate device simulator that runs on a developers machine, given that the underlying hardware and user input mechanisms are different from the get go. Apple has provided one of the best device simulators that we’ve seen for mobile devices. Given their focus on the generation of unique and compelling content, this shouldn’t come as much of a surprise.

The first thing I noticed was the accuracy and speed at which the emulator operates at. To given an example, the Apple emulator can be loaded in a matter of seconds while RIM’s BlackBerry emulators take quite some time to load and I’ve found the load time takes me out of the development “flow”. They’ve also made it very easy to run the emulators across the different released firmware versions (which is quite useful when you’re trying to isolate firmware specific bugs in your application).

When developing using the emulator versus the device, the following should be noted:

• The simulator does not have an accelerometer, thus making it difficult to test any applications that require those functions
• There are ways to simulate the accelerometer and tie it to the one located inside your MacBook
• The simulator does not provide access to location but it does provide you with a default location thus allowing you to use the API
• The performance on the hardware itself is notably slower than on the simulator. Graphically demanding applications should always be tested on the handset itself to ensure the performance is up to par
• There are several video playback issues
• The simulator does not appear to take into account the case sensitive filenames stored on your MacBook’s hard drive. For example, if you have a test.png in your application, [UIImage imageWithName:@”Test.png”] will work on the simulator but not on the device (notice the capital “T” in “Test.png”)
• I had a custom button with an image:
  

  UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];
  [button setImage:image forState:UIControlStateNormal];

  I tried to dynamically position the button using some computations. If button.frame.origin.x was not a round number the margin of the button will show up fine on the simulator but is chopped of on the real device. The solution was to use the round() function when computing button.frame.origin.x, which makes sense but is something I assumed the platform would have done for me

   

2. Differences between firmware SDK versions

When you develop for a mobile device, the firmware version of the device is often a major factor. One could have different firmware versions for a single device as its deployed across multiple carriers as an example. There are also have some users who actively update their firmware to the latest and others who do not. As a result, one could end up with different builds for the same device for each targeted carrier, because they introduced the device at a different point in time with different firmware versions.

Luckily, with iPhone updating the device is extremely well thought out and easy process from the user’s point of view. A developer typically only has to worry about the current operating firmware and the previous version. While a developer compiles the application, its tied to the version of the SDK so a user with an older SDK will not be able to install it and will be prompted to update their firmware in order to do so.

There are still some issues that you might want to keep in mind:

• If you are not building against the latest SDK, make sure that you are testing the application on devices with previous versions
• There are bugs fixed/introduced in each new version. A few that I’ve run into include:
  − the list of supported fonts is different from version 2.0 and 2.1. I believe some fonts were taken out or the name was changed. My font selection dialog was crashing after updating to the new version.
• There used to be a way to provide a transparent background for a UIWebView in firmware version 2.1…. unfortunately this appears to have been removed
• See the links for additional changes: 2.0 to 2.1 2.1 to 2.2

3. Fragmentation between Apple devices

From a device fragmentation perspective, one should consider the three different versions of devices that Apple supports: iPhone 2G, iPhone 3G and iTouch.

When designing your application you have to carefully choose your feature set based on the targeted audience.

Some additions items you should take into consideration when developing your applications:

iPhone 2G vs iPhone 3G

• Because of the network speed, iPhone 2G is not suitable for streaming applications

iPhone vs iPod Touch

• There is no camera on the iPod Touch
• There is no sound recording mechanism on the iPod Touch
• Location information is limited when using the iPod Touch, and is only available when the device is connected to a WiFi network
• The iPod Touch does support any phone functions
• The 2nd generation of iPod Touch introduced a faster processor: 532MHz (up from 412MHz). This has an impact on applications which are dependent on the CPU speed (mostly games).

4. The Future

It will be interesting to see how Apple tackles the fragmentation problem as they release additional versions of their platforms. The rumored 3rd generation of the platform has quite a few enhancements that will allow for more interesting applications to be created, but may cause issues for existing verisons to run on the handsets. I believe Apple will control this by releasing new versions on a controlled basis and ensuring hardware changes are ramped up over time.

The challenge all developers will face is ensuring that there is both portable and future proof at the same time.

Check back soon for additional iPhone development tips and tricks!

Anyone can develop a mobile application. These days all you need is a little programming knowledge, internet access and a laptop and off you go. At first, mobile development sounds exhilarating, especially around the time when new and exciting platforms hit the market. The iPhone phenomenon is a perfect example. In just a few short months, thousands of developers have jumped on the iPhone application bandwagon. And rightfully so as the iPhone continues to be a massive hit.

Once the initial excitement of mobile development starts to fade out, the diverse set of challenges intrinsic to mobile come to light. The full spectrum of fragmentation in mobile development is experienced most clearly and frequently when dealing with multiple development projects at once and especially when developing for multiple mobile platforms.

Imagine developing several simultaneous applications for the iPhone, BlackBerry, Java ME, Android and Windows Mobile platforms. The numerous complexities surrounding this cannot be captured in a single blog post. How does one manage a mobile development team in the face of these challenges? The answer we found at Five Mobile can be summed up in three simple words: Agile Mobile Process, or simply as AMP.

Agile Software Methodologies have been around for quite some time now and have gained significant traction within both large and small organizations. The concepts are proven to work in both desktop and web development. The Scrum process, for example, is an ingenious way of keeping things visible within an organization with minimal project management overhead.
For mobile, Agile simply makes sense. In a mobile development environment, the four Agile principles are of utmost importance:

• Individuals and interactions
• Working software
• Customer collaboration
• Responding to change

In addition to these core Agile principles, an efficient mobile development process requires a mixture of robust development tools, a well structured and experienced team, as well as the appropriate handset and market knowledge to ensure a positive ROI.
At Five Mobile, the core team, with over 25 years of combined industry experience, have tried and tested Agile for mobile. Both our internal team and our customers have come to appreciate the value of the right mobile tools, high-responsiveness to change, overall visibility and continuous working software. What makes AMP unique is that it’s a modification of the traditional Agile methodologies best suited for mobile development. It’s a mixture of both traditional and Agile principles with an emphasis on portability and cross-platform code management.

In upcoming posts we will touch on different aspects AMP and we will look at some real world examples where our process is validated both internally and externally.

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.

Hi everyone, welcome to the Five Mobile Blog! We’ll be using this as a vehicle for communicating some of our thoughts on the mobile industry, our experiences with the different development platforms we deal with and of course, the latest news at Five Mobile. This also serves as the official launch of our re-branded website. Tell us what you think!