Managing a web application project with multiple viewing modes

Question

What is the common practice to handle developing a web application that needs to be implemented in multiple viewing modes, i.e. desktop and mobile/iphone?

Is it better to develop multiple applications for each mode or try to keep all the code in the same application? Does it make a difference if all the page functionality is the same (i.e. sometimes mobile versions can't "do" what their web counterparts can)? What are some of the criteria to decide whether to split the app into multiple projects, gotchas, etc? Are there any specific architecture patterns that make the job easier?

It seems to me that unless the application can simply be presented in the different views, it's better to create a separate application for each one.

Assume the application is similar to a Gmail or Facebook (larger app with multiple functionality), not a simple hello world type or static corporate website.

I'm currently using Grails for development, but this can probably apply to multiple frameworks.

Answer 1

You should build the back end as a web service. This means that any UI can interact with the service and presentation logic is separate from business logic.

For Microsoft platforms, ASP.NET MVC or ADO.NET data services are good options here to start off with. The presentation layer should be separated out into a different project altogether to ensure that it is independent of business logic.

But it should be just as easy to do it in other platforms using a RESTful approach.

Answer 2

As mentioned above seperation of concerns is important.

Following that, whether to build seperate presentation / application layers is really a decision that should be made based on different parameters (i.e. resource, time, cost, scalability etc).

I suggest investigating the MVC / MVP design patterns, seperate your presentation logic from your business logic and consider how your application is going to be represented across each platform and where best to invest your time and money.

Answer 3

You definitely do not want two applications. Try to separate the business logic and controller logic from the view.

Depending on the complexity of the application, the difference could be as little as an additional css file with media type "handheld" to a separat back end web service (as answered above). In the middle is to have all of your server code following the pattern

1. Gather requirements
2. Run business logic, storing value to view somewhere
3. Figure out which view to use
4. Generate the view

This works particularly well for systems that used a templated view (JSP, Rails, etc.), but could be done for PHP as well.

A back end web service is a good idea if you are likely to have even more displays for the web site, if the front end works well with web services, or if the front ends are being developed by separated parties.

Answer 4

1) Central database for everything

2) One, central business logic layer. This could be web services, javabeans, etc. There might be web-only or mobile-only business logic. That's ok, leave it all in one place.

3) Multiple presentation layers. The web presentation layer would call web services and generate for a regular browser. The mobile presentation layer would call the same functions but present them optimized for mobile use.

If you made multiple projects, fixing one bug, or putting one feature in would mean you would have to do it in two different sites, thereby doubling your building and bugfixing time.

Alternatively, you could leave everything "under the covers" the same at the business logic tier and let people see different presentations of that business logic as a website, or mobile site.

Hope that helps.