The Client-Side SyncServer Sign-In System: Making Sign-in Sticky


It looks like it’s time to restructure the client-side of the SyncServer sign-in system. The starting point for this thought came from When I started looking at the problem Dany was having — having to sign-in regularly. I realized that I wrote the code around the idea of signing the user out if anything bad happened. Poof. A network error, and you get signed out. This doesn’t bode well for offline usage. It also doesn’t bode well for an app/device that doesn’t get network access immediately when the app starts.

While I designed much of the SyncServer client with offline usage in mind, I didn’t focus on this with the sign-in system. I made an initial effort to retrofit offline usage into the current sign-in system, but it got pretty darn cumbersome. Hard to reason about. Lots of states. Instead of going forward with that retrofit, I’m instead going to restructure this sign-in system and make it oriented to offline usage from the ground up. My focus is going to be on trying to keep the user signed in for the longest period of time possible. This is not a marketing strategy where I’m concerned about losing customers; if the user actually does a sign-out operation from the UI, they will definitely get signed out. Rather, I want to create a mode of operation where the typical mode is signed-in, and there are few transition points where it is possible for sign-out to occur. I’m going to call this a “sticky” sign-in: Once signed-in, you tend to stay signed-in.

Sign-in should persist across app launches. This is part of a sticky sign-in. Just because the app is relaunched, this should not constitute a means of signing the user out. Of course, because credentials can expire, credentials need to be refreshed periodically. A natural place to do that refresh is when the app launches. However, there are two problems with that: 1) the app/device may momentarily not have wifi or cell data access when the device launches, and 2) the device may be offline more generally– e.g., the device may be in airplane mode. Neither of these two situations should sign the user out. An app should still regard the user as signed in, and when network access is regained, then it can refresh credentials.

The meaning of “being signed-in” now changes in the app– at least programmatically. And to some extent in the perspective of the user. Previously, when the user was signed-in the app had credentials for the user and could make server API requests. Now, when a user is “signed-in” we may or may not have credentials for them. If we have no credentials, it should also be the case that we also have no network access. So, an inability to make server API requests should have no consequence. Plus, when the network comes back online, my plan is to trigger the credential refresh at that point.