5

The company I work for already has a fully functional web app that is written in java using JSF framework. I'm now in the process of creating a mobile version of this web app and having some general questions on where to put this mobile web app.

  1. Should this mobile web app be a separate project, packaged in a different war, and installed as separate app in server or should it be part of the existing web app, packaged in the same war, and installed as same app in server?

  2. Should the mobile web app uses existing web app's jsf Manage Beans? For example, we already have an order entry app that consists of several jsf Manage Beans and jsf pages. To create the mobile version of this app, should I simply create new mobile version of jsf pages but uses all the exist jsf Manage Beans in those mobile jsf pages? Will I run into problem because mobile web app's page-flow might be different from the web app's page-flow? But if I don't reuse, it seems like there will be a lot of duplicate code.

  • 2
    (1) really depends on your architecture (which is just glossed over). There are arguments for each. (2) suffers from the same lack of information as the first question. – user40980 Jun 24 '15 at 19:24
  • The existing web app has three tiers, front-end tier, controller tier and a back-end tier. The front-end tier uses jsf2.2 frame work to create web ui. This front-end tier communicates with a controller tier, a EJB app, that does nothing more than passing info to a back-end tier, which contains all the business logics. – HockChai Lim Jun 24 '15 at 19:32
  • Rather ask for arguments (or pros and cons) of each question (1,2). Once you see the pros and cons of each approach, "the should" would be the one suit better into your project's life cycle management. It's not a mere technical question, there are also implied political issues. – Laiv Oct 3 '16 at 12:37
1

Depending on the architecture your current web app is using. When dealing with multiple channels like in your case, it's recommended to have a core system that manages business logic and data access. On top of it, you would stack your thin clients like web app, mobile app, android app, etc...

I would say if you can, refactor the web app as much as you can to separate the business logic and presentation layer. Then utilize business logic layer as a common, while maintaining two different projects for the clients.

  • Yes, the existing webapp already has a front-end tier that deals with web ui, and a controller tier that passes data to a back-end tier, which contains all business logics. My concerned about creating it as a separate project is that I'll have to duplicate a lot of JSF manage beans. But not separating them also has its own problem. – HockChai Lim Jun 24 '15 at 19:37
  • If you have to duplicate, your architecture is not perfect(well, obviously, there is no perfect applications out there). I would work towards separating the common components into separate libraries and maintain them separate. I would still keep it as a separate project, as it is a separate project. The moment you merge them, you will bury yourself into a monstrous maintenance hog. – Alexus Jun 24 '15 at 20:28
  • Presentation level frameworks tend to have a lot of boilerplate code in them... I don't tend to view this as "code duplication" even if it technically is duplication. If the business logic is segregated as you note, I'd almost always choose separated presentation projects over a merged one. Merged presentation projects have far too easy a chance of turning into an unmanageable nightmare a year or three from now... – jleach Sep 27 '17 at 20:14
0

(1) depends on the intended life cycles of your web app and the mobile version of the app. If you give both always the same version number and deploy them both always simultanously, it makes more sense to keep them in the same project. If the life cycles are somewhat different (for example, you create a new version of your mobile app every 3 months, but a new version of your web app every day), then it is better to keep them as different projects.

(2) depends on (1). If the life cycle of both is the same, it will be probably much easier to have shared components, since you can always use the same version of those components. If the life cycle is different, reusing your "Managed Beans" is not impossible, but will probably need much more care and configuration management, so you do not run into problems when a older mobile app version accesses the same data produced with a newer version of your Web App.

0

Depends on a lot of factors, but essentially:

If you have written the web app or have a lot of experience with it OR that web app script is built with the logic/etc (rather than being a thin client calling an API) it might be easier for you to have it feed different displays and use the same logic.

However, if the app is server/client based (where the web app acts as a client speaking to a service/server through an API), it is probably much easier to start a different project and modify the original web app to redirect to the mobile web app. If everything's written with a decent framework, you might find you can handle all of the mobile/desktop display stuff through HTML/CSS/JS with minimal backend changes.

Personally, I've never written a web app where the desktop/mobile are handled in HTML/CSS/JS with the exception of when I was trying Foundation by ZURB, do note with Foundation that it's a nightmare to convert a site to Foundation as the whole idea is to design for mobile first and scale up to desktop (which is much easier than the other way around).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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