Colorado Software Summit 2003 - Day 3
J2ME Case Study - David Moskowitz, Productivity Solutions, Inc.
The focus of David's talk was how his team enabled a large firm to realize the benefits of making information available anywhere, anytime, to anyone. The company was losing market share in some markets, stagnant in others, and profitability was being impacted negatively. They wanted a competitive edge and were looking to David's team to provide it. Since information anywhere, anytime, necessarily means mobile devices the team had two choices. First they could attempt a daily sync of data on the mobile device. Secondly they could process real time requests with current data. The wireless value proposition includes helping to manage supply and demand, timely response to the customer, and it adds a new dimension to high-tech, high-touch, customer relationship managment. Winning in the wireless space happens when information is available where and when it needs to be.
The team ran into some problems when dealing with small devices. They determined that they had to move nearly all of the processing back up the stack to the server. Small devices are consumer devices not computers. They have limited memory, and limited means for input, and small display sizes. David discussed the CLDC and MIDP. He laid out a few design principles for MIDP UI design. Constantly think of the end user. Use a simple traversing and selection metaphor. Design the app to be usable in all devices with a consistent look and feel across devices. They used SSL and TLS for encryption along with 1-way and 2-way authentication depending on the needs. SMS was the transport chosen. They had to deal with online and offline connectivity, designing for the inevitable loss of network connections. They chose messaging on the server side to integrate the existing applications. The only new application was the CRM app itself. Make good use of emulators for testing since the devices can be very slow.
Writing Java Applications for Mobile Information Devices - James E. Osbourn, Riverpoint Group, LLC
James introduced J2ME and focused on MIDP 2.0. J2ME includes embedded systems for appliances and set-top devices that are nearly PCs, cell phones and PDAs. Two configurations are specified for J2ME, Connected Limited Device Configurations (CLDC), and Connected Device Configuration (CDC). CDC specifies a minimum of 512KB of ROM and 256KB of RAM and a network connection. In addition a full JVM must be supported. CLDC mandates only 160-512KB of memory. You are usually dealing with a slow connection and a small screen. CLDC also uses a Java Kilobyte Virtual Machine (KVM). Many of the hardware manufacturers give you native API's that are accessible from Java but may limit the distribution of your software. The focus of the lecture was on the Mobile Information Device Profile (MIDP) for CLDC.
MIDP apps are called Midlets. J2ME requres cross-compiling, that is you compile on one platform and run on another platform. Make sure that you don't optimize during the early coding. Watch your application run and then optimize. You are required to pre-verify the bytecode prior to moving it to the device.
James demonstrated getting a reference to a display, adding commands, titles and tickers. He explained that it's a good idea to process commandActions in a separate thread from the system's event handling. He showed examples for coding text boxes, alerts, forms, images, imageItem, DateField, ChoiceGroup, Gauge and lists. He explained that traversal can be device dependent and what to do during and after traversal. He showed Record Stores and the code for accessing them and sharing them. He explained that you can keep read-only data in a resource file accessing it with getResourceAsStream().
Advance Features in Java Applications for Mobile Information Devices - James Osbourn, RiverPoint Group, LLC
This presentation built on James' previous talk. He introduced connectivity (http, https). He showed examples of the J2ME Canvas for drawing shapes, text, and images along with demos of Blitting, Clipping, and Animating. He introduced the Game API, Sound and Music APIs. He also mentioned performance tuning techniques. Best practices include using GET instead of POST, use a separate thread for network address.
There were several demonstrations of the graphics capability in J2ME. James drew text, lines, set font attributes, and drew images. He mentioned the game actions built into MIDP 2.0 and the GameCanvas class. He demonstrated layers and tiled layers and went into some of the built in special effects. As regards performance, skinny and fast is important, write code for clarity and maintainability first then optimize if necessary. Benchmark then improve.
Patterns Are for More than Code: Building a Real-life Web Service Application - David Moskowitz, Productivity Solutions, Inc.
David went into the patterns he identified and used in his team's project with a large firm. The business problem was to provide information anywhere, anytime, to anyone. This became a cross-boundary problem where they had to integrate systems across department and organizational boundaries. They decided to use a service-based approach since using distributed objects can be very complex.
Some of the patterns (best practices) employed: Services should be designed to communicate with each other with minimal coupling. Each service should be self-contained. Identify service types and make them as consistent as possible. Know how the services communicate with each other before choosing physical dsitribution boundaries. Keep coupling low & no chatty interfaces. Minimize the number of data formats. Abstract policy from the main app. Determine the type of layering you will enforce. You must consider multiple platforms. Separate process from input. Design for online and offline connectivity. The real issues have absolutely nothing to do with technology. Security is not an afterthought. Use tested proven security systems instead of "rolling your own." Never trust external input. Assume external systems are insecure. Enable only needed attributes. Security by obscurity isn't. Use asynchronous messaging if possible. You can't use old-school thought to solve service-based problems. Everything prior to service-based thought is old-school.
6:45:09 AM 
|
