Welcome to the second session! For the rest of my day, I’ll be looking for replies to this thread and will answer your questions. If something remains unanswered, replies can be posted even during the following days.
Just like the first time, there are no rules - “anything” is anything! Feel free to ask development questions, future plans, or things completely unrelated to Raccoon.
Most importantly, have fun!
deleted by creator
Normally, in commercial services, push notifications require support from the backend. The mechanism works approximately like this: the mobile app registers to a third-party provider such as Firebase Cloud Messaging (on Android) and APNS (on Apple Push Notification System) and obtains a device token, it then makes a network call to the server to communicate their device token (and the user ID this is associated to) and then the server dispatches notifications using the user ID to determine the events of interest and the device token to have it delivered via Firebase or APNS depending on the platform. Lemmy instances, unfortunately, don’t do anything of that so client apps have to periodically poll for new events, which is terrible for both the battery and the network usage. Raccoon is no exception of this, if you look in the “Advanced Settings” screen under the “Experiments” section, there is an item named “Check for unread items in background”. This is an attempt to use Android’s WorkManager APIs to perform scheduled periodic operations such as checking for new mentions/replies/messages. Unfortunately, the scheduler does not seem so reliable so after some time the app is in the background the pending work can never get to be executed. It was an attempt and it should be refined.