Pegboard: A Framework for Developing Mobile
Applications
Danny Soroker1, Ramón Cáceres1, Danny Dig2, Andreas Schade3, Susan Spraragen1, Alpana Tiwari1

1 IBM T.J. Watson Research Center 2 Department of Computer Science 3 IBM Zurich Research Lab
19 Skyline Drive University of Illinois Säumerstrasse 4 / Postfach
Hawthorne, NY 10532, USA 201 N. Goodwin Ave CH-8803 Rüschlikon
{soroker,caceres,sprara,alpana} Urbana, IL 61801, USA Switzerland
@ us.ibm.com dig @ uiuc.edu san @ zurich.ibm.com

ABSTRACT
Tool support for mobile application development can significantly
improve programmer productivity and software quality. Pegboard is
a novel tooling framework that extends the Eclipse integrated
development environment to support the development of mobile
distributed applications. Its extensible design supports multiple
application models and the orchestration of external tooling
components throughout the development cycle. In this paper we
describe Pegboard’s architecture and implementation, and show
how it improves the development experience through organization,
visualization, simplification and guidance. We also discuss insights
gained from interviewing software developers, including early users
of Pegboard.
Categories and Subject Descriptors
D.2.6 [Software Engineering]: Programming Environments –
graphical environments, integrated environments, interactive
environments, programmer workbench.
C.2.4 [Computer-Communication Networks]: Distributed
Systems – client/server, distributed applications.
General Terms: Design, Human Factors, Languages.
Keywords: Integrated Development Environments, Application
Development, Mobile Applications, Distributed Applications, User-
Centered Design.
1. INTRODUCTION
One vision of mobile computing is to deliver the power of network
computing through devices one can easily carry. To achieve this
vision, mobile computing applications require collaboration
between a mobile device and other networked computing nodes,
such as servers and other devices. These applications are therefore
distributed and often involve multiple components running on
multiple platforms. Such applications also need to address mobility-
specific issues, such as device heterogeneity and intermittent
connectivity.
Developing mobile applications is a complex task. Consider
Vindigo[4], an interactive city guide for handheld devices that
provides location-based information in categories such as dining,
shopping and entertainment. The Vindigo code base targets several
hardware and software platforms. The server software executes on
x86 machines running Linux, while client software executes on a
range of devices running Palm OS, Windows Mobile, Binary
Runtime Environment for Wireless (BREW), or Java 2 Micro
Edition (J2ME). Differences among platforms require specializing
large portions of code to individual platforms, for example code that
exploits the availability of a thumb wheel on one particular device.
On the other hand, many functions are common to the server and
some or all of the clients, for example computing walking
directions. To avoid implementing the same function multiple times
or fixing the same bug in multiple places, developers seek to share
as much code as possible between target platforms. Designing,
writing, testing, debugging and deploying a distributed mobile
application presents many challenges.
Integrated Development Environments (IDEs) – such as Eclipse
[10] and Visual Studio [23] – are the tools of choice for complex
software development. These environments strive to support the full
development cycle by combining a rich set of cooperating tools
such as visual user-interface builders, source-code editors, compilers
and debuggers. IDEs are instrumental in developing individual
components such as Java applications and Web services, but they
fall short in developing heterogeneous systems consisting of
multiple components.
IDEs organize software into projects, where a project typically
corresponds to a platform-specific software component, such as a
Web service or its corresponding client. A distributed application,
however, comprises many such components, spanning many
projects. Thus there is a need to augment IDEs to effectively
manage collections of projects as coherent entities. Such tool
support should organize the collection of projects comprising the
application in a manner that reflects its logical structure and
facilitates common operations across the entire collection. To
support development of mobile applications, the tool should also
address mobility concerns that cut across the collection of projects,
like disconnection and device heterogeneity.
In this paper we present Pegboard, a new tooling framework for
developing mobile distributed applications. Pegboard is built on the

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MobiSys’06, June 19–22, 2006, Uppsala, Sweden.
Copyright 2006 ACM 1-59593-195-3/06/0006...$5.00.
138

Eclipse open-source platform [10], which provides an extensible
plug-in architecture that allows the integration of software
components from different providers. A wide variety of Eclipse-
based tools is already available, including the Java Development
Tools and the Plug-in Development Environment. Pegboard is
designed to leverage existing and future Eclipse-based tools that
have no knowledge of Pegboard. We chose the name to suggest a
physical pegboard on which workshop tools are hung.
Our key contribution is a new approach to managing the complexity
of distributed mobile application development in an IDE. The goal
of the methodology we present is to enable IDEs to treat these
applications as coherent entities. Our approach consists of the
following ingredients:
• Organization: We arrange the code artifacts into a nested
composition of projects that reflects the logical structure of the
application and better supports code sharing among different
platforms.
• Visualization: We provide centralized views of the entire
distributed application – a view showing its design as a set of
interconnected computational nodes, and a view showing its
implementation as a nested collection of projects.
• Simplification: We make it easier to perform common
operations in the development cycle, such as launching all
components of the distributed application as a single operation.
• Guidance: We provide architectural patterns to help “jump-
start” development, and we orchestrate the development process by
leveraging other tools as needed, supporting top-down, bottom-up
and mixed design paradigms.
It is important to consider the target users in any software endeavor.
An additional contribution of this paper is to show how user-
centered design has helped improve Pegboard’s usability and
relevance.
The rest of the paper is organized as follows. Section 2 illustrates
the experience of using the Pegboard methodology to develop a
sample application. The architecture of Pegboard and
implementation details of the current prototype are described in
Section 3. Section 4 presents the user studies and feedback. Section
5 provides a deeper discussion of some aspects of Pegboard,
including future directions. Section 6 discusses related work, and
Section 7 concludes the paper.
2. DEVELOPMENT METHODOLOGY
We start by briefly describing our abstractions and terminology.
Pegboard maintains both a design view and an implementation view
of the application. The design view is a graph, in which each node is
a sub-application. A sub-application represents a part of the
distributed application that runs on a single hardware platform. Sub-
applications are typed according to the kind of computational node
they represent (e.g., device, server, Web service). A sub-application
contains functional components, which represent software modules.
The edges of the design graph are connectors that represent
communication links between sub-applications. The implementation
view shows the code artifacts, also known as resources, and reflects
the project structure of the application, which is a tree. The root of
this tree is a Pegboard project, which contains a hierarchy of nested
projects. Composite Projects, developed as part of this work,
provide the mechanism for nesting projects.
To help explain our work in concrete terms, we present a sample
application called Order Entry, and show how Pegboard facilitates
its development. The elements of Pegboard are introduced in this
section, and elaborated upon in Section 3.
Order Entry is used by a sales person to submit purchase orders
through a mobile device to a central server. Orders specify a
customer, product, and quantity. When entered, the order is queued
locally on the device, and sent to the server as soon as connectivity
is available. As orders complete, the server confirms them to the
device. At any time the user can view the status and history of
orders. The Order Entry application comprises a Rich Client
Platform (RCP) [11] sub-application on the device, a Java sub-
application on the server, and Message Queue Everyplace (MQe)
[19] as the connection mechanism between the two. RCP is a
technology for building Java applications from components called
bundles. The bundles are managed by a runtime system called OSGi
[26]. The device sub-application is structured as multiple OSGi
bundles. MQe is a messaging technology that is optimized for
mobile environments with intermittent connectivity.
The first step in developing an application is to create a new
Pegboard project via the new-project wizard. Apart from the project
name, the developer chooses an application pattern, possibly the
empty pattern. The pattern shown in Figure 1, a device-server with
data connector, best fits Order Entry.

Figure 1: Pegboard new-project wizard

The application pattern helps guide development by automating the
initial creation of design elements and associated code artifacts. The
design elements are shown in the graphical Design Editor. The code
artifacts and nested project structure are shown in the Composite
Explorer. Figure 2 shows the Design Editor and Composite Explorer
immediately after the Order Entry project has been created.
The design diagram contains two sub-applications and a connector
between them. The sub-application icons indicate their respective
types: “device” and “server”. The Composite Explorer shows the
actual projects that have been created -- for the device, the server,
and code shared between the device and server. The device and
server projects, as well as the Order Entry project itself, are
Composite Projects that act as containers for other projects.
139