ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #04863
Re: Thoughts on inhibiting app suspend via application lifecycle
>
> >Having only a set of default services would be very limiting.
> >Even if a "music background service" could take streams to support
> metronome-like apps, how about Spotify or Grooveshark?
> >They both have a lot of security built in and you can't just take a
> stream and start playing, you have to talk with their servers,
> >make sure you download the streams in correct speed (too fast and they
> will think your downloading their music, too slow and
> >the listener will be sad) and have a lot of stuff setup just for them to
> trust you.
>
>Download service?
No, a music service with special support for Spotify, and Grooveshark, and
Muzu and whatever music streaming service that are
out there that uses a special protocol that uses a lot of shatter to make
sure you are using the data to play music and not download
it.
>>And what about smart alarm clocks that’s monitors your sleep cycle?
>Microphone service?
I thought of those which monitors your phones accelerometer and finds out
how much you moves and using a special algorithm they
can calculate your sleep cycle and they finds out when they should wake you
up to make you "most awake".
Sure you could create a standard service that does that, but do you really
think it's possible to create a service for every possible
application you can think of?
I don't have much experience with C++ but if I wrote my app in Java the
dream scenario for built in IPC would be something like:
An interface for receiving events and an abstract class (that extends
Thread and implements this interface) for my background
process to extend which could give something like:
class BackgroundTask extends BackgroundProcess {
protected override onMessage(string message) {
if (message.equals("Start working") {
send("Work done!");
}
}
}
class Main implements IPCListener {
BackgroundTask b;
public static void main (String[] args) {
b = new BackgroundTask();
b.start();
b.send("Start working");
}
protected override onMessage(string message) {
if (message.equals("Work done!") {
b.kill();
}
}
}
Now it's up to the BackgroundProcess class to handle all IPC and make sure
that onMessage gets called on correct thread. The
only thing the developer needs to take care of is that everything sent to
the background (or foreground) need to be serializable.
By default everything should be thread safe and beautifully simple to use.
By default BackgroundTask now continues to run even if the user leaves the
app. If BackgroundTask also needs to stop the device
from sleeping it should call some system class or something.
Now, again. I'm not very familiar to C++ but I guess that somewhat the same
approach should be doable.
Now work could be focused on how to make sure a background process don't
consume all battery. Some ideas:
* Ask the user if the app should be allowed to stop the device from
sleeping, or at least make it possible to prevent apps from using
"wake locks" by a setting in system settings.
* Run with lower priority (well this is more a user experience thing rather
than a battery thing)
* Cap the CPU and memory usage.
* Make the user aware that something is running, for example all apps that
have a background process running should show up in
"" and if the user closes the app (using long click and cross) then the
background process would be killed too.
* Limit the number of simultaneous background processes (if I remember
correctly iPhone limits them to four).
2013/10/25 Rick Spencer <rick.spencer@xxxxxxxxxxxxx>
>
>
>
> On Thu, Oct 24, 2013 at 6:28 PM, Rasmus Eneman <Rasmus@xxxxxxxxx> wrote:
>
>> Having only a set of default services would be very limiting.
>> Even if a "music background service" could take streams to support
>> metronome-like apps, how about Spotify or Grooveshark?
>> They both have a lot of security built in and you can't just take a
>> stream and start playing, you have to talk with their servers,
>> make sure you download the streams in correct speed (too fast and they
>> will think your downloading their music, too slow and
>> the listener will be sad) and have a lot of stuff setup just for them to
>> trust you.
>>
> Download service?
>
>
>>
>> And what about smart alarm clocks that’s monitors your sleep cycle?
>>
> Microphone service?
>
>
>> Or my banks app that shows the amount of money on my account when I shake
>> my phone?
>>
> Not certain why this would ever happen in the background, but there should
> be a sensor service, right?
>
> I understand what you are saying, but I still don't think we should give
> up so easily. Constraints are good, and lead to a lot of creativity and
> good design. I think we should stay confident in our initial design and not
> stray from the path until we are very certain that it won't work.
>
> Cheers, Rick
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help : https://help.launchpad.net/ListHelp
>
>
--
Rasmus Eneman
Follow ups
References
-
Thoughts on inhibiting app suspend via application lifecycle
From: Jamie Strandboge, 2013-10-21
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: John Lea, 2013-10-22
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Thomas Voß, 2013-10-22
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Jamie Strandboge, 2013-10-22
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Rasmus Eneman, 2013-10-22
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Thomas Voß, 2013-10-23
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Andy Doan, 2013-10-23
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Michał Sawicz, 2013-10-23
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Jo-Erlend Schinstad, 2013-10-23
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Rick Spencer, 2013-10-24
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Jamie Strandboge, 2013-10-24
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Rick Spencer, 2013-10-24
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Rasmus Eneman, 2013-10-24
-
Re: Thoughts on inhibiting app suspend via application lifecycle
From: Rick Spencer, 2013-10-24