Didn't get a chance to say this before the branch got merged, but the actual username and userType fields should be private. If they're not, they can be accessed wherever by simply going User.username or User.userType. It defeats the point of having getters/setters.
They also shouldn't be static, the whole point of us switching to a singleton class was to avoid storing static values in a class.
Also, if we're being rigorous the User instance should also be volatile, since apparently android studio auto-generates an entity with the volatile keyword. This basically indicates to the compiler that the value needs to be fetched from main memory every time it's requested, and that it cannot cache the value. This is done because if the program is multithreaded, the value in main memory may be changed by thread1, but if thread2 has it cached that thread won't know it was changed. I'm not sure if this is necessary in android studio, but I do know that Javafx does some multithreading when scheduling things like animations, so it's not out of the picture that android studio might also. Not..that we'd ever change this value outside of the LoginActivity page and the logout button but just to be thorough
Didn't get a chance to say this before the branch got merged, but the actual
usernameanduserTypefields should be private. If they're not, they can be accessed wherever by simply going User.username or User.userType. It defeats the point of having getters/setters.They also shouldn't be static, the whole point of us switching to a singleton class was to avoid storing static values in a class.
Also, if we're being rigorous the User instance should also be volatile, since apparently android studio auto-generates an entity with the volatile keyword. This basically indicates to the compiler that the value needs to be fetched from main memory every time it's requested, and that it cannot cache the value. This is done because if the program is multithreaded, the value in main memory may be changed by thread1, but if thread2 has it cached that thread won't know it was changed. I'm not sure if this is necessary in android studio, but I do know that Javafx does some multithreading when scheduling things like animations, so it's not out of the picture that android studio might also. Not..that we'd ever change this value outside of the LoginActivity page and the logout button but just to be thorough