@yenda ok, got it
If it’s not going to consume devices resources too much it might be fine.
yes that is why the idea would be to pause the node in-between checks to minimize resources consumption.
Android update
I implemented simple local notifications and foreground service. When the app starts it starts the foreground service which does nothing except keeping the app alive.
As a result I am able to receive notifications even when the app has been in the background for a while. The only way for the app to die is to be killed by the user himself, which then terminates the service and the app.
I will now test impact on battery of this naive approach.
Further possible improvement:
- Proper notification namespace
- Handle different kind of notifications (mentions, messages, incoming transactions…)
- Logo for notifications
- Use messaging style for notifications: Create a notification | Android Developers
- Add a sound on notification
- Have heads-on notifications
4 Likes
After running all night I was still able to receive messages in the morning and it only took 1% battery. Sorcery!
8 Likes
I love this! Lack of notifications is one of the main annoyances for me, and getting something usable into v1 (at least on Android) will be great
@alexcg1 notifications are not lacking though, they just suck because of how they work currently
Further experimentation showed that battery usage is very reasonable.
Some OS with a stupid battery saving algorithm like OnePlus OxygenOS still kill the app in violation to the Android Compatibility Definition and should be reported to Google but that is an other story. There is an easy workaround for the user which is to lock the app in the recent apps (the square bottom buttom, then upper right corner 3 dots, lock action).
I am now working on making the POC mergeable so that the next step will be to remove Firebase entirely.
not working
now working?
Brilliant! So additional question does that mean message syncing is also much much better (because the polling action fetches the messages already)?
@yenda So additionally, I think we could investigate using the same poll loop for IOS - but schedule it as part of the “Background Fetch” loop (don’t know much about lower level IOS) - this is not a guaranteed callback, but could offer us a ‘degraded’ path for IOS devices.
Current situation
6% battery, the app was not killed after a full night and playing some VR game. As mentioned previously I had to lock the app in the recent apps due to a OnePlus issue.
It currently notifies for every message that you receive on any chat. The layout of the notification is a bit messy because I experimented with different features to see what we can do. We can show the profile picture, name of the user, use custom sound and logo, have direct actions in the notifications.
It works by running a foreground service that does nothing, which prevents the system from running the app.
Design implication (@maciej @hester)
We have to somewhat convey to the user the information that status needs to be running in order to receive notifications. Since a foreground service uses a sticky notification to make the user aware that it is doing something, we could for instance have a “everything fine” notif with some basic action shortcuts, and if for some reason the app is not running, some “something went wrong” or “login to get notifications in status” notification showing up when that is not the case.
Short term goals (end of day)
- notifiy only for 1-1, group chats and mentions: right now I naively call
send-notificationsomewhere in theadd-message(although technically it’s not sent, it’s a local notification on received message) - clean up notification layout: I think I will go for something similar to what’sapp and it’s “you have x messages in y chats”, then the last message of each of these chats.
? - remove firebase ?
Later goals
Investigate bounded service and headlessJS tasks. The idea is that instead of having a foreground service that does nothing, it actually runs status-go and some headlessJS tasks (request mailserver messages, handle notifications). Ultimately that should mean that the app can start itself in the “background” (still a foreground task with sticky notification, just no UI) and start receiving notification.
I would NOT recommend starting the app on reboot or when killed though. In my experiments, the app only gets killed when I force stop it from the application settings, and zombie apps that keep coming back when you don’t want them to are usually annoying people. Instead, we could have a notification with an intent to start the app service popup on startup inviting the user to start status service to receive notifications. Same when the service gets destroyed for some reason.
2 Likes
Do you have an example of such a sticky notification I can take a look at?
@hester it’s a notification like any other, except that it is sticky, so when you try to slide it away it stays.
Got it, thanks! You’re right that we need a way to explain what the app is doing and offer an option to stop running in the foreground.
I don’t know this app, but I like the approach. wdyt @maciej?:
Status is running
Checking for direct messages and mentions
Stop
(first stab, let’s iterate on Figma)
Checking for direct messages and mentions might be a bit too alarming considering it will stay on all the time. The app isn’t doing much but it stays active and receives incoming messages. It also receives new blocks so it can notify about wallet events as well.
Staying with our walky-talky metaphor we could go for something like:
Status is running
Receive mode
Switch off
2 Likes
