Our team began work on the offline login service this sprint. We decided to first investigate AMPATH’s current login process, which turned out to be spread over many different components and services. We found where information was sent to the servers for authentication purposes and determined that what we needed to do was to point to an offline database instead of the servers. There would be no point in creating an offline login service from scratch, and in fact we needed to use their implementation if we wanted to meet the requirement of seamless transitions from online to offline and back. We created a mockup on Balsamiq of what we thought the finished login process should look like with both offline and online options. We would use the online tracker being refactored by another team to determine whether there was an internet connection, and send the user’s credentials to a server or an offline database for authentication based on the connection status. We began to think implementing this was dependent on having an offline database to work with, and we weren’t sure how to proceed before the team working on that piece completed their work.
We also learned about the bridge pattern this sprint, which we expect will be used to handle checking the online status for all the pieces of the app which will be able to function in two different modes. George posted some good resources on it to the team channel, which can be found below:
There were a couple of impediments to our progress this sprint. Multiple classes were canceled due to bad weather, and for this reason we weren’t able to collaborate as much or as effectively with the groups handling the encryption service or the offline database service as we had wanted. We did end up learning about some of the difficulties the offline database team ran into which apply to our service. They explained that patient data can’t be encrypted based on one doctor’s login information, because if it is, other doctors won’t be able to access it. They found a workaround, so going forward we’ll have a clearer idea of what’s meant to happen with the login information we send to the offline database.
The cancellations impacted our group’s ability to work together as a team as well. We do better when we can meet with each other in person and update each other on the progress we’ve been making in more detail than the stand-ups. Regardless, all team members answered the stand-ups in good detail and kept each other updated through the team channel, and I think overall our collaboration is getting better with each sprint.
One more impediment was that we discovered that we didn’t have access to server-side code to see what normally happens to the login information once it’s sent, which would inform our offline implementation if we had access to it. We plan ask the people at AMPATH whether that code can be shared with us in the near future. We also plan to make at least a mock of an offline database to use temporarily for our login service, and we might start using PouchDB ourselves if it’s not too involved. If nothing else, we will understand what the offline database team is doing better and be able to integrate our piece into the overall design more cleanly when the time comes.