(draft) `Day 74 & 75 & 76` - Fixed Login b...

# 100daysofkotlin-2021

[Bryan L]

(draft)
Day 74 & 75 & 76
• Fixed Login bug
◦ Reset registerStatus & loginStatus after execution (this wasn't changing back to the default immediately & was storing/using the previous result if the user logs out after a successful login/register and logs back in with any credentials)
• Discovered a way to view Android Documentation on my Kindle.
◦ Optimized well once I'm on the specific Doc & in Article Mode. Otherwise It overlaps with the navigation tab on the left side and is near impossible to use in navigation mode. But can take advantage of this pool-side. PDFs on the kindle for Android Docs are "ok"...
•
Self-Comment
• Successfully fixed the login/register bug! I had tried a few different scenarios I thought may have fixed it, however I took a step back on Day 74 and tackled the bug for a few hours on Day 75 to no avail. I'm pretty sure I solved in in my sleep in my sleep going into Day 76. It's not optimized yet, but it works nonetheless 😆👍
• Decided against all of my "Goals Tomorrow" besides fixing the bug. I did play around with these, but ended up just reverting the code. Reasons below:
◦ DisposableEffect, not sure it would fit in my scenario compared to LaunchedEffect / SideEffect. I could replace my "subscribeToObservers" function and put the code in one of these, but will deal with it if I decide it's important enough or there are performance issues.
◦ Regarding the loading screen, I have left it there to determine and navigate to specified screens in the event there is an issue with transitioning to a screen. It will default to the loading screen instead. I ran across an issue with finding a blank screen with no way to navigate out when I attempted to removed it.
◦ The UiDrawerState is directly effected by the user being logged in & the data held is relatively small. Unless there is a performance issue, I will leave it the same as to separate I would still be calling both whenever I needed to change one. Just separately instead of together (a lot more code involved for similar/same result)
• I had to go back and see what I planned next. Been working on implementing datastore & login for some time 🤷‍♂️
◦ Refactoring
▪︎ Clean up all of the spaghetti code I've created over the past 1-2 weeks. Including unused code & adjusting some functions. Thinking about setting aside time per day to dedicate to refactoring to avoid being stuck on it while continuously cleaning it up
◦ assigning users to notes
▪︎ (Fetch from server with Retrofit and cache in Room)
◦ Encrypting login information
▪︎ (Important, but I'm only using test accounts and email addresses aren't being used & running through localhost. So not concerned about this yet
▪︎ Google-Sign-In method is still disabled for now. When I encrypt current data I'll enable it or remove it. Decision for a later time.
• Lot's of comments compared to completed tasks, but I've got a direction for the week
• I may have found another project. Initially planned on a Pomodoro Timer app, but this one would be for company I used to work for in NZ. It's currently just talk, but could lead to actual work. Some more details in thread

[Bryan L]

The company deals with heavy engineering involving Hotels, Bridges, Commercial buildings, etc. I would be building an app to help them track their material (Who performed the work, Steel beams / assemblies & such) as they move around to different bays in the shop up to the point they leave to move to the job site.

A few things about it: It's still just idle talk, but can be pushed to become a real project if I so choose to. I'm close to the people in the company that want to push the idea. They are familiar with me still being new to the "developer role", and I told them the truth that it would be a big project for one person, especially one without experience. They're all for giving me the opportunity if I believe it's something I can handle.

I had given it some thought and spoke to them about the possibility of creating a small proto-type to test the waters.
1. Because I know that there will be quite a lot involved, one of the comforting aspects is that the app will be used internally and not by consumers & will ultimately not result in any extreme losses.
2. It's not something I have to be committed to while developing a proto-type. So I can choose to decline/drop the project at anytime before they push the app and it becomes an actual contract. It's not a necessity & there is about a 99% chance that it would not come to fruition if I don't take it up myself. So up until the proto-type is built and/or I say "I'll do it", there's no actual commitment by either parties.
3. I'm leaning towards working on a simple proto-type before making any promises that I will take the project up as even if I decide not to, I can..
a. still add the project to my portfolio of apps.
b. use the company as a referral regarding building a proto-type app for them
c. gain experience regarding freelance work (even if it would be unpaid)
I'm okay with the fact that it is unpaid during the proto-type faze as it's more of me testing the waters and seeing if I'd be comfortable enough taking up the project while checking my current level of knowledge.

Bonus: Everyone that works there uses Android 😆