Many of your Android applications will need to interact with Internet data, which comes in a variety of formats. In this article, build an Android application that works with two popular data formats—XML and JavaScript Object Notation (JSON)—as well as the more exotic protocol buffers format from Google. You'll learn about the performance and coding trade-offs associated with each format.

When building Web applications with the Google Web Toolkit, using Berkeley DB Java Edition as a persistent data store can reduce project costs significantly.

RichFaces, like most other rich/Ajax component frameworks designed for use with JavaServer Faces (JSF), was extensively revamped for compatibility with the significant changes in JSF 2. Joe Sam Shirah examines changed and new RichFaces 4.1 components that provide the same functionality he demonstrated in "An introduction to RichFaces" with version 3.1. He also updates the setup requirements for using RichFaces with JSF.

A key part of any Asynchronous JavaScript and XML (Ajax)-based web application is the communication layer between the client and the server. To implement this layer, you need to understand the various communication mechanisms that browsers provide, as well as each mechanism's pros and cons. In this article, learn to make the correct match between the specific communication needs of an application and the appropriate mechanism. Detailed examples show you how to create a communication layer that can meet these different client-server communication needs.

AJAX, rich Internet UIs, mashups, communities, and user-generated content often add more complexity than they're worth. They also divert design resources and prove (once again) that what's hyped is rarely what's most profitable.

Imagine that you are tasked to create a new application that will live in the Web 2.0 world. Some of your users are perfectly happy with HTML-based user interfaces while others expect every application they use to behave like Excel. Your business sponsor expects a productivity-enhancing user experience, but your CIO won't allow you to develop anything that a user needs to manually deploy. You know HTML won't cut it, but what else is out there? This article explores a series of Web 2.0 user interface technologies that enable you to build applications with better-than-browser user experiences. As a result, you can centrally deploy and manage them just like any other Java™ 2 Enterprise Edition (Java EE) application.

The jQuery UI package aims to create a well-defined and reliable set of user interface widgets that you can reuse within your own Web applications. The goal is to provide well-tested widgets that go beyond those available in HTML Input elements, and ease the work of all user interface developers.

Learn the tips, techniques, and pitfalls when developing Web 2.0 and Dojo applications. Wendi Nusbickel and Melissa Betancourt have worked on the Dojo application documented in this article for over a year. Having recently completed the development of a Web 2.0 Dojo prototype, they share the experience they gained when creating a custom Dojo application.

There are a lot of choices here. The X in Ajax is for XML, but XML is not a language, it is a toolkit for building languages. So your first decision is: do you use an existing language, or build your own? Several tradeoffs are involved. You have to ask if an existing language fits your needs or whether you can design something which is a better fit? Are there tools to process the language, or will you have to build them? If you communicate with others (and if not, why are you building a Web application in the first place?), how well known is the language? Will other applications readily be able to access and use your data?

Any programming problem can be solved in multiple right ways. This series looks at four approaches for creating an Asynchronous JavaScript + XML (Ajax) weather badge, a small reusable widget that's easily embedded on any Web page. This first article lays the foundation and examines the first approach—walking the DOM tree.

Aristotle, the Greek philosopher, once wrote "it is possible to fail in many ways..., while to succeed is possible only in one way." But then, Aristotle wasn't a computer programmer. While Aristotle's first conjecture certainly applies to programming—"it is possible to fail in many ways"—his second is nowhere near as certain.

This series of articles looks at four different approaches to the same problem. None of them is demonstrably wrong—each has its own set of strengths and weaknesses. The problem they each solve is not complex, and neither are the solutions. Even so, the approaches illustrate a wide range of trade-offs that can be embodied in even simple solutions.