Table of Contents
Introduction
A Job is an object that needs to be processed and retrieved results from. A Job object needs to be Serializable and is submitted by the client. It takes a JobID and a JobHandler as arguments and notifies the handlers who will take care of this type of Job when the reply from the server has arrived.
Design Choice
A client (Android device) sends a Job to server via the protocol. We delegate the Job to the server rather than handling it locally because of three reasons:
- mobile devices have less powerful computation ability;
- computationally intensive work consumes relatively high battery energy;
- processing the job preserves data privacy.
We explicitly decoupled Job objects from TIProtocol in our design because we want a plug-and-play situation where developers can directly pass Jobs to the protocol without worrying that their Job would conflict with the protocol as long as their Job has the correct signatures and inherits from correct parent class or implements the correct interface.
Types of Jobs
There could be many kinds of Jobs and you could implement new Jobs based on your needs by inheriting from AbstractServerJob. In our library, we provide you with several basic Jobs:
- DataJob: a general outgoing data job with data is of type BackableEncapsulator. This job is identified by a DataJobIdentifier.
- RequestJob: a general outgoing request job. This job is identified by a RequestJobIdentifier.
- ReportJob: a general outgoing report job, which are used to send reports to the server. The reports may include statistics, info, error, verbose messages, and so on. This job is identified by a ReportJobIdentifier.
Notice that the Jobs mentioned above need to be submitted from a protocol implementation. They can also be converted into more protocol specific Jobs provided the implementation of new Jobs (example see HTTPSOutgoingRequestJob).