In order to solve the objectives for the mobile application, our team decided to build it on native android. The primary objective was to provide a user-friendly experience to the users. For that, the application must be very simple but should deal with all the concerns of tenants and landlords. User Verification Process To effectively handle the users in the system, a verification process is needed for both user types. For the landlords, 2 steps of verifications have been made mandatory; email verification and document verification in order to publish the homes. We have used is_verified status to make a landlord eligible for posting the homes. This verification status is managed by combining the document verification status and the email verification status. Id proof, House Insurance, and Home Ownership certificates of landlords are stored on the server. After the admin verification is completed, this status will be changed. If the email verification is done, the landlord can publish their homes. Tenants in this application are university students and so the university-related student information has been stored along with the university email id in the database. The admin verifies the university student and then the status is changed. Then a verified student was able to request particular homes from a list of nearby homes. Quickblox Chat We needed a chat service to communicate with the tenants and to participate in the group chat of a particular home. When a home request is accepted and the terms & conditions are agreed upon between them, the students turn to be a tenant. One tenant needs to be part of the group communication channel and one to one chat with the landlord. We used the quickblox chat service on which customizations were made to satisfy our needs. Quickblox chat session needs a logged-in state of qbusers. This qbuser is generated by the signing process by using a QB id and a password. Since this qb_id generation at the front end is overhead, we decided to create a unique qb_id in the backend server immediately after a user registers in the app. In order to use the abilities of QuickBlox SDK, we need to authorize our app on the server, log in to the user account, and create a chat session. When a student/tenant enters the chat screen, they were assigned a common password and the unique qb_id in order to log in to the chat account. As a result, one qbuser is generated. Having connected to the QuickBlox server and authorized with a user, a chat server connection was established with chat module functionality. Then we created a chat dialog to fetch the recipient list and previous conversations of one-to-one chat and group chat. Thus each student could connect with the landlord and other tenants through group chat. This chat SDK has no inbuilt support for encryption. We implemented a custom algorithm for the encryption of the data.
