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?
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.
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?
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.
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.
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.