· UI fields which displayed several different values, such as Lat/Lng coordinates, Speed, Distance, Bearing, etc. They each must “listen” to an external map API, and display specified precision, delimiters and units. At the same time, they must maintain segment abstraction from that API. They can be “bound” through a proxy, automatically synchronizing values with a data object. That functionality is part of the framework, but ensuring their cooperation was difficult, partly because they could not adhere strictly to an MVC pattern, since they wrapped an object which must contain the actual current value, display it differently as directed by the map API, and provide a standardized value to the object.
· Unit objects (MeterUnit, KPHUnit, FathomUnit, etc) to contain value information which were accessed through a converter type to maintain segment abstraction. The Unit objects were used instead of primitive fields because when programmatically passing in a value to the field, the units of the value were ambiguous, and there was no way to query the field for the current unit. For simplification, I created the unit objects. These could be used as fields on problem domain objects, and also serve as easy means to perform unit conversions, since any Unit object could be built from another, and conversion was automatic in the process.
· The MapPropertyChangeBroadcaster serves as the focal point for listening for events from the map API. Any interested party can register with it. The ui fields listen for changes in precision, delimiter and unit display changes from a dialog within the “ICSF Map.” They then alter their display.