ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Fri, Oct 2, 2015 at 11:03 PM, John Johansen
<john.johansen@xxxxxxxxxxxxx> wrote:
> On 10/02/2015 08:32 AM, Thomas Voß wrote:
>> On Fri, Oct 2, 2015 at 5:04 PM, sturmflut <sturmflut@xxxxxxxxxxxxxx> wrote:
>>> Hey Thomas,
>>>
>>> On 02.10.2015 16:44, Thomas Voß wrote:
>>>
>>>> Let's make sure that we are untangling the lifecycle policy discussion
>>>> we are having here from the
>>>> discussion of enabling apps to prevent the device from going to deep
>>>> sleep. The latter one can be solved and
>>>> both you and me have been talking about the solution. With that,
>>>> keeping the tracking app in the foreground is perfectly fine.
>>>>
>>>> Screen goes off, devices stays operational, problem solved :)
>>>
> Nope. That forces the user to keep the tracking app in the foreground.
> That means the user can not go about using their phone in the regular
> way if they want the tracking app to function.
>

Fair point, I oversimplified the solution.

> Receive an sms, or email. Switch to reply, now you are forced to
> return to the tracking app. Instead of just continuing on your way
> especially if you are expecting another response soon.
>
> Out walking, and take or make a call while continuing to walk, to
> bad your tracking app doesn't support that. Forcing the user to
> deal with this is not user friendly especially when the competition
> does not have such restrictions.
>
>>>
>>> Wait.
>>>
>>> So we would then have three cases?
>>>
>>
>> Sure, this topic is orthogonal to the lifecycle discussion, though.
>>
> Not really, it is a design decision that forces a certain tying of the
> two, as your response clearly shows. The lifecycle affects what and
> how an application can do some things. It forces certain design choices
> and atm even forces certain user behaviors. The most common use cases
> can eventually be covered by background services but it will never
> cover all use cases.
>

Let me clarify: I think it *should* be orthogonal, keeping an app in
foreground and forcing the screen on
is obviously not the ideal solution to the use-cases we have in mind,
specifically as we mix up both problem domains.

Cheers,

  Thomas