The SAP Mobile Infrastructure is offered in two flavors: JSP and AWT. Both versions include the same core APIs for synchronization, configuration, persistence, logging and so on. The JSP based MI client includes a Jakarta Tomcat 3.2.4 webserver, which allows to run servlets and JSPs on the client device. This technology is used to create the offline user interface. The rendered html is displayed in the Pocket Internet Explorer (Windows Mobile) or a client application which uses an Internet Explorer control (Win 32). Applications that should run on the JSP based MI have to implement servlets and JSPs to create the user interface. An old technology - which is still available but nor supported anymore - is microITS. As it is not supported, it will not be discussed here. The AWT client is uses the Abstract Window Toolkit, which was introduced by Sun in Java 1.0. AWT uses native operation system controls to render the user interface. The question is: Does it make sense to run a web server on a small device like a laptop or PDA? Let's discuss the pro and cons. There are multiple problems with the JSP based MI client:
Browser based UI: A classical browser based user interface can never reach the same quality like a native application. To change the screen or display new data it is always required to make a round trip (http request and response) to the local web server. With new technologies like AJAX this is getting better now, but this technology is not available on Windows Mobile devices so far. Because of the html UI, the usability is much lower than with a native user interface. So the limitations are really big.
Footprint: The Tomcat web server allocates alot of memory. But as memory is the most valuable thing on small devices, this is a huge problem.
Performance: The performance of the webbased UI is significant slower on PDAs/Windows Mobile devices than the AWT user interface. The bottleneck here is the Pocket Internet Explorer which renders the html really slow.
On the other side we have AWT:
Rich UI: AWT does not support all controls that are available by the operating system, therefore the possibilities are limited. But AWT can be mixed with other Java UI technologies. On both Windows Mobile and Win32 devices it is possible to use SWT, which is also using native UI components, but has alot more controls available. With the use of SWT you can not see a difference between a Java and a Microsoft application anymore. Another technology that you could use is Swing. Swing also offers a broad range of available controls, but on the other side it is not based on native controls. Because of that the UI will not look as nice as with SWT and it is also slower. Therefore SWT is the number one choice IMO. No matter what technology you use on top of AWT, the UI will be alot more user friendly than a web based interface.
Lower Footprint: The AWT based MI has a smaller footprint. This leaves more memory for the application logic and the data.
After reading this the the decision should be clear: Go with AWT! Not really. I agree that AWT is the better choice, but there are some scenarios where you should or must go with the JSP UI:
Standard MI applications: If you develop your own application which should run side by side with a standard app from SAP like MAM, MAU or MTT, you have to go with JSP. These applications are JSP based and as you can not run AWT applications on the JSP MI, you have no other way.
More JSP developers: You will find alot more JSP then AWT developers. Maybe you already have them in your company. So it could be easier to use the existing skills instead of having invest in the training of AWT developers.
Online applications: Maybe your scenario requires an online version of your application as well. In this case you can re-use the user interface and the controller and you just need to replace your model.
IMO you should go with AWT if none of the aforementioned reasons apply. But enough for today, let's get the Business in Motion!.
