Skip to content

Unify the API with the CMA SDK #44

@tomxor

Description

@tomxor

Prior to v2.0 the public API was structured as follows:

  • client.fetchEntries(); // async
  • client.fetchEntriesBlocking();
  • client.fetchAssets(); // async
  • client.fetchAssetsBlocking();

This results in a very big CDAClient class, with many methods which is a pain to maintain. Considering future support for RxJava, this would make a bigger file with even more methods. This change should follow the same structure of the CMA SDK:

  • Define a module class for every type of resource (i.e. ModuleAssets, ModuleEntries, etc).
  • Top-level methods of a module should be used for making synchronous requests.
  • A module should contain an inner-class named Async that should be accessible by invoking a top-level method named async().
  • All methods of an Async inner-class should take a CDACallback instance and be used for making asynchronous requests.
  • CDAClient should contain instances of all available modules.

When introducing RxJava support, every module should have another inner-class, similar to Async, but for methods that return Observable instances. (i.e. Obseravables class accessible via rx() method of the module).

As opposed to the CMA SDK, there is no point of creating several Retrofit service interfaces, as the number of methods for CDAService should now be fairly low, and is not subject to change.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions