Jump to content

Macaw-Movies/Development/3rd party API: Difference between revisions

From KDE Community Wiki
Ochurlaud (talk | contribs)
Ochurlaud (talk | contribs)
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
= 3rd party API =
= Description =
 
== Description ==
This part of the code is used to get the metadata of the movies over Internet. Currently we only work with the public API of The Movie Database (TMDb).  
This part of the code is used to get the metadata of the movies over Internet. Currently we only work with the public API of The Movie Database (TMDb).  


== Source location ==
= Source location =
Everything that concerns requesting the TMDb API is in the folder {{Path|1=src/FetchMetadata}}. If we begin to have more API, we should create a Namespace for this and a {{Path|1=src/Modules}} folder, but it would be currently a little overkilled.
Everything that concerns requesting the TMDb API is in the folder {{Path|1=src/FetchMetadata}}. If we begin to have more API, we should create a Namespace for this and a {{Path|1=src/Modules}} folder, but it would be currently a little overkilled.
= How it work : Global workflow =
The class <code>Application</code> owns a <code>FetchMetadata</code> object and asks it to get the metadata of some movies. Because <code>Application</code> doesn't know the status of <code>FetchMetadata</code>, it will only add the Movies which metadata should be obtained to a waiting queue.
<code>FetchMetadata</code> take care of all the intelligence behind the queries, without knowing the detail of the queries. It only deals with <code>Movies</code> objects.
During its construction, a <code>FetchMetadataQuery</code> is constructed. This is the only object that knows how the queries are build, and how the responses look like. The connexion to the API is initialized at this time by <code>FetchMetadataQuery</code> (during the construction): we get the urls to query for getting the posters, the available sizes and so on.
Then,  for each <code>Movie</code> of the queue of the <code>FetchMetadata</code> object:
# <code>FetchMetadataQuery</code> is asked to search all the movies having the title of the current <code>Movie</code>
## ''If it returns only one proposition:''  <code>FetchMetadataQuery</code> gets all the metadata of this precise movie, see 2.
## "If it returns 0 or more than one proposition": a <code>FetchMetadataQuery</code> is constructed and all the propositions are shown, so that the user can choose or write the title that should be searched.
### If the user searches a new title, we go back to 1,
### If the user choose a movie in the list, we get all its metadata, see 2.
# <code>FetchMetadataQuery</code> gets directly all the metadata of a given movie (based on its TMDb id).
## For each member of the crew (actor, director...) a <code>People</code> object is added to the <code>Movie</code>, containing only a TMDb id, a name and a type (or role), and to another waiting queue so that it can reliably get the metadata of each person.
## If there is a poster, a request is send to get it.
# For each <code>People</code> of the waiting queue,  a request based on the TMDb id is sent.
When the <code>People</code> waiting list is empty, it means that the <code>Movie</code> is completely hydrated, so it is returned to the <code>FetchMetadata</code> object, which saves it in the database, take the following element of its queue and goes back to 1.
When the <code>Movie</code> queue is empty, a signal is sent to the <code>Application</code> object which will destroy the <code>FetchMetadata</code> object.
= How do the queries and responses look like ? =
* See [[/TMDB-json-responses|TMDB-json-responses]]

Latest revision as of 14:49, 23 April 2015

Description

This part of the code is used to get the metadata of the movies over Internet. Currently we only work with the public API of The Movie Database (TMDb).

Source location

Everything that concerns requesting the TMDb API is in the folder src/FetchMetadata. If we begin to have more API, we should create a Namespace for this and a src/Modules folder, but it would be currently a little overkilled.

How it work : Global workflow

The class Application owns a FetchMetadata object and asks it to get the metadata of some movies. Because Application doesn't know the status of FetchMetadata, it will only add the Movies which metadata should be obtained to a waiting queue.

FetchMetadata take care of all the intelligence behind the queries, without knowing the detail of the queries. It only deals with Movies objects.

During its construction, a FetchMetadataQuery is constructed. This is the only object that knows how the queries are build, and how the responses look like. The connexion to the API is initialized at this time by FetchMetadataQuery (during the construction): we get the urls to query for getting the posters, the available sizes and so on.

Then, for each Movie of the queue of the FetchMetadata object:

  1. FetchMetadataQuery is asked to search all the movies having the title of the current Movie
    1. If it returns only one proposition: FetchMetadataQuery gets all the metadata of this precise movie, see 2.
    2. "If it returns 0 or more than one proposition": a FetchMetadataQuery is constructed and all the propositions are shown, so that the user can choose or write the title that should be searched.
      1. If the user searches a new title, we go back to 1,
      2. If the user choose a movie in the list, we get all its metadata, see 2.
  2. FetchMetadataQuery gets directly all the metadata of a given movie (based on its TMDb id).
    1. For each member of the crew (actor, director...) a People object is added to the Movie, containing only a TMDb id, a name and a type (or role), and to another waiting queue so that it can reliably get the metadata of each person.
    2. If there is a poster, a request is send to get it.
  3. For each People of the waiting queue, a request based on the TMDb id is sent.

When the People waiting list is empty, it means that the Movie is completely hydrated, so it is returned to the FetchMetadata object, which saves it in the database, take the following element of its queue and goes back to 1.

When the Movie queue is empty, a signal is sent to the Application object which will destroy the FetchMetadata object.

How do the queries and responses look like ?