Code Away

Traditionally, the most convenient way for web developers to buzz the user with a message has been the javascript alert() pop-up. It is convenient to code and ensures that the user doesn’t miss the message (no way to go back to the page till the user clicks OK or whatever prompts you’ve coaxed in)

Today this very pop-up is a major hassle for users, just because in multi-tabbed interfaces, the user cannot switch between tabs when an alert is displayed to him. So you have an irritated user who wants to urgently book a flight in the next page, but is stuck on your tab because you have provided some text for him to understand and press OK.

This is still ok when the alert is shown on the press of a button. There is a higher probability of the user being still focussed on your page. But alerts on page load, notifying “Successfully performed operation” are nothing but rot.

To grab user attention while user is on your page, a far more elegant way is the use of div based message boxes. This keeps the user interface consistent with the remaining website and also grants user space for some other (possibly precious) activity. The new CSS opacity attributes also let you gray-out the page background whilst displaying your error — pretty neat.

While you are proceeding towards unobtrusive interfaces like a good kid, why not also give a thought to what ought to be the messages warranting a pop-up? Oracle ADF, which we use for development, has 3 levels of messages:

• Info, Warning: Display at the top of the page with appropriate icon
• Error: Display as a div based pop-up to the user, gray out the remaining page, ensuring the user cannot perform any activity till he selects an option to handle or acknowledge the error.

The good part is that the behavior of messages is built into the framework. So if tomorrow a usability test suggests that warning messages better be shown as a popup so the user doesn’t miss them, there’s a 3 line change in the framework to enable this. Clean, easy, cool. That’s the way we want it.

Opacity, Shadow and Rounded-corner control over rendered objects make CSS3 exciting stuff. Imagine creating a beautiful website with all these features, without using an image editing program! (ok, throw in @font-face and you have the font of your choice on the webpage as well. That’s it. Image editing is out)

Its safe to assume that not all developers will be using these features for mainstream websites unless our very dear IE supports them. So we still have time to see these beauties in action. But we have a lot of gray area for what happens when these are used together. The implementations are still juggling with these questions.

For example, what happens when opacity of a box is 50% and a drop-shadow attribute is used for the box? Or, what happens when a shadow drops on a box which is having less opacity? Should the shadow have rounded corners for a box with rounded corners? How should a shadow with bigger fade (black to transparent area) render on a shadow with smaller fade?

These are just some tricky “beginner” questions with no straight answers. Fortunately the community is pretty enthusiastic about rendering these effects with markup. Lot of such issues and fundamentals have been discussed.

In an image editor you can manipulate the effect rendered depending on which operation you perform first. This is not really clear for CSS, and with browser implementations which can vary, it might be a bit of a hassle for us to have consistent cross-browser CSS3 markup ready to use.

For I/O newbies in Java, the big question comes is which of the methods are to be used for I/O read/write. Anyway, unlike some other languages, Java insists on using the “explicit” way of coding:

Code for Python (Write to file)

f=open('scratch','wb')
for i in xrange(1000000):
f.write(str(i))
f.close()

Code for Java (Write to file)

File f = new File("scratch");
PrintWriter ps = new PrintWriter(new OutputStreamWriter
(new FileOutputStream(f)));
for (int i = 0; i < 1000000; i++) {
ps.print(String.valueOf(i));
}
ps.close();

Discounting the mandatory include statements for java.io, class name, try catch block for any and all I/O operations, we are still left with around 4 classes to be used for 1 write operation to a file.

So the question newbie posts in a forum is: I am writing to a file, but I’m not sure whether I should use BufferedOutputStream or BufferedWriter

The reply generally holds this: If you are inserting chars, use a Writer, else use the Stream

This is fairly accurate, but for a slightly deeper understanding let us break down the modules

Streams transfer bytes. Period.

So when you want to transfer any binary data, you use streams. You open the file, wrap it with FileInputStream, take out the data and process it. When you save it back, you make use of the FileOutputStream. Similar classes to be used for transferring though other streams.

In case you would like to use some text-friendly methods for your ascii text, you need chars or a char[] array. To get this, you convert bytes to chars while reading (and similarly chars to bytes while writing), with a simple wrapper, which happens to be InputStreamReader for reading and OutputStreamWriter for writing.

To have data formatting conversion done by Java, wrap the Writer objects in a PrintWriter

To increase performance, you wrap the objects in a buffer. Java uses internally allocated memory space to provide efficient read/write operations. The working of the buffer is transparent to the programmer, except for few methods like flush()

(Any) OutputStream => (wrap in) BufferedOutputStream

(Any) InputStream => (wrap in) BufferedInputStream

(Any) Writer => (wrap in) BufferedWriter

(Any) Reader => (wrap in) BufferedReader

The Buffer classes also provide some friendly methods: readLine() in BufferedReader and write(String, int, int) in BufferedWriter. These are more of a convenience which can be coded anyway in 2-3 lines. In case your app can’t afford to wait for the buffer to get full before transmitting or receiving data, it is always better to avoid using Buffers than to use and flush() them throughout your program.