Now that I have a client SDK handling this instead of having to re-implement an SDK for myself, this should be easier to achieve robustly, which hopefully means the notifications should work on boot instead of needing the app to be launched at least once after boot, even if you subsequently close the app. If that problem doesn't go away using this SDK which provides a local database and a more robust way of communicating with the server, then the problem is probably a lack of network permissions on the foreground service which should be solvable by adding those permissions with the intent that launches it.
In general though this task should be quite simple with the only annoying thing being properly constructing notifications from the data given while trying to keep as much of the database out of memory as possible.
Now that I have a client SDK handling this instead of having to re-implement an SDK for myself, this should be easier to achieve robustly, which hopefully means the notifications should work on boot instead of needing the app to be launched at least once after boot, even if you subsequently close the app. If that problem doesn't go away using this SDK which provides a local database and a more robust way of communicating with the server, then the problem is probably a lack of network permissions on the foreground service which should be solvable by adding those permissions with the intent that launches it.
In general though this task should be quite simple with the only annoying thing being properly constructing notifications from the data given while trying to keep as much of the database out of memory as possible.