Interface for Snappy Apps that understand Unity8 Application Lifecycle

[Ted Gould]

On Mon, 2016-05-30 at 14:23 +0200, Michał Sawicz wrote:
> W dniu 27.05.2016 o 19:48, Ted Gould pisze:
> > In a nutshell, it is listening to a set commands that are sent via
> > the
> > Mir connection from QtMir/Unity8 which correspond with the
> > different
> > states that an application is put in. As an example, it is told
> > when it
> > is about to be suspended so that the application can save data in
> > memory
> > to disk. For QML/Qt apps this is implemented in the QPA plugin.
> > Applications that do not speak this protocol could lose user data
> > if
> > they were killed by Unity8 and didn't realize they needed to use
> > their
> > chance to save.
> I just wonder if this is anything really unity8-specific. We've not
> created special APIs (at least not compared to Qt ones), we're not
> actively killing apps for no reason, it's just that we're more
> resource
> constrained and OOM killer kicks in quicker. When closing apps, we do
> tell apps, after waking them, when the user closes them, so they know
> they need to save data (we're not giving them a chance to prevent
> closing, at least not yet).
> 
> Well-behaved apps (LibreOffice, Firefox) do this already by
> periodically
> saving restore information, would you consider those as "supporting
> the
> unity8 lifecycle"?
While other systems like Android and iOS have this type of behavior, I
don't know of anyone else doing it on a GNU/Linux. Certainly they could
, but they aren't. While we tell apps when a user closes them, they're
expected to save state before that because most of the time it's not
the user closing them, it is the OOM killer. While I think that it is
great apps periodically save, I would not consider them implementing
the lifecycle as they are today. I think that it would be easy for them
to migrate to do so (literally adding a single observer to that same
code path) until they do they aren't supporting it and risk losing user
data.
So, I agree with Gustavo that calling it Unity8 today makes sense, and
we can put other U8 interfaces in there to have potentially fewer
interfaces going forward.
Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160531/fdb7de02/attachment.html>