Offline - The Class Diagram

Terminology

I decided to change the persistence class names to use the term "service" instead of "broker". This is not a mandatory change, but I feel that "service" more closely mimics modern terminology for such a capability. Keeping in line with this change, I also standardized the method names to leverage the traditional CRUD operations.

The Class Diagram

The following class diagram describes the updated persistence framework:

The various classes and interfaces / protocols are described as follows:

  • AbstractServiceWeb - This class is very similar to the original class named ContentBroker. It's purpose is to provide general purpose behavior that applies to all services that exchange data with a server.
  • LocationService and CatchService - These interfaces (or protocols) define the basic operations available to the app. For example, one of the Java-based methods in LocationService is: public void create(FishingSpot l) throws ServiceException; Regardless of whether the implementation uses a local database or a server, the interface implies that an invocation of this method will create a new FishingSpot object.
  • LocationServiceWeb - This concrete class inherits from AbstractServiceWeb and implements the LocationService interface / protocol. This class will contain the specifics for exchanging location information with the server.
  • ServiceFactory - This static class is responsible for providing the application with an appropriate service. The class tracks the online / offline state of the application, and ensures that an appropriate concrete class is provided. As an example: If the application is in online mode, and a LocationService is requested, this class will return an instance of LocationServiceWeb.
  • AbstractServiceDB - This will be described in more detail in the next article. At this point, it's sufficient to note that it's a peer class to AbstractWebService, but it deals with local persistence instead of server-based persistence.

The next sections will describe the classes in more detail.

Note: There should be an interface / protocol for every business object that can be managed offline. For simplicity, I've limited this article to discussing locations. However, the final code will have additional service classes for things like fish, users, and catches.