This android app was created to fulfill a business idea by my father. He used to be a residential home inspector, and knew about the money available in the service. However, instead of running a company, he had the idea to create his own sole-proprietorship. This app was designed to allow him to create his own inspection process, but make it incredibly efficient, and located in one device. Scheduling, inspecting, and reporting; from beginning to end of every inspection, all on one app.
This app was a huge learning project, so hyper-efficient coding practices, or even architecture isn't perfect. The project was attempted to be organized using OOP. I utilized comments to explain the more complex classes.
This project is a continous learning project, and I think it is turning out fantastic despite--probably--not being up to standard. This app is still a work-in-progress, but has a lot of core-functionality completed. Let's go over it!
The start of every inspection is the scheduling process, and this app handles it efficiently.
Additionally, the user can remove a schedule in the case it gets cancelled, or the inspection is completed.
Upon opening the first-ever inspection, the user will be introduced to the "inspection-hub." This Activity provides access to the tools to inspect residences. Without prior configuration, the custom-coded "Front" system is the only system available. There are also buttons to upload data and create the PDF; which we will come back to later. Here is also a good place to demonstrate the app's ability to change its theme!
Systems will be mentioned a lot in this documentation, so it's important to clarify what they are. A system is a componenent of an inspection. Whether the inspection be for homes or businesses, a system represents an aspect of the property that needs to be inspected. In the final PDF systems are used as chapters, not unlike a book, to group together related information. This app allows the user to create systems whenever they want.
After the user creates a system, the app stores the data into SharedPreferences. As a result, every inspection henceforth will include that system in the "inspection-hub."
Now that we have created a system, it is automatically filled with default Categories. Categories are yet again another way of grouping related information. Much less complex than a System, but each Category groups together different kinds of information. Within the Information system, we can create 4 types of items: Check Box, Numeric Entry, Slider, or Group.
Unlike the Information category, the observations, restrictions, and defects only show 2 types of items, 1 being a Group. Their layouts are similar, but are used for very different purposes in an inspection.
Observations, Restrictions, and Defects sometimes require comments from the inspector to give more information. This app allows for comments on these types of items, and has a robust system to make boiler-plate comments quicker.
Global scope comments are comments that can be accessed throughout the entire inspection, in every system, for every item that has comments.
System scope comments are accessible for every item that has comments within the same system.
Section scope comments are accessible for only the item whose comments are being edited.
The next category to talk about is the Sub System category. This category is very unique because it stores other "child" systems! This is another method of grouping together information, because when it comes to properties, there is a lot to talk about. Providing the tools to group information like this is crucial for making sure the screen doesn't get too crowded, and the final report is also easier to read. Sub-systems are the same as the System object we have been talking about with only a couple differences. For one, a Sub System does not have a Sub System category of its own, and this is to not make the inspection overly confusing; one nested system is enough. Secondly, in the final report, a Sub System will appear within the chapter of its "parent" system.
The final category in every system is the Settings category. This category is not editable by the user, and is hard-coded. This category provides basic tools to help the inspector during an inspection. Marking the system as partially complete will show the inspector that the system still needs more inspection. Likewise, marking a system as complete will signify to the inspection app that the system is done. A system can also be marked as excluded, which is equivalent to "complete" status, but means the system will not show up on the report. Some properties do not have every system configured in the app, so excluding systems is almost always going to happen. Finally, a system can be marked as a quality of the property to indicate to the client that this system is in excellent condition.
After the inspector has finished entering all the applicable data for every system, the inspector can upload the data to the database. Uploading this data is crucial for any business to keep a record of what the inspector reported. If a client reaches out after an inspection, the inspector can reload the past inspection from the database to follow up on any questions/concerns.
Due to emulator problems, my custom camera-x implementation is unable to work. Due to this, the PDF can't be created with pictures using the emulator. However, I can show screenshots of it working on a physical device. Inspectors can take a picture very quickly inside the app by pressing the image icon on a category-item that has pictures. The picture is saved into temporary local storage, and the inspector is shown a preview of it. With this preview, the inspector can add a circle or square to the image, drag and resize these shapes, and put them over the image to indicate importance. I.e. for a defect, a circle on the image will help show where the defect exactly is in the image. After finishing editing, the inspector confirms the image, and the original image file is replaced with the the image including the shapes.
