ubuntu-phone team mailing list archive

[Rodney Dawes <rodney.dawes@xxxxxxxxxxxxx>]

On Thu, 2014-06-26 at 16:09 +0200, Thomas Voß wrote:
> I assumed that you know:
> 
> https://docs.google.com/a/canonical.com/document/d/1ij8RtPsR_eYMW3mys8Gu1Y2CVFZpjXdMpdIjIGZ1SCA/edit#heading=h.28drra4u9knx
> 
> given that the document has been around for quite some time now, and
> has been referenced multiple times in other mail threads on this list.
> It might not contain all of the details you are after, but it gives a
> very good overview of the design that we implemented. There are also
> multiple UOS sessions available from youtube. Anyway: I'm happy to
> iterate on the document and adjust it if concrete points are missing.

No, I didn't know about this doc. However, it doesn't actually describe
anything about what system services will exist or how they will
function. The only information about background tasks in that doc is a
very short list of a few very specific use cases that might need
background processing.

> See my comment before. Also: We already put a bunch of background
> services in place, an updated version of the location service is about
> to land. Push notifications are well on their way, too. With that, and
> given the numerous updates by individual teams being reported to the
> mailing list, I wonder what else would help in terms of documentation?
> I agree that it would be great to have complete SDK and API docs
> available and any help is appreciated to reach that point. And feel
> free to reach out to me on irc.

Where are these services and how apps are expected to use them,
documented? I don't need complete SDK/API docs at this point, but a
general overview of how we expect this to look and function on a
technical level would be nice to see.

> Sorry, but I think you are ignoring the arguments that multiple people
> have presented in this mail thread. We have pointed out that we are
> well aware that we are taking a somewhat conservative and strict
> choice to ensure predictable battery life and performance. None of the
> alternative approaches presented in this thread qualify for
> predictable battery life and performance, they all focus on solving
> the perceived issue of a lack of flexibility for application
> developers.

I am not ignoring any arguments. But "predictable battery life" is not
an argument. Battery life is  unpredictable. There are way too many
variables to predict battery life. Battery life can only be predicted in
a controlled environment. Long running tests of minimal usage and very
heavy usage, combined to find the average, will give you an average
expected battery life on a particular piece of hardware, which is used
for marketing and declared an estimate in those materials. Beyond that,
you will have no idea what sort of battery life I will get on my phone.
There are way too many variables for you to make any reasonable guess.
Where I live on the planet, how many calls I make, how I travel, how I
carry my phone, what accessories I connect to my phone, what apps I use,
how often I use them, etc… all have an impact on what the battery life
of my phone will be. Yes, if I have 30 apps running in the background
all actively doing things, it's going to be bad. But it's also going to
be bad if I spend 4 hours straight actively playing one game. Arguing
about battery life isn't something that will provide a solution to any
actual problem.