Please visit this page for Live Demo - Click for Live Demo
Features of this Project
Following are the features of this project!
- Authentication is Identity based.
- Android App communicates through WebApi.
- Administrator can add Pricing Plans that restrict devices and set pricing.
- Administrator can search customers and view payments made.
- Customers can pair their devices for communication.
- Customers can see their journey on an OpenStreetMap.
Video Explanation (see it happen!)
Please watch the following youtube video:
Please visit this page for Source Code - Source code here
Purpose of the Project
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.
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.
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.
This Blog Post/Article "(C# ASP.NET Core) Location Tracking Project in ASP.NET Core and .NET MAUI" by Parveen is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.