Notice removed Draw attention by Pablo Almeida
    Bounty Ended with blue's answer chosen by Pablo Almeida
7 added 2 characters in body
source | link

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?


EDIT: As requested, more information about the problem which might be useful:

  • My query currently is of the form "the latest 1000 entries, from newest to oldest, if they are newer than 2 weeks". 1000 is a number so high that is effectively infinite, for the purposes of my application. 2 weeks is a time interval so long that the user should not want to be notified about that information anymore, as it is highly unlikely to become relevant by that time.

  • All entries have a "created" timestamp. They also have an "updated" timestamp, which, if exists, should be treated as the "created" date for the purposes of my application. I do not expect answers to account for this technicality, though.

  • All entries have aan "importance coefficient", which is the value I am tracking. I notify the user only of entries with this coefficient higher than a set threshold. Since this value changes over time, I cannot simply ignore entries I have already fetched before and found to not be relevant. Changes in this value do not affect the "updated" field.

  • If the user dismisses the notification about aan entry, its notification should be filtered out the next time a query happens. Comparing the IDs is enough for that.

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?


EDIT: As requested, more information about the problem which might be useful:

  • My query currently is of the form "the latest 1000 entries, from newest to oldest, if they are newer than 2 weeks". 1000 is a number so high that is effectively infinite, for the purposes of my application. 2 weeks is a time interval so long that the user should not want to be notified about that information anymore, as it is highly unlikely to become relevant by that time.

  • All entries have a "created" timestamp. They also have an "updated" timestamp, which, if exists, should be treated as the "created" date for the purposes of my application. I do not expect answers to account for this technicality, though.

  • All entries have a "importance coefficient", which is the value I am tracking. I notify the user only of entries with this coefficient higher than a set threshold. Since this value changes over time, I cannot simply ignore entries I have already fetched before and found to not be relevant. Changes in this value do not affect the "updated" field.

  • If the user dismisses the notification about a entry, its notification should be filtered out the next time a query happens. Comparing the IDs is enough for that.

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?


EDIT: As requested, more information about the problem which might be useful:

  • My query currently is of the form "the latest 1000 entries, from newest to oldest, if they are newer than 2 weeks". 1000 is a number so high that is effectively infinite, for the purposes of my application. 2 weeks is a time interval so long that the user should not want to be notified about that information anymore, as it is highly unlikely to become relevant by that time.

  • All entries have a "created" timestamp. They also have an "updated" timestamp, which, if exists, should be treated as the "created" date for the purposes of my application. I do not expect answers to account for this technicality, though.

  • All entries have an "importance coefficient", which is the value I am tracking. I notify the user only of entries with this coefficient higher than a set threshold. Since this value changes over time, I cannot simply ignore entries I have already fetched before and found to not be relevant. Changes in this value do not affect the "updated" field.

  • If the user dismisses the notification about an entry, its notification should be filtered out the next time a query happens. Comparing the IDs is enough for that.

6 Added some more info
source | link

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?


EDIT: As requested, more information about the problem which might be useful:

  • My query currently is of the form "the latest 1000 entries, from newest to oldest, if they are newer than 2 weeks". 1000 is a number so high that is effectively infinite, for the purposes of my application. 2 weeks is a time interval so long that the user should not want to be notified about that information anymore, as it is highly unlikely to become relevant by that time.

  • All entries have a "created" timestamp. They also have an "updated" timestamp, which, if exists, should be treated as the "created" date for the purposes of my application. I do not expect answers to account for this technicality, though.

  • All entries have a "importance coefficient", which is the value I am tracking. I notify the user only of entries with this coefficient higher than a set threshold. Since this value changes over time, I cannot simply ignore entries I have already fetched before and found to not be relevant. Changes in this value do not affect the "updated" field.

  • If the user dismisses the notification about a entry, its notification should be filtered out the next time a query happens. Comparing the IDs is enough for that.

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?


EDIT: As requested, more information about the problem which might be useful:

  • My query currently is of the form "the latest 1000 entries, from newest to oldest, if they are newer than 2 weeks". 1000 is a number so high that is effectively infinite, for the purposes of my application. 2 weeks is a time interval so long that the user should not want to be notified about that information anymore, as it is highly unlikely to become relevant by that time.

  • All entries have a "created" timestamp. They also have an "updated" timestamp, which, if exists, should be treated as the "created" date for the purposes of my application. I do not expect answers to account for this technicality, though.

  • All entries have a "importance coefficient", which is the value I am tracking. I notify the user only of entries with this coefficient higher than a set threshold. Since this value changes over time, I cannot simply ignore entries I have already fetched before and found to not be relevant. Changes in this value do not affect the "updated" field.

  • If the user dismisses the notification about a entry, its notification should be filtered out the next time a query happens. Comparing the IDs is enough for that.

    Tweeted twitter.com/StackProgrammer/status/713024738558349313
    Notice added Draw attention by Pablo Almeida
    Bounty Started worth 50 reputation by Pablo Almeida
5 Made an important point clear
source | link

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again. The

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, soand I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again. The query to the service might return data which were already retrieved before, so I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?

I am developing an application which sends certain notifications to the user as read from a read-only external service. The user might dismiss notifications, and those should not appear again.

I cannot ask the server to give me only entries newer than than my last query because I am particularly interested in a value that changes over time. I have to give entries a chance for at least a week or so. Because of that, the queries to the service might return data which were already retrieved before, and I need to filter the ones already dismissed. I can do that by looking at the IDs of the received entries, which appear to be SHA hashes.

I can save those IDs to the Preferences as id -> boolean pairs, or in a SQLite database, but surely they will reach some limit sooner or later.

Also, I do not really need to check the older entries. I could put a hard limit on, say, the 100 latest entries and that should be more than enough.

How should I approach the disposal of old entries to ensure I don't go over the limits?

4 edited comments into the question
source | link
3 edited title
source | link
2 edited title
| link
1
source | link