How would you design an application with many target platforms and devices?

Question

I'm in a very beginning of the design phase of an application that will have to run in the following platforms/devices:

• Desktop: Windows, Linux & Mac
• Mobile: Android, iPhone/iPad & Windows Phone 7
• Web: Silverlight

I will use C# on Mono and I want to maximize code re-usability.

Except for the desktop (I'll use WinForms/GTK#), my concern is related to many different GUI that I will face.

What would be your approach? Obviously, the views will be different, but what about the controllers, data access, utility classes, etc. Is it really acceptable to share everything but the views?

Answer 1

I would start the web app first, so you can get a test/beta site to multiple users as fast as possible. It's about the easiest way to distribute. Find out what people want out of the core functionality of the apps. Whatever you release first, is going to have the fewest features.

Along with the website you may want to consider a web service if there is going to be a need for centralized data that has to be shared to all devices. If so everyone is going to want to be able to store local and synchronize.

Other than the obvious differences, I don't think there is a lot of functionality you would have on a website that couldn't be done on a desktop app. If you start with the desktop app, you run the risk of giving users features that they want only to be taken away when they go to the website. It won't be perfect, but it will limit this issue. You may find that people would prefer to have it on their phone instead of/before a desktop app.

If I knew the nature of the app, I could be more specific. Having multiple devices may help grow the client base. An API would allow developers to provide customization which would be beneficial if you clients are larger companies needing enterprise software.

Answer 2

I would take the approach that I would follow DDD principles, building a domain layer that contains all the domain logic for the application. The domain layer would be common between all platforms.

I would probably write individual GUI implementation for each platform. When you talk about the controllers, I consider these to be part of the GUI implementation, because different GUI frameworks tend to advocate different design architectures. E.g. the controller you would write for a WPF application would be very different from the controller you would write for an iPhone application. And since I believe that you would be using WPF for Windows Phone 7, then I think that reusing the controllers between these two platforms will be more pain than pleasure.

Also, the controllers often reflect how the view is build, and you would build completely different views for mobile devices than you would for desktop computers due to the size of the screen, and the means of input (touch vs. mouse/keyboard)

In regards to data access, then I would say, it depends. If it doesn't feel awkward to reuse the same data access code between a Windows phone implementation and an OS-X implementation, then by all means do it. But if it starts feeling awkward, don't.

The key here is to have solid IOC principles in place, allowing you to easily change the data access implementation without affecting the implementation of the domain layer.

Answer 3

Try to do something like they do in osdev to develop an abstraction layer, simply define a set of interfaces that define the methods that you would use in the upper layers (domain, controllers, etc.), and a implementation of those interfaces for each of the real platforms, if one platform is significantly different than the other for the same interface.

For example, imagine that you wanted to have an input area, that the user can input some text, then you could define an interface that has methods to allow you to read keys from the "keyboard", and you could use that interface, that is created using an factory (that could bind the interface in a static way, i.e. in the compile time, as part of the compilation routine, an define is set, that selects the code of the factory that corresponds to the architecture that you're compiling; or in a dynamic way, i.e. the factory determines the platform it is running on, and returns the correct implementation for the interface in that platform). And them you can create an implementation for the desktop, web and mobile in that the mobile version, could be used together with an virtual on-screen keyboard or not, whether an physical keyboard is present or not, and that would be two different interfaces for two different types of mobile devices, and your portable code would only be interested in getting characters to fill in the text area.