EJB 3.1 calendar based timers

I attended Ken Saks' session on EJB 3.1 at JavaOne, and found it quite interesting, mostly because I tend not to work on the back-end of applications, since I'm more of a GUI / component developer, so it was informative to me. But one thing immediately leaped out to me, which was the ommission of time zone and locale parameters for the new calendar based timer functionality. I've worked on calendar and time entry components, in JSF and Swing, and I can tell you that it's a typical oversight. So, I'm partly writing this, to hopefully influence the EJB 3.1 team to include it, but partly to raise awareness of this issue in general.

I'm going to start with a simple example, taken from page 38 of the PDF of slides, from the session, now available online.

ScheduleExpression expr = new ScheduleExpression().dayOfWeek(“Mon-Fri”).hour(12);

This should make a timer go off at noon every week day. The example uses hard-coded values, but most likely those would be input by a user in some configuration GUI, or by editing some configuration file. In any case, a human would enter those values. And what that human would probably think is that it would be noon, in their time zone. Perhaps they're working in a branch office, so they might think it should be in the time zone of their head office. Unless instructed, they wouldn't know which of the two it may be. To further complicate things, the server, on which that application is deployed, may not even be in either time zone, as it may be co-located elsewhere, maybe in one of those "safe" places that don't flood or get earth quakes. In that case, they would have no idea, and would have to use trial and error. And those are just the mostly likely scenarios. Add on the possibility of distributed applications, with beans executing in containers around the world, or failover servers intentionally geographically dispersed, and we see that this could actually be impossible for a user or developer to account for.

There's also the lesser issue of daylight savings, where some people need to schedule activities that respect daylight savings, and some people need to ignore daylight savings.

While being able to use "Mon" and "Fri" is a usability gain for most people, it ignores the fact that different locales use different starting days of the week. Some places begin with Sunday, others with Monday. In those cases, people want to be able to just give an index into their week, respecting when their week actually starts. Especially for large organisations which have branch offices in varying countries.

Finally, there's the issue that we're all still assuming the Gregorian calendar. There are many countries which do not use the Gregorian calendar. Almost the entire Middle East does not.

My recommendation is to look into java.util.Calendar, and allow for all of the parameters that it requires. And then add in syntactic sugar.

Mobile application component considerations

http://www.michaelyuan.com/blog/2007/09/25/jsf-and-mobile-web-applications-part-1-what-looks-good-on-paper-doesnt-always-work-out/

I was reading this guy's article, and more importantly the readers' comments, about writing JSF applications for mobile applications, and thinking about what ideas best fit with ICEfaces. And that led me to think about some other articles I've read, including one by Ted, a co-worker of mine.

http://blog.icefaces.org/blojsom/blog/default/2007/09/07/Ajax-on-the-iPhone-with-ICEfaces/

The problem is that you can't really write once and run anywhere a web application, with a sophisticated user interface, simply due to screen real-estate trade-offs. If you have a large screen, then you'll want to make more of the interface available to the user at a glance. There's a psychological limit to that though, creating an upper-bound on what you can have in a web page, even on a 30" display. Unfortunately, there's a lower-bound as well, so we can't just target mobile browsers with small screens, and expect desktop users to be happy. So, I'm going to look at ways of addressing this, from a component writer's perspective.

A few differences between desktop and mobile web applications are:

Complexity of the user interface

Showing the user less information, and asking them to do less work, at a time. This can be accomplished by breaking that page into several pages, like a wizard, or by relying more on drill-down detail pages to show successively more detail.

The problems is that you then have to have parallel page hierarchies, which have to be kept in sync as your application evolves.

Another approach is to remain with the single large page, but use intra-page data hiding, so that all of the data is on that one page, just not necessarily at the same time. For example, you could use an <ice:panelTabSet> component, or an <ice:menuBar> in conjunction with an <ice:panelStack> to create sub-panels, where only one will be shown at a time. And the switching will be done via Ajax, without disturbing the rest of the display. Or, better yet, you can use several <ice:panelCollapsible> components, where all of them could be expanded at once, for the desktop user's benefit, or only one at a time be expanded, for mobile users. This is quite simple to do at the application level.

Functionally equivalent components

Some components might be able to accomplish the same tasks, where one would be richer than the other, or have other trade-offs. Just looking at the <ice:panelTabSet> versus list of <ice:panelCollapsible> components, we can see that there are several ways of accomplishing the same goal, but with implications for mobile applications. Perhaps a better example is with date selection, where we could use a calendar or a text field. The text field will be smaller, and fit on a mobile screen easier, but will probably be more cumbersome for actual date entry. Plus, there's the whole issue of date format validation, whether they enter "January 16, 2008" or "2008/01/16" or "01/16/2008", etc. So, showing a date is best accomplished as text, and entered via a calendar. In that case, one would use <ice:selectInputDate renderAsPopup="true"/>.

Still, in the immediate-term, it will undoubtedly be necessary for some applications to use lowest-common-denominator components, or different pages with different components, for mobile versus desktop interactions.

Device aware component rendering

Probably the biggest TODO item in supporting mobile devices, for the component team, is simply rendering differently for mobile devices. Where possible we'd like to keep the HTML markup the same, and simply be more mobile browser friendly. But, where necessary, we'll have to detect when rendering to a mobile browser, and adjust accordingly.

In a way, <ice:selectInputDate renderAsPopup="true"/> exhibits some of the first strategy already, by adapting between the two modes of displaying and entering data. Another example of this would be text entry on the iPhone, with the popup keyboard. Pretty much every input component could be made to simplify its rendering, visually, while not actively being used to input data. This is something that really would not be possible without Ajax.

The iPhone, while simplifying some user interactions, actually complicates others. For example, how does one do Drag and Drop, when finger dragging has been re-appropriated to mean scrolling? Will we simply not support Drag and Drop, or will we have to render some WebKit specific markup? Or, since the iPhone uses a special interface for menu selection, how can we adapt <ice:selectInputText> to benefit from that, if at all possible?

The main example of a component that already renders itself differently, depending on the user's browser, is <ice:outputStyle>, which will output a link for a main CSS file, as well as one that is specific to the user's browser, thereby allowing for CSS work-arounds for web browsers' idiosyncrasies.

CSS styling

Which brings us to CSS, and styling web pages differently for desktop versus mobile browsers. Currently, <ice:outputStyle> can differentiate between:

• Internet Explorer 6.x and below
• Internet Explorer 7
• Safari
• Safari on the iPhone
• Opera
• Opera Mobile
  

How can you tell that we're Firefox centric? ;)

As you can see, you can serve out different CSS files for the main mobile browsers, automatically, without any application level coding. Over time, the default CSS styles for our components, for the mobile browsers, will get more and more refined. But, the beauty of targeting feature-complete mobile browsers, like Safari and Opera, is that few changes need to be made to styling.

What we're not doing

Notice how I didn't mention using different RenderKits for mobile devices that don't support straight HTML + CSS, or have limited Javascript or Ajax capabilities? Because most cellphones are moving away from those constraints. Maybe a few years ago it was worth throwing a couple years of development into those devices. Hell, maybe even now it appears tempting. But within a year or two that's just going to be a mistake.

Bonjour

After getting a taste for writing on the ICEfaces Forums, I've decided to make my own blog, to have as a single place to express my ideas related to ICEfaces. But first, I should explain who I am, and what I do, for this to make any sense at all :)

I work at ICEsoft, where we've got three main products, ICEfaces, ICEbrowser, and ICEpdf. I actually started there working on ICEpdf, which is a Java library for viewing PDF files, that you can embed into your Java applications or applets, say for online help features or whatever. I mostly focussed on adding support for more image types, added the ability to parse the newer PDF file formats which allow for faster incremental loading of PDF files, and a tonne of memory and speed optimisations.

Now I spend most of my time working on ICEfaces, which is an Ajax framework for JSF (JavaServer Faces). Its goal is to transparently add Ajax capabilities to regular JSF applications, where developers just don't have to worry about Javascript or manual configuration of what interactions will update what parts of the page. I've worked in several parts of the framework, most notably in our integration with Facelets, and also as a member of the Component team.

I've always worked on closed source applications in the past, sometimes contributing to opensource projects that my work relied on. So, it's been a new experience working on ICEfaces, where we're actively encouraged to connect with our community. I think that we're pretty privileged in that our community is so strong, helpful, and insightful. Sometimes it's pretty surprising just how superior developing with a community is, over just developing for clients. Hopefully, as times goes by, I'll be able to share those kinds of anecdotes here.