Are there any "best practices" on cross-device development?

Question

Developing for smartphones in the way the industry is currently doing is relatively new. Of course, there has been enterprise-level mobile development for several decades. The platforms have changed, however. Think of:

• from stylus-input to touch-input (different screen res, different control layout etc.)
• new ways of handling multi-tasking on mobile platforms (e.g. WP7's "tombstoning")

The way these platforms work aren't totally new (iPhone has been around for quite awhile now for example), but at the moment when developing a functionally equal application for both desktop and smartphone it comes down to developing two applications from ground up.

Especially with the birth of Windows Phone with the .NET-platform on board and using Silverlight as UI-language, it's becoming appealing to promote the re-use of (parts of the UI). Still, it's fairly obvious that the needs of an application on a smartphone (or tablet) are very different compared to the needs of a desktop application. An (almost) one-on-one conversion will therefore be impossible.

My question: are there "best practices", pitfalls etc. documented about developing "cross-device" applications (for example, developing an app for both the desktop and the smartphone/tablet)?

I've been looking at weblogs, scientific papers and more for a week or so, but what I've found so far is only about "migratory interfaces".

Answer 1

What you are talking about is essentially building a family of products that use a common code base. I disagree with premise that you would have to re-write a large part of the code base for different platforms. Sure there are going to be platform specific areas, but by in large this shouldn't affect the common code base.

The basic premise or practice that provides the most usefully insight into cross platform development is the concept of design for change. At a most fundamental level, you need to identify what areas are likely to change and/or areas that you know are going to change. In your case, I can identify four areas that fall into this category.

• User Interface
• Hardware Interface
• Operating system Interface
• Varying Feature Sets

The first three are definitely platform dependent. The forth one in my opinion is more of a configuration thing, but it is still important from a design perspective.

The first three are pretty easily isolated by abstracting each interface behind a common interface. For example, you should have an abstraction layer for operating system services such as semaphore control. The interface should be the same from the common codes point of view regardless of the operating system that you are using. Essentially, the idea is to create virtual interfaces. Honestly, this pretty much defines the Adapter design pattern. I realize that you are not looking for design patterns specifically, but often times design patterns solve many of the challenges involved in designing a product for multiple platforms because they specific support the notion of design for change.

To tackle the concept of varying feature sets it is important design features that have low coupling with other elements in the system. For example, in a word document, the save option should not depend on the fact that the open file feature is enabled. You should aim to make disabling features as easy as stubbing out the interface. At this point building with a specific set of features should largely be part of your build configuration. Based on what product you are building you can decide weather or not to include a given feature or a stubbed interface. This just one possible solution. I am sure that there are other ways to do this, but concept is the same.

Answer 2

I'd say the one biggest thing for me is adopt Model-View-Controller. Taking Windows/.NET vs Windows Phone/Silverlight, */JavaSE vs Android/Java or Mac/Cocoa vs iPhone/Cocoa Touch, a good MVC application can use the same model objects and the same domain logic on multiple platforms. The views and code to interact with them need to be specific to each situation, but when that code is well-contained it's easier to maintain multiple versions.

Secondarily, test for features, not for platforms. What I mean is, don't do this:

if (device == phone) {
  // small screen resolution
  // touchscreen UI
}
else {
  // desktop screen resolution
  // WIMP UI
}

...because at some point, this will start to fail. Either a phone with a high resolution (e.g. the iPhone 4) will appear, or a larger device with a touchscreen UI (e.g. the iPad) will.