Thursday, 17 September 2009 17:54

XML for Small Devices

15.1 What Is XML? XML is the acronym of the eXtensible Markup Language. Like any other markup language, it uses nested text tags to enclose content and represent data structure. XML itself does not define a specific set of tags and structures to use. You can define any tags to use in your XML document as long as your applications and other communication parties understand them. Hence, XML is extensible. For example, you can use the following XML document to describe a small computer parts inventory. Listing 15.1. A sample XML document Athlon 1.5GHz AMD 100.0 10000 Inkjet color printer HP 120.0 1000 Markup data languages have been around since the 1970s. In fact, the HTML itself is a markup language. What makes XML so special? Well, there are several reasons. XML has rich expression power. Nested tag elements allow us to easily express hierarchical data structures. More importantly, together with technologies such as XML Schema, XML supports strong data typing. Strong typed data are fundamental to object-oriented systems (i.e., Java applications). Please see Chapter 16 for more on XML Schema and XML data types. XML is both machine and human friendly. Unlike HTML, XML has strict syntax requirements for…
Thursday, 17 September 2009 17:32

Access Backend Databases

14.1 Direct Access to Remote Databases In the previous three chapters, we discussed the application architecture of the disconnected but synchronized mobile databases. Although that architecture is adequate for most mobile application scenarios, in some cases, direct connections to remote databases are still preferred or even required: Some applications depend on real-time backend data to function correctly. In theory, we can synchronize the databases as frequently as we wish to catch up with the real-time changes, but that would soon become too inefficient. For example, a salesperson might only need to look up the current availability of a specific product. There is no need to synchronize the entire product catalog. It is much better and more flexible to allow the application to query the backend database directly. Some devices, especially MIDP devices, do not have enough resources to support large on-device data sets. Legacy data on mainframe applications is available only remotely. Fortunately, the wireless network intermittency and latency, which make always-connected applications impossible in consumer markets, are less a problem in the enterprise markets: Many enterprise users reside on company campus and have always-on, low latency connectivity through WiFi or other company-provided networks. Now, let's have a look at…
Thursday, 17 September 2009 16:53

Database Synchronization

13.1 Synchronization and Mobility Isolated mobile databases are just discrete islands of data packets. Backend databases play an essential role to glue mobile databases together to form a complete IT network. Most business processes require field data to be aggregated at the back end for centralized decision making and access control. Mobile users need to get periodic data updates from the enterprise back end. For example, a sales representative needs to update his inventory database with new data from the warehouse server several times a day. The backend database is a content provisioning hub for mobile databases. This reduces the complexity of distributed data management. The backend database is also a backup repository for mobile databases. This reduces the chance of data loss from dead batteries or lost devices. 13.1.1 The Disconnected but Synchronized Architecture The need for the backend database does not always justify always-on connectivity. For most applications, the changes on both ends are not time critical and several-times-a-day updates are more than enough. That allows us to design disconnected but synchronized mobile applications. Under that architecture, the backend databases do not need to synchronize every little change at real time. It is a scalable and reliable solution…
Thursday, 17 September 2009 16:45

Mobile Databases for MIDP Devices

12.1 PointBase Micro Edition Among all mobile databases, PointBase Micro (v4.5) has the best CLDC/MIDP support. It actually produces a SQL database on the MIDP platform. Point-Base provides a set of proprietary Lite APIs under the com.pointbase.me package to access its MIDP database. The PointBase Lite API is very similar to JDBC. The only thing a JDBC developer needs to know to get started is the URL to obtain a Connection object (Listing 12.1). Listing 12.1. Connect to a PointBase Micro MIDP database public void connect() { try { Connection c = DriverManager.getConnection( "jdbc:pointbase:micro:" + m_dbname, "PBPUBLIC", "PBPUBLIC"); Statement s = c.createStatement(); } catch (Exception ex) { // Handle the error } } The PointBase Micro Lite database has a footprint of 47 KB. In the Lite API's PreparedStatement and ResultSet classes, the setter and getter methods support only the following types: Int, String, Decimal, Date, and Bytes. The setBytes() and getBytes() methods allow us to manipulate binary database fields (i.e., Blob fields). You can use your camera phone to take pictures and store them in your on-device PointBase MIDP database! For more details, please refer to PointBase Micro documentation and sample applications (see "Resources"). PointBase also provides a utility…
Thursday, 17 September 2009 15:46

Mobile Database for CDC Devices

11.1 Database on the Go One of the biggest obstacles of WAP-based mobile commerce is the requirement of uninterrupted wireless network coverage. Today's unreliable and incomplete wireless network infrastructure leaves the anywhere, anytime promise of mobile commerce unfulfilled. Fortunately, the widespread adoption of the smart mobile client technology will change this picture and enable new generations of mobile applications. A key benefit of smart clients is that they can function in the offline mode when the wireless network connection is temporarily unavailable. The offline mode drastically improves the application availability. In fact, most of today's mobile applications primarily work in the offline mode. Users carry their PDAs or barcode scanners all day. They synchronize data with desktop computers only once or twice a day. The disconnected mobile application architecture is a proven success. To support offline operations, the mobile client must store application data locally. There are great needs for first-class data management tools on mobile devices. Lightweight relational databases are just the tools we are looking for. Compared with linear data storage facilities (e.g., plain file or the MIDP RMS) that come with J2ME standard profiles, relational databases are much more efficient for complex data. Besides supporting highly available…
Thursday, 17 September 2009 14:33

Enterprise Messaging

10.1 Mobile Enterprise Messaging  More examples on the RPC scheme . Although RPC style integration is simple and does not require any middleware, it is sometimes not optimal in the occasionally connected, unreliable, and heterogeneous mobile environments. Error handling and quality-of-service (QoS)-level guarantees are difficult to implement in RPC environments. The messaging scheme, however, offers great advantages in some key enterprise areas. The benefits of enterprise messaging are as follows. Universal integration: In the messaging scheme, the message sender and receiver are completely decoupled. They interact only with standard interfaces defined by the messaging protocol and do not need to know the status or availability of the other party. This allows automatic and seamless integration between enterprise components. For mobile applications that run on many different devices and use different network transport protocols, messaging-based integration is crucial. Reliability: Due to the intermittent nature of wireless networks, communication reliability is a big concern for mission-critical mobile applications. In a messaging application, we can guarantee message delivery or at least notify the sender when the delivery is failed or not completed after a certain amount of time. Scalability: In an asynchronous messaging solution, the server resource is not tied up by idle…
Thursday, 17 September 2009 14:05

Converged Mobile P2P Messaging

What's up
Thursday, 17 September 2009 13:32

End-to-End Best Practices

7.1 Limited Device Hardware The most visible difference between the mobile and PC platforms is the difference in computing hardware. Today's PCs have much faster CPUs and far more memory and storage spaces than any mobile computing devices. Desktop and server developers can afford the luxury to write applications with bloated features (e.g., Microsoft Office); they also have access to rich productivity features provided by large, all-in-one frameworks (such as the J2SE platform itself). However, on mobile devices, it is a completely different story. With CPUs as slow as 20MHz and RAM as little as 100KB, we must carefully evaluate the features we need, thoroughly optimize our code, and live with limited framework support. In this section, we discuss how to cope with those challenges. 7.1.1 Lightweight Libraries The most common mistake beginners make is the "golden hammer" anti-pattern: choosing the wrong technology for the task. In the Java world, software tools are often available as reusable objects in standard or third-party libraries. To choose the best libraries that support required application features at the minimum hardware cost is essential. J2ME Foundation and Personal Profiles (as well as PersonalJava) are compatible with J2SE at the bytecode level and inherit a…
Page 1 of 3