ubuntu-phone team mailing list archive

[Rasmus Eneman <Rasmus@xxxxxxxxx>]

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.

And what about smart alarm clocks that’s monitors your sleep cycle?
Or my banks app that shows the amount of money on my account when I shake
my phone?

A set of good behaving default services would be very good, but it's far
from enough and when trying to squeeze to much functionality
in the same service just to try to cope with everything you would back fire
your saving battery plan by having non optimal implementations.

It's much better to try to help the developer instead of limiting him.

Provide good default services than can be used when possible
and provide good help in creating well behaving daemons when needed.
Create an event based message handler for communicating between the
frontend and the deamon, probably could use already available
functionality in QT however I haven’t used it enough to tell.
Make it possible to subscribe to events from the system (incoming
call/message, precise time, rough time, location).
Create something like Google Cloud Messaging for developers to push
notifications to devices.

Everything that can ease in creating good behaving apps for the developers.
If you instead limits them to a set of fixed services,
those will be misused to do stuff in non optimal ways. Just look at X at
these days.


2013/10/24 Rick Spencer <rick.spencer@xxxxxxxxxxxxx>

>
>
>
> On Thu, Oct 24, 2013 at 3:27 PM, Jamie Strandboge <jamie@xxxxxxxxxxxxx>wrote:
>
>> On 10/24/2013 02:00 PM, Rick Spencer wrote:
>> > It's been interesting to read all the expected use cases, and also the
>> > requirements for application developers. It's good to think hard about
>> how we
>> > fulfill these requirements, and do it well.
>> >
>> > What I liked about Thomas's first iteration of the application life
>> cycle, is
>> > that it is clean, simple, comprehensible, and works. To me, it seems
>> that as an
>> > app developer you get:
>> > 1. the ability to do what you want when your app is in front and the
>> phone is
>> > not idle.
>> > 2. a set of services via well known APIs to call for things where your
>> app may
>> > not be in front (i.e. music service, download service, alarm service
>> etc...)
>> >
>> > I think that instead of thinking of ways to grant applications long
>> running
>> > processes, we should grow these services. For example, it sounds like a
>> location
>> > service may be required, etc...
>> >
>>
>> I think that is where we landed:
>> https://lists.launchpad.net/ubuntu-phone/msg04766.html
>>
>> Ie, we build out our services but application developers also have a way
>> to
>> implement their own background service if they need to.
>>
> So I am saying the opposite. Rather than allowing apps to create
> background services I think we should stick to the original vision. Apps
> use well known APIs for their functionality, or the the user keeps the app
> in front and alive on the phone. I think there should be no "background
> processes" other than what is available on the base system. This system we
> have started down is clean, simple, and very hard to subvert. The hard part
> is providing the correct set of APIs so that app developers do not wish
> they could write such services.
>
> I think that if we go down the path of allowing folks to write background
> services, then we may as well just allow the app to run in the background.
>
> For completeness, I would expect a different policy to be in force when
> running on a desktop. I could imagine that in desktop mode the policy
> allows applications to run in the background. However,that is a discussion
> for later ;)
>
> 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