Code review comment for lp://staging/~gerboland/unity-api/appManVersion2

> Jup... Again, I'm fine with having them in both. We need to keep
> startApplication() in AppMan which makes it natural to have stopApplication()
> there too, and with it suspend/resume. But I can see how it would be
> convenient to have that as an ApplicationInfo object's property in QML.
>
> So I'd probably go for
> ApplicationManager:
> startApplication()
> stopApplication()
> suspendApplication()
> resumeApplication()

Ok, I can do those

> and ApplicationInfo:
> Q_PROPERTY(suspended)

This one I'm not so sure about. We already use 'state' to get the process state, so adding the "suspended" property duplicates info. I also dislike it as some apps are excluded from lifecycle, so shell setting myApp.suspended=true is just incorrect.

I prefer just using the first part of your proposal - with {suspend,resume}Application() returning bool, so that shell knows if asking an app to suspend was actually acted upon or not.

I don't think shell really needs to know if an app is lifecycle-exempt, but it would care if suspendApplication returns false. Main use-case I can think of is there's no need for shell to save a screenshot to disk for a lifecycle-exempt app's surface, as there's no way that app will be killed.

> stop()
I might leave this out for the time being, just for ease of implementation, if you don't mind.

Also maybe just putting the process control methods (start/stop/suspend/resume) in AppManager is enough for a start.