1. Number of devices is forced restricted to 5 even if the quota shows 10, or 50 or whatever.
2. If the number of journeys exceeds 5, then the journeys table is automatically trimmed by deleting journeys older than the previous day.
3. If the number of locations recorded exceeds 1000, then the locations table is automatically trimmed by deleting locations older than the previous day.

What is the Purpose?

Allows a customer wants to keep a historical log of the journeys performed by him. The longitude and latitude points are recorded through an android based mobile phone carried by him.

What is the flow?

First a customer creates an account on the ASP.NET Core Location Portal [X].

After that he installs an android app. The code for the app has been given as a part of this project. When he opens the app he sees a pairing code.

The customer has to create an entry for his mobile phone in his control panel marked [X] above. This entry adds a row [Y] in the "Devices" table of the database, and it contains a (1) primary key called "id", (2) nameIdentifierOftheUser from the identity database, (3) pairing code for the device - the pairing code has a "Unique" index.

The device entry marked [Y] above has to contain the same pairing code that he sees on his mobile phone. This pairing code is known only to the customer and his mobile phone. The actual mobile number is avoided this way.

The app has a "Start Pairing!" button. When the user clicks this button, the android app makes a web api call to "GetCredentials". The server checks whether the pairing code matches. If it matches, then it sends the combination "primary key + nameIdentifierOfUser" of the record (marked [Y] above) that contains the pairing code. The phone caches this combination for further requests with the server. The role of pairing code ends with this.

The "primary key + nameIdentifier" has to serve as a foreign key for the journeys table. The journeys table contains rows that represent a journey. A journey is a collection of locations. So we have one table for "Journeys", and one table for "Locations".

Now, when the phone travels and changes location, the android app records the longitude and latitude internally in a queue so that too many calls to the server do not take place. This application doesn't send realtime updates to the server.

The mobile application sends locations in a batch of 3 or 4 items. When it sends the first batch, it makes a WebApi call to "CreateJourney". This causes a row to be created in the "Journeys" table. The "primary key + nameIdentifier" serves as a foreign key for the journeys table. The response of the "CretateJourney" WebApi call contains the "id" of the record for the journey created just now.

Now the mobile phone keeps sending journeyId + nameIdentifier + deviceID + co-ordinates to the server. The server makes authentication checks and adds the coordinates to a "Locations" table.

Is the Tracking in realtime?

No! the tracking is not in realtime.

Is the phone number used?

No! the phone number is neither read nor send, nor used.