Week 15 - 16 : Demo Day!In the final two weeks of our project (week 15-16), my team decided to focus and put in as much effort as we could to complete the project. This involved implementing the remaining functions, cleaning up the code as much as possible and fixing any bugs. Auto-generating IDs I The way announcements are stored currently is via IDs. However, the announcements were originally stored based on their titles (instead of numbers like 1, 2, 3, ..., the 'heading' was their title (given by the admin)). But, because of a bug (more explained later), announcements could not be stored by their titles. As a result, I temporarily made use of the method to make booking IDs for announcements. This actually resulted in a big issue: if the application is restarted, the generated ID would start from '1' and would replace the current announcement/booking. To solve this, I implemented a check that automatically generates IDs (by adding the last existing ID by one). However, I noticed another issue with this. If there are 3 announcements currently (1, 2, 3) and announcement number 2 is removed (1, 3 left), the check would fail and cause errors. After playing around with the code, I successfully made a check that would automatically generate IDs in any situation. I also implemented this check for booking IDs. Bug in Adding to Firebase This image partially shows the json of the Firebase with test data. In the "MakeAnnouncement" branch, it is shown that it contains objects in an array []. However, as mentioned earlier, if announcements were identified by their titles, the "MakeAnnouncement" branch would not be in an array, but would be an object instead (like the "User" branch where there are objects within objects). In order to extract the data to be displayed, the announcements must be in an array (objects within objects causes many issues as these objects will be under their own class instead of being under "MakeAnnouncement" class). Also, the "MakeAnnouncement" branch was originally called "Announcement", but was changed due to some bugs. One of these bugs was that an array could only be created if the name of the class was the same as the name of the page/branch. After testing out many times, I noticed that if the names were different, it would result in objects within objects. However, if the names were the same (e.g. Booking), an array could be created, which was what I wanted. Changing Status of Lots Another function of the admin that I implemented was the changing of status of lots (disabling/unlocking lots). Originally, I created individual pages for each location, but this turned out to be very inefficient since I would have to manage 10 for disabling/unlocking lots. After a teammate suggested using 2 'general' pages for all locations, I followed his advice and noticed that it was easier to manage the pages, making it more efficient (for me). As mentioned above, instead of using individual pages (e.g. RwsDisable, SuntecDisable), I made use of QueryString to get the location the admin clicked on and display appropriate lots based on the location (by reading from the Firebase). After disabling a lot, an announcement will also be automatically generated to alert users. Some Screenshots Here is the home page for admins (styling not done by me). Admins can make announcements for users. Admins can select the location to unlock/disable lots. Based on the status of the lots, lots that can be unlocked/disabled will be displayed. Admins are able to select the reason for disabling lots. After selecting the reason for disabling the lot , there will be a confirmation message. For disabling lots, a new record will be added to the Firebase. For unlocking lots, the record will be removed from the Firebase. Demo Day Pictures This was our setup for our booth during the demo day. Three laptops were used: One for the web application, one for the firebase and one for the admin. We also made a 'carpark lot' to demonstrate our proof-of-concept.
0 Comments
Week 13 - 14Week 13 was Open House week! Unfortunately, as mentioned in the previous post, since I was involved in the Open House, I was unable to help my team out in some of the areas. I was only able to make some progress once open house week ended. In the following week (week 14), my teammates and I met during the P2 lessons to continue with our work. To summarise what I did this week, I successfully implemented the "Make Announcement" function for admins to make announcements that users are able to see. This is the code used to make an announcement and add it to the database (Firebase). After an announcement object is created and added to the database, a success message will be displayed and the admin will be able to return to the home page.
Week 12After the Hackathon, P2 lessons were temporarily cancelled so that we were able to focus on our other subjects + our own P2 project. In the case of my team, we only made very minor changes to our web application, but we did not make any significant changes to it. Some of the minor changes I made included cleaning up some of the back-end code (e.g. removing unnecessary comments) and fixing some small bugs (e.g. displaying of deadline in Status page).
When the new term began, we decided to start making significant changes to our project. I was appointed to work on the admin functions, which is a function we planned to add in subsequent sprints. Originally, we planned to allow admins to change the status of parking lots (unlock/disable) and upload announcements for all users to see. Unfortunately, as I am involved in presenting another project during open house (happening in the following week), I could only make the 'skeleton' of the admin function. This included:
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |