Customizing Mobile Applications

One-line summary: 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 state changes.

Overview/Main Points

• 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 customization.
• 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.

Relevance

• 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.

Flaws

• 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.