Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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".

share|improve this question
    
An interesting read in this context is maybe the iOS Human Interface Guide. Though not specifically design practices, there are two case-studies there for porting desktop-apps to another device. –  vstrien Feb 24 '11 at 8:41

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
is being remembered of "the Pragmatic Programmer", practice 8 (orthogonality) and practice 26 (Decoupling and the law of Demeter) –  vstrien Feb 24 '11 at 8:21

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.

share|improve this answer
    
+1 for "test for features, not for platforms". –  Frank Shearar Feb 23 '11 at 11:35
    
Very informative. However, what I meant wasn't just reusing the codebase - after all, you don't want all the feature tests in your deployed packages and it's likely that your smartphone / tablet app will have only a subset of the features of your desktop app, so I think it's necessary to re-write large parts of your code anyway. What I'm looking for is design practices. I'm developing on (for example) two devices. What can I take into account now to do (or not do) that will make the overall "twin-development process" easier? –  vstrien Feb 23 '11 at 11:55
    
@vstrien: MVC is design. –  user4051 Feb 23 '11 at 11:58
    
You're right - maybe more of a pattern than a practice, but that's a meta-discussion that doesn't add value to the thread IMHO. I just try to point where my question lies. (I'll upvote as soon I've enough rep around here :-)) –  vstrien Feb 23 '11 at 12:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.