tagin! offline version #21

@elyas-bhy this is a good start, here are my suggestions:

• Let's start by implementing your local copy idea but with a bit more flexibility. What about using a parameter on a server call so that users of the Android library have access to any number of neighbours that can be temporarily stored for local/offline use. I believe you already implemented a call to retrieve any number of neighbours, so this might just involve exposing an easy way to navigate the data retrieved through the library... e.g, a DB cursor.
  • It is important to note here that we should allow for an ordinal way to sort neighbors. For example, if a developer requests 15 neighbours but the URN only has 5, then we should look at retrieving the neighbours' neighbours going from the closest to the furthest neighbour. So the only time when we would retrieve less than 15 items is if the DB actually has less than 15 entries or if there is a discontinuity where, for instance, we have only 10 URNs somewhere in Canada and another 12 somewhere in France. Then there would not be enough neighbours' neighbours to fulfil the query. You might have already done this, just pointing it out. Hope this is not too confusing.
• Also, we should start by making local copies read-only... we can assess later whether we need to expose any engine functionality while offline (preferably not given the argument you made earlier about not implementing local URN generation). Instead, we should save all raw queries for the server so we can send them as soon as we are online.
• Finally, we should always keep a set of updated copies (i.e., update all copies when we are back online). The size of this local DB should be determined by number 1 above.

Hope this makes sense, sorry about the delay in getting back to you! Now to check the demo app.