Background service in SailfishOS
 

I am working on Pebble Watch support for SailfishOS.
Current implementation requires having an application open which talks to the smar****ch proxying call notifications etc. which is not very robust.
I would rather have some background service I don't have to remember to launch. Preferably D-Bus activated.
What is the suggested way of implementing such service in Nemo/Sailfish?

Re: Background service in SailfishOS
 

Haha It sensored smar t w a t ch.

Re: Background service in SailfishOS
 

what problem in using dbus services? it's best way to do it :)

Re: Background service in SailfishOS
 

No problem really. QtDBus Adaptors are great.
Just asking whether it is the right way to go with Sailfish?

Re: Background service in SailfishOS
 

it depends, fx, you need to consider if you want your stuff on Jolla store (or openrepos ;) )

Re: Background service in SailfishOS
 

there are nothing to consider. if you want to make background service you can't be published in Harbour. There are no other way :)

Re: Background service in SailfishOS
 

Sure there is something to consider.
But, if wanting to use dbus, then the decision is not-jolla-store :P

Re: Background service in SailfishOS
 

any background daemons are not allowed for Harbour. There are nothing to consider ;)

Re: Background service in SailfishOS
 

So for an app like that, one should keep app open and listen for dbus events?
I'm willing to do something simpler for a push button like pressy, so was wondering how get started.

Re: Background service in SailfishOS
 

is this due to unfinished APIs or a final say as in, this stance will never change? If so time to go back to Android...

Re: Background service in SailfishOS
 

Please do not derail the thread.

Re: Background service in SailfishOS
 

@m4r0v3r what is your question about?

Re: Background service in SailfishOS
 

But who cares about the store? Chum is where the money is.

Re: Background service in SailfishOS
 

@m4r0v3r if you asking why store not allowing background services answer is simple: because dbus daemons can be started as root, and there are no checkings if you starting it as regular user or root, and because of that it's just forbidden at all :)

Re: Background service in SailfishOS
 

No, that's not true for user/session services.

I suspect the problem is that there's no task manager/service control UI to lay blame to a specific program.

Besides, opportunistic suspend makes daemons completely useless.

Re: Background service in SailfishOS
 

not entirely true, but close enough. At best it makes daemons run unreliably. At least without nasty hooks.

Re: Background service in SailfishOS
 

That's not a problem for Pebble daemon, as long as ring/sms/notification wakes up the device :)

Re: Background service in SailfishOS
 

Care to elaborate where exactly is that money?

Re: Background service in SailfishOS
 

thats exactly what am asking, thank you :)

do daemons not run effectively due to wakelocks? or atleast how deep sleep is implemented through wakelocks??

Re: Background service in SailfishOS
 

It will only wake the device for less than a second, unless you or someone else takes a wakelock. (Which are also forbidden in store btw).
If your BT connection is e.g. parked, or has been lost, etc. your program will take more time than what the system needs to display the notification, and will then happily proceed to suspend while your program hasn't yet forwarded the notification to the watch.

Re: Background service in SailfishOS
 

Well, considering all the current Jolla store limitations, I would advise Sailfish OS application developers:
Don't care about the Harbor limitations and make your application as awesome as possible instead! :)

I understand the while the limitations are there (apps not breaking due to upgrade, missing API versioning, fear of increased power consumption, missing security mechanisms, etc.) but at the same time they pretty much limit any non trivial application that actually does something useful from being included in the Jolla store.

The best way to improve the current situation is in my opinion to just build awesome applications that make use of the "banned" functionality and publish them on OpenRepos (or any other suitable place of your liking). As OpenRepos has detailed application download statistics this will clearly show how popular your app is and how many users the Jolla store is missing.

This could be a good incentive to either make Jolla to reconsider the limitations (or fix the shortcomings that require them) or might even make OpenRepos the one true Sailfish OS application repository (some might feel that this has already happened) in place of the Jolla store, thus also solving the issue. :)

Re: Background service in SailfishOS
 

Shouldn't just putting rpm on the web and making it "clickable" from the Jolla browser be enough?
Why do we need OpenRepos?

Re: Background service in SailfishOS
 

OpenRepos just because awesome Warehouse client and update package notifications :)

Re: Background service in SailfishOS
 

Makes sense. :-)

But still I would advice newcomers, that when it comes to distribution, they could throw an rpm anywhere on the web. Just make that damn app.
I've seen having to understand stuff like OBS, repos etc. to discourage new devs as too complicated.
After a few releases, they will grow into OpenRepos. :)

Re: Background service in SailfishOS
 

I thought the original suggestion was an irony :)

There are dozens of reasons why this approach is wrong. It's the Windows' "search for an .exe and pray it's not infected way"... I'd rather have newcomers unable to install any apps at all than having them trust random rpm's all over the internet.

The bad thing is, OpenRepos are currently broken (and don't get me wrong, I do use them) as they have no source verification, but psychologically act as an authority (so in the end it is worse, since people are in fact downloading random .rpm's from the internet, but do no feel like they do). Let's hope this changes once they are connected to OBS (plus there's chum!).



Back to the topic, I've looked into timedclient-qt5 and it should be quite easy to create a GUI like Alarmed on Maemo 5 to schedule background jobs. Timedclient-qt5 even seems more powerful than Alarmed, but unfortunately lacks proper documentation.