Bump - Native App Background Notifications

Feature Requests
#1

I know this has been asked for before, but … bump.

For those of us who use native messaging, social or similar apps (my main ones are Sailslack, Fernschreiber and Piepmatz) a key missing feature is to be able to receive notifications of new messages, etc when these apps are closed (i.e. using a daemon or whatever). We always have to remember to keep all these apps open otherwise no notifications are received. This doesn’t always work as if too many apps are kept open then the phone simply runs out of memory and starts closing them. Also if you forget to keep the app open you are also going to miss what might be important or urgent mssages.

I believe background notifications for apps are not allowed due to some Jolla restriction rather than a lack of support in the OS (Jolla email, messages have background notifications) which, in a modern OS, seems … well … an odd decision.

Of course the biggest irony is that if we abandon native Sailfish apps like Fernschreiber, etc and use the equivalent Android apps (Telegram in this case) on Sailfish instead then background notifications work just fine.

So it seems Jolla allow background notifications from Android apps on SFOS, but not from native apps developed for their own OS - a strange decision indeed - and perhaps one best now remedied.

What do you think @flypig?

2 Likes
#2

So you are asking as much for background services in general, as for notifications in particular, correct?
(Wasn’t the former bumped just recently too?) Not a big fan of reposts… but somehow this feels warranted.

Nothing strange here… Android has a model for it, whereas Sailfish doesn’t really have one outside of the built-in accounts support. Let alone one that is modeled enough for making sure apps behave and conform to set guidelines. I believe this is running with elevated privileges, and from what little i have seen about it also wouldn’t necessarily be a perfect fit in the general case.

But as for things running in the background in general; surely that is doable, and surely they could raise notifications - it just wouldn’t be allowed in store.

Edit: I agree with you that this is important, but i think we’d do well to be more constructive to get some real movement on it.

1 Like
#3

Well, I am a user, not a developer - so I can legitimately say that the technical intricacies, design strategies and implementation models - whether specific to notifications or general background services, don’t really interest me. What interests me is the end-user functionality - so, for example, when somebody sends me a <insert native messaging/social app name here> message I would like to know about it even if that aforementioned app is not open - in exactly the same way as I receive notifications for SMS or emails.
The current situation is rather like driving a car and having to press a button every few miles to see which warning might lights illuminate on the dash.

Well, Sailfish is a Linux OS and Linux has been doing this for decades- so surely there must be some open source model/software implementation/set of libraries that could be relatively easily adapted?

As for the security issue that individual third party developed app daemons could do naughty things - sure, but if you say that app developers can already do this now then isn’t that yet a further argument for having a proper OS based approach for doing this?

How is my request not constructive? Its … er … a request in the ‘Feature Requests’ section requesting a not yet available feature. I hardly think that pointing out the irony that native Sailfish apps can’t have background notifications but Android apps under Sailfish can is negative or destructive. You’re over thinking here. What this irony does do, sadly, for these types of apps, is to make Sailfish users consider Android apps over native Sailfish apps because in this respect they’re more usable - and that can’t be good for the Sailfish ecosystem.

#4

My point exactly; if we could find one and perhaps even evaluate it a bit, that might move things along.
Or maybe it all just really is the wild west…

Yes, just as it is background to why it does not yet exist… which you seemed to feign surprise over.
I know you understand this.

But i do, and i’m fairly certain others would agree. It is wholly besides the point of solving the problem. And unless you actually think disabling android background notifications helps it doesn’t qualify as even close to helpful.

1 Like
#5

Well, your disappointment in me and just about any other user on this forum who has a different point of view to yours is just something you’ll have to live with I guess. Time to move on.

#6

See point 11 from this community meeting.

3 Likes
#7

@pherjung thanks for this. I did see these minutes and, in part, they were what caused me to bump the issue. My feature request is specifically about background notifications. One positive thing that @attah did highlight in his post was the difference between ‘background notifications’ and ‘background services’.

I am not skilled enough to know the difference, but assuming that ‘background services’ are more general than ‘background notifications’ got me thinking about whether there was any possibility that something could be done specifically about background notifications any more easily or quickly than perhaps a wider background services model.

I confess that my hopes aren’t high, but let’s see what the response is - both from users on this forum who might also want this, developers who would incorporate this in their apps if they could and, finally, Jolla who might think about how they could provide this according to the demand.

If it all falls flat then fine. I asked, nobody responded, Jolla said ‘No’ or ‘Not yet’. Nothing is lost.

#8

What i did mean to say was that without a full-on background service your notifications would have to conform to a very strict set of limitations, and be pushed to you by a server in a specific manner. So your examples are afaict solidly in the service category, being custom protocols. (Unless you’d like said server to hold your sessions with your accounts with the rework of those apps which comes with that…)

2 Likes
#9

For Social Media it would be helpful if the Browser would support WebApps, Service Workers etc. and could get notifications that way.

2 Likes
#10

As simple end-user, just 2 cents:
I could appreciate having background things running to inform me in some cases.
At least, I have nothing against this.
But I’d regret very much if it would become mandatory or complicated to disable.

I am very happy being able to be where I am, do what I do, talk to who I talk, without being interrupted. Because my attention wouldn’t resist to notifications.
In my usage (not excluding other’s usages), phone + sms is enough for important things.

Being able to have peace with nothing more is a great feature for me.

1 Like
#11

I think that most apps would have a simple ‘Enable Notifications’ option in their settings, so you could turn notifications on or off as you wished. Fernschreiber already has this, but obviously it only works at the moment when the app is running.

1 Like
#12

I probably know less than anybody, but isn’t it up to each app/developer to provide it? For example, Yottagram by @Mister_Magister offers “daemon” option in settings, and last I checked, it worled fine…

2 Likes
#13

Yes, yes it is. Even in android, apps just run separate process called service for notifications while in sfos we can just run entire app because why not, we got true multitasking.

Just write separate process to listen to notifications and call it a day, don’t bother jolla with stuff they shouldn’t even be doing

3 Likes
#14

^ I agree with @Levone1 and @Mister_Magister here.
However, tbf, OP is asking about native notifications which means the functionality is built into the OS.
Personally I have no need for this except for the few apps that already do that.

That is not what I read in the article @pherjung linked.
It says very clearly “We are working on it.”

If this ever gets implemented I dearly hope it will be optional.

1 Like
#15

Do I understand this right that in fact every sailfish app could get notifications if the dev wound offer his “daemon” especially for the app?
Is this daemon thing some kind of cron job?
(Sorry, I’m no dev, just a curios user wanting to understand…)

#16

Well, that’s not what I said either:

There’s a big “if” at the beginning of the sentence that you didn’t quote - so "if … … Jolla said ‘No’ or ‘Not Yet’…Nothing is lost. So, a different meaning completely if you quote the whole sentence, eh?

@Mister_Magister do you have some sort of official role approving feature requests before they are allowed to ‘bother Jolla’ then?

#17

Yes, I think this is what is being said. An app would need its own daemon always running in the background listening for new messages, synchronising them or whatever - and then sending a system message to whatever OS process raises notifications on the home screen and the pop ups at the top of the screen.

What I am still not clear about from all these experts who have posted replies is whether the Jolla rules don’t allow the daemon process, and why, or whether its the the use of the Jolla internal OS notifications system that is not permitted. In other words a daemon process is allowed but it has to then duplicate the effort of producing notifications itself.

I’m assuming the cleanest solution would be that every app needed its own daemon process for listening/synchronising (because the protocols, synchronising servers, etc will be different for every messaging app) but then would then be able to raise a notification using inbuilt OS functionality. Obviously the models, libraries, code, etc must already exist for any Linux based OS.

#18

See previous post below.

Notifications are optional on every other OS (Android, IOS, Linux, etc) - both generally overall in settings and at an individual app level. I don’t see why Jolla, if they do decide to do something about this, would want to do it differently so that notifications were always mandatory.

#19

I’ve been thinking about trying to do this in an app:

  • In main() check if org.example.myapp is registered on D-Bus
  • If it is not, then fork a new process:
    • Original process (not forked) registers that D-Bus name and providing notifications etc. and thus becomes our background service.
    • Forked process creates and runs UI and connects to this service process to share data.
  • If the name was already registered, then make a D-Bus call to this owning service (our background service):
    • The background service responds to the call by checking if there is an UI process already and tells it to bring the window to foreground or forks to create new UI process.
    • After the window is exposed, main() can quit.

While I think the principle is sound, I’m not totally sure that there won’t be some unexpected things happening somewhere. A good thing is that now both the background service and the application window process run in the same sandbox and the sandbox should be alive as long as the background service is running. The bad thing is that lipstick (= compositor, does window management) might get confused about the application that’s running in this new window. These two processes can choose quite freely how to communicate since they are in the same sandbox: They could keep on using session D-Bus or use sockets directly (with or without D-Bus) or even files or pipes on shared tmpfs.

Additionally, it’s possible to streamline this a little by using D-Bus activation from lipstick. When the app is opened from a launcher it would actually trigger IPC call in that background service which is then able to fork a window without doing any of these D-Bus name checks or going through main(). This would be way faster than creating a sandbox to launch a new process which is going to quit soon anyway.

This is all quite rough and I haven’t tried any of this yet myself. There might be some use case for doing fork-exec for the UI process but that’s something to experiment. I hope some of you made some sense of this and hopefully this gives some food for thought to some developer trying to implement background services.

Another direction you could approach this same thing is keeping the service and UI processes the same and trying to not stop the process when ApplicationWindow is destroyed. I think that should be also doable. It might be wasteful when the UI is not running but sharing data is easier.

2 Likes
#20

On Android or iOS exists a quite complex structure for push notifications.
But the principle is simple and the system relays on three components:

  • P: push server (e.g. from google)
  • A: the server of the service (e.g. Telegram)
  • Client: app on your smartphone

Lets create an example:
The server A gets a new message and wants to inform the client. The app on the client is not running at the moment and checking for new messages. The server A sends the information: “client: you have a new message” to the push-server P. The server P now informs the client, that for the specific service there is a new message and displays them. If the user now clicks the message the correct client app is launched and can handle the context.

The advantages are:

  • only one deamon is running at the client. Which ideally uses a connection type that don’t beed that much resources.
  • A normal dev does not have to handle with background tasks.
    The disadvantages are:
  • the service A has to push to server P (not easy if you do not develop the server A)
  • the push server may be in the position to collect personal informations and usage data

Nevertheless: it would be quite an interesting task to take a look to all the different push services (Server an client code) that already exist and to check if one of them is usable on SFOS.

1 Like