Interactive applets & the oj (hello Java) user program template

primitive i/o applet (1) oj i/o applet (2)

Fileage:
priIo.jar: (1) archive* file
priIo.java: (1) Java pgm code (plain text)
ojQ1.jar: (2) archive* file
ojQ1.java: (2) Java pgm code (plain text)

*(.jar format info)

Note re: multiple i/o applets (those having device Listeners) on a single web page -

Observe as in the 2 applets here, that the mouse Listeners of both (all) are operative simultaneously, since directing to processing of a click is checked for & confined to the applet space boundaries prescribed for all applets in their respective html Applet tags, or any subsequent programed setSize() Java method calls.

The directing of keyboard input, however, has to be determined by which applet has been given the "focus", which defaults to the last application opened, unless arbitrarily assigned to a particular applet by clicking on it somewhere with the mouse or, in this case, by using a requestFocus() Java method call (since Java 1.4 this method has been deprecated and the more broadly effective method requestFocusInWindow() substituted). These 2 applets use a requestFocus() call in the paint() method, which is run automatically when the applet is refreshed for some reason, or, in the case of (2), is called by the applet code when the mouse is clicked somewhere inside the applet borders, but outside the designated mouse input "button" field area (not readily noticeable here; but you can make the "Here we go again -" message vanish). So, when this web page is browsed, the requestFocus() call transfers key input from the browser menu to applet (1) just momentarily, before applet (2) is loaded when it calls for & gets the focus. Then, if a key is hit immediately, it is sent to applet (2), otherwise clicking on either applet transfers the key focus to that one.

Limitations:

Applets are a great vehicle to take advantage of the web's outreach, and they offer a lot of capabilities that can be developed to suit the needs of the occasion. The oj template program above is like a minimal implementation & is lacking in a few areas (the to- do list). It's designed as a single- class, marginally event- driven (mainly in accordance with Java's repaint provisions), structured (flow- oriented vs object- oriented), integer only, pause for input automaton; which gives it some strengths in operability Java- wise, but makes it tricky to revise and diagnose (the case layout in the rdyItm() sbr of the Arms Reach game is some serious spaghetti, and an interruptable timer for input with blinking unit markers is being added in the upcoming Aggressor wargame, not to mention the potential eventual extension to multi- player games). But, for the simple- (sorry: "single-") minded, it can provide an entre into user functionality.

For those wondering about the performance aspects of Java, it may be noted that if an applet is run with a call to a .jar file, which is the default format for the contents of this site, the execution will be slower than that of an applet run with a call to the .class file directly. However, in the case of the frequently paused text- significant programs generally presented here, there's no noticeable lag.

AWT options:

Note that these examples are of the very basic GUI coding variety, using Java's Abstract Windowing Toolkit graphic statements. Employing the Swing layout package incorporated in Java, which "paints" its own components, is at the other, high end of the spectrum of interactivity. An interesting in- between capability is to hijack the components which are effected by your software's particular operating system GUI for placement into a Java panel: get a clue.