More Work on Android
At this point I’m not overly enamored with Android development – maybe it’s because the code base I’ve inherited is not the best, but I’m looking forward to finishing up these cards and moving back to working on my .NET project full time.
This week I put the finishing touches on the functionality for the Android additions. Each room item that now has a new list of strings that will be populated with the student ID’s of anyone who will be billed for it – we do this mainly because each item needs to be able to be billed by different people, and if we just update the reference to the list each item has the data stays up-to-date with much less effort overall. To update this list, I added an onClick event to each item in the list I was working on last week. There was some difficulty involved with making this all work because we have to maintain a list of the selected people, but also a list of the people who are possible to be billed.
Once all the functionality was done, my focus shifted to making things look a bit nicer. For each item, I made the two fields that are displayed have a fixed percentage width so the data all lined up going down the list. I ended up making the onClick event also handle changing the item’s background color to help indicate that it has been selected – this led to a slew of refactors to make things a bit more concise. I also added a button to hide/show the list of people to bill – not only does this make the page feel less cluttered upon loading it, but it will assist us in restricting who can access the list of people to bill once we have proper authentication (a card for another day that is coming relatively soon once core functionality is all complete on the .NET side of things).
The only issue I ran into while doing the formatting of this view (aside from being generally not amazing at making things look pretty) was in making all the list display at once, and then for it to make the entire view scrollable when content got pushed off the screen. Prior to working on this, we just had a list view that showed about 3 possible items, forcing you to scroll down to view more items. This is undesirable because we want whoever is selecting people to bill to be able to see all the possible people (or as many as possible on a single screen) when doing their work. The caveat with this is we don’t want to have a scrolling within scrolling (the worst possible UX on mobile devices in my opinion). After a lot of painful investigation I realized that I needed to convert my current list view into a linear layout, and then wrap the entire view itself inside a scroll view. I had to rework how decent portion of the code worked to accomplish this, updating some of the formatting I worked on earlier this week as well.
Toward the end of the day on Friday I discovered an issue with the approach we took to updating each item’s list of people to bill. Because of how it is handled, there’s no explicit saving that needs to happen for that list to be updated. That is, a user can select a person to bill and simply hit the back button, not the save button on screen, and the list will be updated anyway. This will be something I’ll tackle next week.
Pairing on the Vacancy Report
This week we started Josh (the new hire I pair with regularly) on a completely new section of the application – a vacancy report. Essentially we want to know what rooms are completely moved out of, kind of like an opposite of our check-in queue. I worked through the kind of information we were going to need and pointed him in the right direction to services we had the likely would have all the information we need to complete this task. We used the housing location service that I talked about a building just a handful of weeks ago to get all locations that have people checked into them, and then compare that to the list of all facilities – the difference of these two lists yields us the list of vacant rooms.
Josh blazed through this card. It worked really similarly to the check-in queue so he had a lot of code to base this new section off of. I paired with him in the instances where he got stuck, but every day when I came in and checked in on what he was working on I was amazed by how much progress he had made. He even learned how React worked well enough to do most of the front end work by referencing existing components without much assistance. Most of the help I gave him focused on outlining what I think he had to do next, and then helping him write up tests to verify his changes were all working as intended.