Michael Yuan

The challenges to develop a mobile web application are two-folds:

1. The application needs to generate different page layout and markups for different devices. This is not just about using wider layout for wider screens — it also includes using table / CSS / JavaScript for devices that support those features.
2. The content (e.g., image, media, and text) also need to be customized and transformed for each device.

The web server can tell the client device type from the user agent header in the incoming HTTP request. The question now is how we integrate the user agent header information into the web framework and generate the right web page. The JSF renderkit approach we discussed earlier is not practical since we are not going to go through the trouble to write our own JSF renderkit.

One potential choice is to use the WURFL WALL JSP tag library, which can generate WML / CHTML / XHTML MP markups from the same JSP page based on the user agent. But the WALL tag library is difficult to integrate with modern web frameworks: it requires you to construct your page in WALL tags completely, while frameworks like JSF requires you to use its own component tags on the page. The WALL tag library also only deal with markup transformation. It does not provide different page layouts for different devices / screen sizes (except for the most basic customization hardcoded into the tag library), and does not deal with content transformation / management. We need a more flexible solution.

Don Kittle and Frank Carver mentioned in the comments to my previous blog entry that they use a JSTL servlet filter to transform the rendered XHTML content into WML / XHTML MP, and use special markups on the view template to progressively select content fragments for the target device. Those solutions are very good but they generally break the JSF component model, and to me, they are not generic enough.

So, here is what I think we could do (please let me know if I am missing something!): We can use a URL re-writing servlet filter to check the user agent of the incoming request, figure out the device attributes (e.g., screen sizes, whether CSS is supported etc.), and dispatch the request to the correct template for rendering based on the device attributes. For instance, a request from Nokia 6600 will be dispatched to the 176×208 XHTML MP with CSS template. For most current mobile device, I think the following 10 templates (in 5 groups) will suffice:

* Basic XHTML MP without CSS or table for small screens (width <= 128)
* Basic XHTML MP without CSS or table for medium screens (128 < width <= 176)

* Basic XHTML with table support for small screens (width < 128)
* Basic XHTML with table support for medium screens (128 < width <= 176)

* XHTML MP with CSS for small screens (width <= 128)
* XHTML MP with CSS for medium screens (128 < width <= 176)
* XHTML MP with CSS for large screens (176 < width <= 320, i.e., iphone-like)

* XHTML MP with CSS and JavaScript for medium screens (128 < width <= 176)
* XHTML MP with CSS and JavaScript for large screens (176 < width <= 320, i.e., iphone-like)

* Regular full blown XHTML with JavaScript for PC screens

The filter also saves the device attribute in the HttpSession object. When backing beans render content for the page, they can use the device attributes from the session to retrieve the right content for the device. For instance, the backing bean would retrieve a 176×10 banner image for the Nokia 6600, and limit the dynamic text to less than 250 chars (more or less one screen).

In the context of JBoss Seam, it would be great if we can make the filter a Seam component so that the user can configure it (e.g., URL rewriting rules for template locations) in components.xml. We can also make the device attribute object available as a Seam component so that all JSF beans can inject it as needed. Maybe this will be my next contribution to Seam.

Now, there are some potential issues with this approach. Let me explain why they do not matter in most cases …

• There are some repetition to write different templates for the same content. But it improves the usability of both the mobile and PC web pages, and that is all that matters. Also, the clarity of XHTML MP/HTML/WML-based design is far better than the opaque JSF tag-based design.
• The standard JSF renderer cannot generate WML markup for JSF input/form tags. That needs to be corrected by developing a set of WML-specific JSF form tags. That is much simpler than meddling with the renderkit. And frankly, there are not many WML devices out there! The vast majority of mobile phones today are XHTML MP-compliant and works perfectly with standard JSF tags.
• Some JSF implementations (e.g., MyFaces) use JavaScript to trigger button click actions. That will not work on some lower end devices. Fortunately, JavaScript-free high-quality JSF implementations (e.g., the RI) are readily available.

All in all, I believe the servlet filter approach is the right way to go for most mobile web applications. It allows web pages to be optimized for a variety of devices from the PC to iphone to PDAs to small mobile phones. And it can be used in any web framework since there is really nothing specific to JSF here!

In the next post, I will discuss how to map user agent strings to device capabilities (e.g., supported markups and screen sizes) in the filter, as well as exactly how many different view templates you will need in a typical mobile web application.

Update: Please see Dan Allen’s comment below for an alternative view. I do agree with him that component level multi-rendering makes sense. But without a good, production ready renderkit, all the practical problems listed in this blog post still exist. The bottom line is that we need a renderkit that can dynamically detect the device, dispatch to different page templates based on the device, render standard JSF components into multiple markups, and generate customized content for the device. That far exceeds the capability of any renderkit out there …

One of the much touted benefits of JavaServer Faces (JSF) is its capability to render multiple outputs from the same view page. For instance, in theory, the same JSP page can be rendered into WML/CHTML/XHTML MP for mobile phone browsers and regular HTML for PC browsers. However, no one uses that in the real world for a couple of very good reasons. The static JSF renderkit for “mobile content” just does not cut it:

1. The mobile phones and PCs have very different screen sizes and media capabilities. It would be silly to assume that you can use the same page layout and display the same type of contents for both use cases. If forced to do, the developer will just have to use the lowest common denominator and ruin the user experience. More than likely, you will need different view templates for phones and PCs. Hence the entire point of “reuse the view page” is moot.
2. Even if it is possible to reuse the page, the price you pay is to write the page entirely in JSF tags. There must be no regular XHTML/HTML/WML tags in the page for this to work. That does not bode well with almost all web page authoring tools. The rendered page is opaque to page designers. As we have seen many times, web developers prefer to construct the page template primarily in “regular” markups and only use JSF tags for specific input / data components.
3. Since the JSF renderkit is statically configured in faces-config.xml, you cannot have mobile web pages and regular PC web pages co-exist in the same web application. That is really silly and very limiting — what is the point of page reuse if you have to deploy two web applications to serve those pages?
4. While JSF can generate WML/XHTML tags from the same page, it does not address deeper content transformation issues. For instance, you will probably need to display different images on different devices based on the target screen size.
5. Finally, probably because of the above, there is really no production quality mobile renderkit out there for JSF. MyFaces has a basic WML renderkit. But it is just for demo and has not been updated in a long time. There is no renderkit for XHTML MP.

One way to address issues #3 and #4 is to build some user agent detection logic into the renderkit. The renderkit figures out the device type of the incoming request and generate the right tag / image for it. For instance, the following user agent indicates that the request comes from a Nokia 6600.

Nokia6600/1.0 (5.27.0) SymbianOS/7.0s Series60/2.0
Profile/MIDP-2.0 Configuration/CLDC-1

This user agent causes the renderkit to generate XHTML MP tags with all images on the page resized to below 240 pixels wide. The down side, however, is that renderkits are pretty complex to develop and we still have not addressed issues #1 and #2.

In the next post later this week, I will propose a better solution to develop mobile web applications with JSF and potentially other web frameworks. Stay tuned!

At eZee, the founders made a conscious decision to start our company in University of Texas’s Austin Technology Incubator (ATI). To be honest, I did not really know what ATI does when I joined eZee a couple of weeks ago. Okay, I knew that it provides its portfolio companies very cheap office space at prime locations, offers low-cost shared admin / IT / legal services, and provides access to technology investors. But still, while those offerings are nice to have, they do not seem to be strategically important to us — we are not some cash-strapped no-name startup (actually, the ATI would not admit no-name startups to begin with). ATI gets part ownership of the companies in its portfolio. If all ATI offers is operational help, even one percent ownership would seem a very steep price to pay.

Now, two weeks into my startup life, I finally begin to understand the value of ATI. The “access to UT’s brain trust” sounds very abstract, but it is in fact very valuable to any startup. How? Let me explain …

Most technology startup companies are built on a specific business idea and a specific piece of technology to give them an “edge” in that business. However, as they’d like to say, good ideas are a dime a dozen. It is pretty much guaranteed that someone else is already trying the very same thing. While the business and technical leaders of the startups are probably familiar with the competitors, and have general confidence that “we can execute better.” Very few people actually have the time to go through the quantitative exercise to determine exactly how much better we need to be in order to not only beat the competition but also reach our own goals of valuation / market penetration etc. That is especially true for a company like eZee, since we have entering a very big landscape where virtually all ideas have been tried, and many companies have failed or succeeded to various degrees. The founders of eZee would have to do quantitative research on hundreds of mobile-related companies — including to analyze their execution strategy, financial statements, and finer details of their products / marketing. That is certainly not possible for our busy CEO / CFO / CTO, and beyond the capabilities of technologists like myself.

So, here is where UT and its highly trained MBAs can really help out. They not only study the products and strategies of our potential competitors, but also analyze their financial to determine what our valuation will be if we are in the same space. They help us understand how the market is segmented, and the key differentiating points our company should focus on. That has turned out be to very helpful to the eZee management team, and trickled down to the techies as new product requirements and new delivery timelines etc. I believe that eZee will have a much better chance of success if we go through the analytical studies with ATI on a regular basis.

As we build our product, we can also expect ATI to help out with consumer behavior research, target custom surveys and focus groups etc. All those researches are crucial for the success of the consumer mobile product we are building. They require a lot of specialized expertise and man-power that we cannot possibly deliver on our own as a young startup.

Okay, so much for the ATI’s benefit to startup companies. How about the employees in those companies? What are we personally getting from working in an ATI company (well, aside from getting rich from the success of the company as a whole!)? The answer is networking. The ATI building is like a little silicon valley of its own. You can walk around the hall, wonder into other startups, learn what they are working on, and even discuss collaboration opportunities. That is very different from the working-in-my-own-basement startup experience. In the long run, this kind of networking will help us individuals to advance our careers, come up with new ideas, and even assemble teams later to implement those ideas.

All in all, even from my casual observation point, I am now convinced of the value of ATI (and by extension, the MBA education). I hope that we also get to work with those guys on the technical front (EE/CS graduate students?) besides the business front!

Fedora ships with SELinux (Security Enhanced Linux) enabled by default. Well, more security is a VERY GOOD THING if people know how to use it. But for a casual Linux user/admin, SELinux imposes a new set of unfamiliar runtime constraints beyond the standard *nix users/groups permissions. I learned this the hard way this weekend.

I recently installed Bugzilla on a fresh Fedora 7 box for my development team (well, I will write about my impression of Bugzilla versus JIRA in another post later …). After following the instructions closely to setup required Perl modules, MySQL database, Apache configuration, and SSH tunneling, I was able to hit Bugzilla web pages. However, when I tried to create an issue, Bugzilla complains that the notification email could not be sent. With the default “sendmail” option, Bugzilla complains:

/etc/mail/sendmail.cf: line 0: Permission denied

Error closing pipe to /usr/lib/sendmail

Hmm, that is weird since the /etc/mail/sendmail.cf file is globally readable. I can sudo into user apache and can read it just fine. Actually, I can invoke sendmail from the command line as user apache and sent out email … But nevermind, I will just try SMTP for email sending. But then Bugzilla complains:

Can’t connect to localhost

What? I can run telnet localhost 25 on the server, and send out email by manually interacting with the local SMTP server. Why would Bugzilla complain?

Without knowing anything about SELinux, I can only assume that the issue is with the Perl Email::Send module, which Bugzilla uses. So, I dived into my old Perl books and wrote several test scripts to see whether Email::Send works. They all worked fine from the command line console but all failed with the above two error messages when I tried them as CGI scripts.

Frustrated, I started to google for everything related to Bugzilla, Email::Send, Bugzilla, and Fedora 7. I spent hours reading, learned a lot about Perl, but still no luck. Then, I stumbled across this Red Hat Magazine article explaining how SELinux works. It says:

Its aim is to provide additional security to some of the more commonly used daemons: httpd, dhcpd, mailman, named, portmap, nscd, ntpd, portmap, mysqld, postgres, squid, syslogd, winbind, and ypbind by employing Mandatory Access Control (MAC) rules. These daemons run in their own domain such as httpd_t for httpd …

Duh! My SELinux configuration must have constrained the HTTPD from invoking sendmail or making outbound network connections! It is so obvious! I have no idea whether this strict security policy comes from Fedora 7 by default or is the result of checkbox I unknowingly chose at installation.

I disabled SELinux enforcement on the box, and Bugzilla works wonderfully now! I will leave it as disabled for now since my server runs inside a firewall and is only accessed via SSH tunneling. However, if we choose to setup a public server later, we will need to fix HTTPD security permissions and re-enable SELinux for sure.

In 20/20 hindsight, it is obvious that I should be able to spot the problem quickly if I searched for “SELinux” from start. However, due to my own ignorance of SELinux, I did not even know where to start. I believe this is one of the cases where I could really benefited from professional Linux support — a trained Linux admin would easily spot the problem and solve it for me in minutes. Lessons learned.

Ju just posted the photos we took from our vacation in Glacier, Yellowstone, and Grand Teton national parks. Enjoy!