Closed CR4567 closed 1 year ago
I also changed the multiplier for the requested count. Not sure why this should be needed.
It is hard to understand the pr on mobile but we are doing that already, depending on the api version.
I think the multiplier is used because the query filters out notifications after queried from the db and therefore 100 are not like 100 in the other query.
yes you have two possibilities. Version 1 queries all "my" notifications. So you would possibly get notifications from other devices too. That was the reason of version 1_4 which uses get_my_device_notifications. But device in this case was defined by the token. I think it should be the device Identifier because it's more durable. Maybe just a small optimization but it prevent some lost notifications.
The Endpoint on the backend is using a "value contains" condition for the configuration, so it shouldn't matter if it's a token or deviceIdentifier for which is queried.
I see the point with the multiplier. Can check it later in notifo code.
Now I see it
just checked the take parameter and you're absolutely right, it's filtered a second time on the first "take" * 2 notifications. So it's fine to increase the size of the list.
Can you add a comment?
added a comment but with these changes I expect some problems with the unSeen property. Maybe we have to set it to false. If I understand the notifo code correctly, we should now receive all notifications doesn't matter if they are seen or not.
Changed the query parameter from Token to DeviceIdentifier. Token can change over time and so it could be possible that notifications wouldn't be downloaded if you're offline and your token changes in meantime. Same when you logout and login again.