-
Notifications
You must be signed in to change notification settings - Fork 1
Project Diary: Features and Challenges
- AES algorithm is used for encryption the data while communicating with data among devices.
- User's profile password is hashed for security reasons using the SHA256 algorithm.
- If the internet goes off: The app can work in offline mode using connection-less Wi-Fi mode.
- If the app crashes: The app saves the data on the server as well as on local mobile SQLite database.
The user will be asked for the permissions for using location and device storage. If the user provides these permissions then only the app performs the functionalities. This has been mitigated by allowing the app to use these services only while it is in use by the user and not in the background. Another concern is the risk associated with sharing the ride details with unknown people, which could lead to criminal and malicious activities. We have used filters to limit this but it is another concern that must be carefully handled. As the app works on broadcasting P2P messages and uses user devices to hop the messages beyond the range, this could immense load on the user devices leading to battery draining quickly and/or the phone overheating.
Since most of the application's functionalities are based for offline based scenarios, we use DNS to communicate. We believe that, for this service, the mobile internally uses Wifi to communicate and due to this reason itself, the limit to connect and communicate with other devices can be at most 8 devices. With respect to online devices, currently, we are using Heroku. In the future, if the number of users using the online functionality to schedule rides increases, we can switch to a better service provider like AWS. The same issue can be solved on AWS by load balancing. But these are expensive solutions and can be done by using HaProxy with keepAlived. This is TCP/HTTP based application software that provides features like which algorithm to use while transferring the call to other node servers if the master server goes down. Other options like the number of requests a node can handle to serve the requests and if exceeded, the requests are shared among the nodes.
Every bit of constants was added in a common Constant file. For example, changing the database API can be done using the constants file instead of changing it everywhere in the code. Other way of doing this can be using an XML based file system for taking the parameters like database information(database server address, port, password etc), server information(server address and APIs). This file can be edited directly by client/developers easily without needing to know the actual working of the code.