Planning the development
The process of developing swingweb application is not much different from developing swing desktop application.
Nevertheless, since the target user is web user and the target platform is web-container, there are several technical
considerations that need to be attended:
- Resource requirement
Swingweb application tends to have higher resource (memory) requirement than traditional page-based approach
(e.g. jsp, struts) because the components in the application lives through the lifecycle of the application
and keep track of a lot of data (component size, height, position, label etc). Also, for non share-app application (refer to
section 3.1 for when to use share-app mode), for each user that access the application, a separate instance of the
application will be created.
Given the limitation, swingweb approach is only considered significantly outweighs traditional
development in these scenarios
- The number of users that connect to the web-application simultaneously is bounded
e.g. a CSR web-application that is accessed by at most 100 internal CSRs at any given time
- The number of users that connect to the web-application simultaneously is unbounded,
but share-app mode can be used
- e.g. a B2C e-commerce application where >10,000 users accessing the same instance of the application in share-app mode
-
Hardware resource is abundance and rapid development to changed requirement is the ultimate goal
-
Prototyping of application
There are additional benefits of swingweb approach that should be put into consideration:
- The development process are significantly faster than page-centric approach
- The functionality of the application are less bug-prompt than traditional page-centric approach
- The components become reusable asset of any future development
- Less learning curve for developer as most developer knows swing
- Architecture requirement
Most of the desktop applications are single-user application with very simplistic architecture (e.g. simple persistence to a data file).
With swingweb application being on web platform, it is very likely the application will have a more structuralize architecture (e.g.
using j2ee architecture). So it is useful to first conceptualize how the UI model can interact with a middle layer that accommodate
the infrastructure layer and make sure it is technically feasible. Also, the challenges will increase as the development tries to
incorporate the development of desktop application and into the swingweb application development.
- Usability requirement
While swing component model is a rich-client component model, a lot of components such as menu, dialog
would not be very natural to common web-user. So, there must be some considerations to ensure the
end product will meet the expectation of the target audience in terms of usability. This would also be
the major principle for the user interface design for swingweb application.
Another potential issue will be the limitation of swingweb application to allow the use of the browser "back" button (back button
won't work well for swingweb application).
- Deployment requirement
Currently swingweb default implementation supports recent releases of Mozilla based browser and Internet Explorer.
Certain level of support for javascript and CSS is needed for swingweb application to behave correctly.
Nevertheless, it is possible to make swingweb supporting older browser by simply fix some templates for components
that break in legacy browser.
It is crucial to evaluate the above requirements to conclude whether swingweb is the correct technology choice for the development.
Deciding deployment type
A typical swingweb application development process consists of the following:
- Developing the application
The developer uses his/her favorite GUI tools to flesh out the application components and that wire the business tier with the UI components.
- Testing the application
The developer tests his/her application in desktop mode or in swingweb mode.
- Customizing the templates of the components
The developer attaches some templates to certain components if they want to tweak the
way the component looks (e.g. changing how container layout its children totally - using template).
- Deploying the application
The developer deploy the application
While deployment come at the last, it is very important in the early stage to decide what kind of deployment the application will use as it will
have major impact on the application development (as explained below). There are a few types of deployment scenario that supported by swingweb:
- Single instance per session
This is probably the most common case for application, where each user client (web-browser) access to their private session of web application.
An example of this is online mail client where each user has their own instance of the mail client to view/compose their emails. This type of
application is very similar to the desktop application development thus is the easiest to develop in swingweb.
- Multiple instance per session
This is very similar to the first type of application above, except that the user can choose to start multiple instances of the same application.
An example would be like the "notepad" program on windows, where the user can start multiple notepad to read/write multiple documents. This is actually
fairly easy to achieve this functionality by providing an application launcher (e.g. like a "Start" menubar) to launches/manages multiple application instance.
So in terms of development this is as easy as (1).
- Single instance for all sessions (aka "share-app" mode in swingweb)
This is probably the most unnatural thing in swingweb to most developer, as it is hard to imagine how a single instance of an swing application be shared by many users.
The reason that "share-app" mode exists is to allow "economies of scale". Image an online shopping mall type of application where most of the product pages that the user
will view would be the same. It is wasteful to have created a copy of the product pages (read "a set of components") over and over again just for the every user visiting
the page. It make more sense to share the components and this is exactly what "share-app" mode is about. As good as it sounds, the "share-app" mode require special attention
and consideration on the application architecture itself. For this reason, it will be discussed in detail in a several sections in Chapter 3.
Except for "share-app" type of application, the other type of application development should pretty much be the same as the desktop one.
Nevertheless, they are few important things that the developer should understand/know, which would be explained in next sections.
