Implementing a method that never returns the same data twice

Question

I have a mobile application which retrieves x number of ContentItems from a Web API, however I need a way to only display content that the user hasn't seen before on screen. (Just to be clear, the user only ever see's a single item of content once.)

Imagine the content class to be like this:

public class ContentItem 
{
    public int ID {get; set; }
    public string Foo {get; set; }
}

I can think of two ways of implementing this, both with serious drawbacks over the long term:

1. Returning x number of contentItems, then comparing it to an internally stored list of content id's the user has already seen.

Return the newest x ContentItems from the API, then compare these items to an internally stored (Mobile side SQLite DB) list of ID's which represent content items the user has already seen. If the ID of any of the returned items matches an ID stored in the database, then remove it from the ContentItem list.

Note: If the API returns 100 items of content, and the user has seen 3 of them, then I'd just display the 97 new items. This is also true for the inverse, (97 seen, 3 new) as I have a mechanism which detects when the user is running out of content, then runs the 'getContent' method asynchronously.

Drawbacks:

• What if the user has seen all off the content returned from the API? The obvious answer here is to re-run the method which collects the data, but this has performance implications. (If its a really heavy user, we could possibly end up running the method several times to get new content.) This also seems a little bit redundant as we have no idea what content we are going to get back.

2. Sending a list of seen content ID's to the server to ensure only new content gets returned

In this method, I'd use the internally stored list of content ID's that the user has seen, and send it to the Web API before sending the getData request. The API would then ensure any data it returns does not match an ID that's in the list of the previously seen content.

Drawbacks

• Sending two requests: This would mean I initially have to post the ID of every contentItem the user has ever seen to the API, then create a GET request to actually return new data. (Not sure on how much of a drawback this actually is, but one problem with this method would mean id be unable to asynchronously send the requests - How would I know once the server had finished parsing the id list in order to send the get request for example?)

• For really heavy users I may be posting a huge list of ID's (especially after 3 years of using the App for example), this could lead to performance problems.

It's worth noting that I have total control over the API and the App, and that the API only serves the App - There are no other dependencies.

If anyone has any feedback on which method they would go with (or any alternate methods) I'd greatly appreciate it!

Answer 1

If you have full control over the ID generation and the order in which content is presented, then it must be possible to guarantee that if I am looking at the ContentItem with ID 42, then I have already seen the ContentItems with IDs 0 to 41.

In that situation, you can use a simple variant of #2: In the GET request to the server, send the ID of the first unseen item (or the last seen one) and let the server return items from that ID onward.

Answer 2

Why not consider

3. Send a userID and let the server figure out what to send.

This will optimize network traffic in a big way - you're always sending the server a single piece of information of fixed size, and you're only getting back data that you will actually use.

You have the added benefit that if something happens to the user's device (or they want to view your content on more than one device) you can do the right thing.