Our App's Features

Check out what you can do with House Hunter today!

Technical Design Choices

 We used multiple APIS and Frameworks in our App. Our login System implemented the Firebase Authentication API. To store user data and listings we used the Firebase Firestore. To store the images we decided to use Firebase Cloud Storage and we can retrieve and display them in our app using their respective URI's. When entering a listing we use Google's GeoCoding API to get the longitude and latitude of an entered address. To display these listings in the map fragment we used the Google Maps API. Our final API is the Firebase Real time DataBase which we implemented for messaging. We chose Real Time for speed and it is the most apt method for storing message related data.

 When designing our app we wanted to minmise the amount of activities used in the app to keep a low amount of activities in the stack. We had an activity for user authentication steps and a main activity for the rest of the app. We also have another activity and broadcast receiver which accounts for when a user loses internet connectioin on the app. The rest of our app was designed to use fragments. Each tab or new page navigated to was implemented via fragments. We chose fragments as they encapsulate the views and are easier to reuse within activies. Our navigation tab at the bottom of the app on every screen was implemented via a BottonNavigationView. The tabs were achieved via view pagers. We also used naviagtion graphs to capture the user navigation. 

Lessons Learned

While creating House Hunter we encountered lots of problems and new concepts. During this time we learned lots of lessons. It is probable that if we were to start this app again we would complete it in half the time aswell as make some potential changes.The first problem we encountered was Activity Lifecycles. When we would flip the screen or close and reopen the app, data would often get duplicated. We learned several lesson on how to handle app transitions ans states to ensure the  data integrity was kept. We were able to put the theory we learned in lectures into pracitce, After learning about broadcast recievers we were able to account for when the app would lose internet connection. This was very helpful in creating a coherent app that could provide basic feedback if it became offline.

We also learned new concepts as we thought of more features to implement into our app.  We researched how to implement different themes for apps and after learning about shared preferneces and style value sheets we were able to implement a night mode for an app found in the profile section of the app. This was our first time dealing wiht nosql databases and it was an easy enough transition in terms of data retrieval and storage. However we quickly came into a diffuiculty regarding the asynchronous nature of the database. As it runs asynchronously we would often reference a null object which had not been returned from the query. This was one of the more difficult problmens we encountered. However once we came up with a solution to handle the asynchronous calls it was very reproducable and was no longer an issue. If we were to do this project again the main chnage we would have is more threads. We probably have too much work being done on singlethreads at some stages in the app. Dividing this work onto more threads in the future would lead to a more optimized app performance