Hi Charles,
So the easy part of these questions are on timing. The TMM or TID login is basically an OpenID based login - therefore we have two kind of token:
Access token --> lifespan of 14h
Refresh token --> lifespan is long (30 days).
So the access token is used for e.g. geoid download and all other web service interactions that happen in the background. It goes stale after 14h but can be refreshed with a refresh token - which typically has a much longer life span (30 days in our case).
The license file itself has also a lifespan of 30 days - so the license must get refreshed within 30 days.
When you login via the corresponding intent TMM will download 'your' license (so the license file is specific per app per user) and TMM will also refresh all licenses it knows about if TMM is running (and not killed). So TMM tries to keep things up to date as well.
If TMM is not running you can use the
com.trimble.tmm.RefreshUserToken
intent to update tokens; if you take a look at the facade sample you'll see that we run this in a Timer thread parallel to the facade main model.
So a really granular model would check when a specific user downloaded his license - and then call the RefreshUserToken say after 20 days (if online etc). This means that if the device is online within the 10 days time window the user will not see a TMM login screen - the refresh will happen in the background and there is no UX break.
Alternatively the refreshToken intent can also be called in the beginning - when the license file was loaded from disk and the device is online (so I'm assuming the TID of the user got stored somewhere).
The Login intent works in a similar way - but it might be that the UI flickers slightly. I actually can't remember but thats something we can double check here as well - and see if that flickering is really 'required'.
Hope this helps - I think the important numbers are 14h and more important 30days.
Regards
Nico