Hi, the obvious solution is to run service that is 24/7 on and separate client for GUI. That's what stock messaging is doing. I would recommend it and use some simple messaging API for communicating between them. There are probably many APIs to choose that will allow you to set it up simply.
If you can withstand short shutdown of the service then you can combine it into the same application. It would require that application will start in GUI or server mode depending on command line option. If started in GUI mode, you would have to * shut down service via systemd * establish new connections and on GUI exit you would have to * drop all connections * start service via systemd The latter is the way OSM Scout Server works with the adjustment that its using systemd sockets to keep it switched off when user is not accessing it. Note that it was done for historical reasons (signaling between parts was implemented via Qt) and since its mostly used as a service anyway (users don't need to access GUI for weeks). I would still recommend splitting service/GUI parts and use some messaging protocol in between. Myself I would have used zeromq, but you could choose probably many others. Cheers, Rinigus On Mon, Feb 5, 2018 at 11:17 AM, Marcin Mielniczuk <marmistrz...@gmail.com> wrote: > Hi, > > When creating SFOS applications which should run 24/7 (e.g. IMs) we > would like to achieve similar behavior as the stock applications, e.g. > the stock e-mail client: the sync (*) runs in the background, even > though the application is closed. A window staying open just to make > sure the sync goes on clutters the open app view and makes it more > difficult to manage the open applications. > > On a desktop DE one would simply minimize the application to tray. > Alternatively, one could create a daemon which the client app would > communicate with using UNIX sockets, but it greatly increases the > complexity of the application and slows down the development. > > What's the easiest way to keep the sync process in the background > without keeping the window open? > > Regards, > Marcin > > (*) when speaking sync, I mean any kind of waiting for a remote event, > no matter if it's done by idle TCP (which is good) or HTTP polling > (which is not good) > > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscribe@lists. > sailfishos.org
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
