Back to index
Customizing Mobile Applications
Bill N. Schilit, Marvin M. Theimer, and Brent B. Welch
The physical and logical environment of a mobile application
evolves over time, and the application should adapt to this evolving
context; "dynamic execution environments" provide an abstraction
for notifying and being notified by other entities of such contextual
- Adaptation: In the mobile computing world, the state in
which a mobile or migratory application lives changes. Network
characteristics change for mobile applications, and physical device
characteristics (such as display, CPU power, storage available) change
for migratory applications. Applications must adapt to such changing
state; the method proposed in this paper is to create customization
contexts (similar to shell environments) to which applications can
subscribe. Subscribers are asynchronously notified of changes in
these contexts, giving them the opportunity to perform dynamic
- Dynamic environment servers: These are the entities that
manage customization contexts or "environments".
Communication between clients and servers is through RPC; clients can
add, modify, query, or delete variables within servers through RPC
calls, and servers notify each of N subscribed clients at each state
change through N RPC operations. Servers may run anywhere on the
network, and a given server may manage more than one environment.
There is one environment assigned to each mobile user, and other
environments managed for rooms or locations.
- Conventions: There are a number of well-known variables,
such as LOCATION which gives a user's current room location.
Environment servers are assigned attributes; applications bind
to servers through such attributes. Example attributes are
"location" or &kind& - a server with location attributes
manages items that have location; values for server attributes
are stored as well as the attributes themselves.
- Threaded vs. non-threaded: Two versions of the dynamic
environment variable system were implemented; for threaded
applications, an RPC notification of state change is used. For
monolithic applications, a separate process (one for potentially many
applications) receives state changes and writes these changes to shared
memory; applications must poll the shared memory.
- The system described provides a convenient and general way
to relay dynamically changing state information to a group of
interested and possibly cooperating applications.
- A key insight is that the mechanism for discovering and
relaying state change information can be largely abstracted away
from application specific semantics, and embedded in a support layer.
- Why did they have to use RPC? It's unnecessarily heavyweight, and
decidedly unscalable. Lightweight multicast or some other such alternative
would be much better.
- Frequently changing state imposes a high cost, as all subscribers
are notified of every such state change. More flexible filtering
mechanisms should be provided - servers that push have a funny
way of becoming too pushy.
- The dynamic environment servers are extremely centralized. Another
characteristic of mobile computing is unreliability - their system of
course does not function well in disconnected mode or in the case
of partitioned networks.
Back to index