This came out longer than initially planned... I blame the
jalapeño-flavoured beer!
W dniu 30.08.2014 o 22:00, Sam Bull pisze:
On mer, 2014-08-20 at 09:06 +0100, Matthew Paul Thomas wrote:
Having account setup in Online Accounts, instead of inside an app,
makes the app harder to use. People have to learn and understand that
there's a separate place on the system listing a separate "online
account" that an app may or may not have permission to access.
What I'd like, is to be able to simply add an ownCloud account to sync
contacts and calendars, much like the Google account already does. I've
no interest in installing a dedicated ownCloud app.
Note this has been available in GOA for atleast a couple of years now.
Here, too, I'm afraid this goes into the "why isn't
$my_favourite_service included by default" problem. Adding it to the
default set would mean we need to commit to maintaining it in there,
supporting it etc. Doing this for all of the services available out
there is not something we'll be able to do. And then it becomes locked
down to framework versions. Your app depending on a certain framework
version (of which the account plugin would have to be part of) could not
progress as quickly as it could if you had control of it all.
I'd have no problem installing "ownCloud sync support" from the store to
get it. As for whether it's integrated with the accounts system or not,
the engineer in me obviously votes for that. But not all people are
engineers and I agree with that, if there's only one app that would ever
use the ownCloud account, having to go through the accounts system has
some experience disadvantages. And then there are technical advantages
to having it *in* the accounts system.
The accounts UI became a trusted prompt recently so the process of
configuring an account is much smoother now, so I'm not sure that the
user experience of having to go through it is so much worse these days
than having it built into the app.
So it's worthwhile only if it saves a lot of time -- only if multiple
apps use the same kind of account.
I'd also like to add notes syncing to the notes app using ownCloud. I've
already done this in my gnome-shell extension, by retrieving the
credentials from GOA.
I'd like to do the same on the phone, the code is Javascript, so I
should be able to reuse it mostly unchanged.
I think we need a more generic system here, the notes app shouldn't have
to know what ownCloud (or any other service, for that matter) is. It
just needs to be a source for a destination (I'm thinking content hub,
of course, I'm sure we can engineer something that will make sense and
be agnostic to what kind of data is being sent through it, from and to
where).
It occurs to me now that even contact/calendar syncing should maybe
become part of the content hub experience, these days it's all just file
exchange anyway.
=====
Now, we've had a chat recently about what to do with multiple apps
wanting to use the same account, one that isn't part of the default set
of supported services. The simplest approach, albeit not too user
friendly, is just saying in your app's description that it's a
requirement to install a separate support package. It's not an unheard
of approach. The app, if realized that the account type is not
available, could even link to the store to point directly at the
required package.
Another approach I was thinking of is allowing multiple plugins of the
same account type exist (so every app would ship their own copy) and
deduplicating based on type and compatibility version. This has some
technical difficulties like allowing multiple packages of potentially
different compatibility versions to co-exist (you'd have two accounts of
the same type in that case, again not a great user experience, but
should be rare). We'd also need a place to share the account plugins, or
at least their interfaces so that different implementations can talk the
same language. This could potentially have security implications if not
done right. The more I think of this way the more it feels like
overengineering for a quite rare a problem.
HTH,
--
Michał (Saviq) Sawicz <michal.saw...@canonical.com>
Canonical Services Ltd.
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
