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.
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.
No! the tracking is not in realtime.
No! the phone number is neither read nor send, nor used.
CONTACT: SALES.HOVEN@GMAIL.COM for customizations