aspose file tools*
The moose likes Applets and the fly likes Offline applet limitations and practices Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Applets
Bookmark "Offline applet limitations and practices" Watch "Offline applet limitations and practices" New topic
Author

Offline applet limitations and practices

James Hollier
Greenhorn

Joined: Jul 27, 2009
Posts: 19
I've written an applet or 2 prior and am aware of the security and resource limitations from that experience. But, I do not recall much in regard to running the applet while Offline from the server and that is a prime requirement for my new project.

Can a user hit a URL that launches an applet while their is NO network connection? I assume if the applet is resident from a prior download then it will startup normally and the user may not even be aware of whether a connection exists or not, correct? Naturally, the applet code would take extra steps when a connection exists to download and upload app data.

Are there any other gotcha's I should be aware of in regard to design/development of an applet primarily used for Offline processing?

Many thanks,
J
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
I assume if the applet is resident from a prior download then it will startup normally and the user may not even be aware of whether a connection exists or not, correct?

While that is easy enough to test, it also seems highly browser-dependent, if it even works.

Java Web Start applications, on the other hand, are designed to be independent of the server, and can be started from a web page in a way similar to applets. I think that would be a much better approach for the scenario you're describing.

Something else to check out is the capability of recent Java 6 versions to have applets dragged from a web page to the desktop where they can run independently of the browser. In that state they might work w/o server interaction and be restartable.


Ping & DNS - my free Android networking tools app
James Hollier
Greenhorn

Joined: Jul 27, 2009
Posts: 19
I researched and thought about this further given your input. Also, I spoke further with the client to understand his requirements better. He wants an existing home grown Java-based Html/JS forms engine to operate while offline.

Currently, administrators use these forms online to manage patient data and insurance claims. Now he wants various workers (nurses, etc) in the patient's home to perform data entry without access to the network. This solution currently runs online using Glassfish/SqlServer. Each form is defined via metadata in the database and his Java forms api returns the Html and JS for each page rendered by JSP.

Naturally, running in offline mode needs to preserve rendering of the page and JS processing...so we assume a browser would be required. If we install Glassfish and a database on every nurse's laptop then obviously they can run the forms and the only changes required would be data synchronization with the central server.

But, we'd rather NOT have to manage an app server/database on every laptop (ie more moving parts, more problems). What is the Best Practice for this scenario? How does a User still use a browser while offline for data entry without a full-blown app server to serve these requests/responses?

Can a JWS app act as a server to a browser? If so, the JWS app could leverage his forms api and other classes already included in his online app, to process requests from the browser. Do you follow?

He also was curious how an iPhone would accomplish this data entry for nurses who would potentially use the iPhone versus laptop in the field?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
That sounds like a use case for Google Gears.

Another option might be to create a double-clickable desktop app that starts an embedded servlet container (like Tomcat or Jetty) and a server-free DB (like HSQLDB or Derby). (I'm assuming that the app can run in a servlet container; if not, you'd have to embed GlassFish - doable, but still more complicated.)

Then the user would still have the same web GUI they're used to, just running at a different URL (at localhost). You'd have to think about data synchronization, though.

I don't quite follow the points about the forms api/engine, so I may be missing something about that.
James Hollier
Greenhorn

Joined: Jul 27, 2009
Posts: 19
What I mean by the home-grown forms api is I can do the following currently in .jsp:



So, I don't really need the JSP and servlet features at all since the entire form and dependent JS are given to me by the PatientForm POJO class. Obviously, embedded in there is an action to a specific service to send the data collected to.

From a JWS app I could leverage the same PatientForm class and send the response to a local browser...naturally this JWS app would be responding to the strict subset of actions and resources needed specifically for our targeted offline forms by the local browser.

If a JWS app can serve these basic HTTP requests from the local browser, then the other area we'd need to address is the data persistence/sychronization with the central server. But, that aspect is nicely independent of a UI solution.

To sum up, we'd rather NOT have a full-blown app server on every field device which could be hundreds...we just went thru hoops lately to make the app multi-tenant in order that our central server instances and databases are a minimum, for overall ease of maintainence.

It appears unless a custom JWS app can handle these basic HTTP requests given our forms api, then we're back to multitudes of infrastructure deployments to support. Do you see any reason why a JWS app could NOT successfully satisfy simple local browser requests as I describe? Is there an API that would lend itself to a JWS app in order to help with the HTTP services? Hope this makes a bit more sense now...

Since the Google Gears is purely a client-side component, I don't see a good fit here unless you wanted to write something from scratch. We are trying to leverage the forms engine we already have.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
It appears unless a custom JWS app can handle these basic HTTP requests given our forms api, then we're back to multitudes of infrastructure deployments to support. Do you see any reason why a JWS app could NOT successfully satisfy simple local browser requests as I describe? Is there an API that would lend itself to a JWS app in order to help with the HTTP services?

A JWS app could indeed serve as a local web server; in fact, it could have an embedded servlet container and DB as well, like I suggested above. That would most likely be easier to develop than to come up with a custom/lightweight HTTP server on your own.
James Hollier
Greenhorn

Joined: Jul 27, 2009
Posts: 19
When you say embedded, I can take that 2 ways: 1 - an app server is installed on the laptop or 2 - the JWS calls an http api directly and there is NO separate app server running. Which are you referring to and can you provide a link to such an api?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
I meant #2 - the server would be part of the JWS app. Googling for "embedded XYZ" -where "XYZ" is your choice of server- will get you started:embedded tomcat embedded jetty embedded glassfish
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Offline applet limitations and practices