QML Friends API and UI Components

Registered by Ken VanDine on 2013-05-08

Discuss how the Friends API can be improved and the possibility of UI Components that developers would find useful.

Blueprint information

Status:
Not started
Approver:
Alan Pope 🍺🐧🐱 🦄
Priority:
Undefined
Drafter:
Ken VanDine
Direction:
Needs approval
Assignee:
Ken VanDine
Definition:
New
Series goal:
Proposed for saucy
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Friends development began as a simple attempt to port Gwibber from python 2 to python 3. In the process, so many components were so heavily refactored that it took on a life of it's own as a new project, hence the new name. Unfortunately, very little consideration was given to API consumers; the effort focused almost entirely on making gwibber testable and maintainable, while inheriting it's API largely unchanged.

Now we need community feedback in order to shape Friends' API into something that is more directly usable by consumers, and we can thus shape the future of Friends development based on the needs of the public, rather than the needs of Gwibber.

Notes from the session:

= Ideas =

General:
 * friendly roleNames (message, sender, etc instead of column_#)
 * new components:
   * Poster
     * character limit should be service specific
   * service specific delegates for use in a ListView
   * Share
     * Photo upload, etc

Facebook:
 * support for pages
 * albums
 * profile pages
 * better wall support
   * write on a wall
   * destinguish wall posts in the stream

Call for feedback, include examples:
 * Code examples for Poster and StreamModel

Feedback from hmiguellima:

Better error handling: There are errors happening in the firends backend, for example sometimes when I try liking a post a fatal error happens on the backend, it doesn't crash the app, but there's also no feedback of the error.

UI components: General UI components made available through Friends would be good, having an integrated look and feel between apps, although I think in Facebook case there might be a need for more Facebook branded look, that would'nt look good in other apps.

For example the Facebook mobile apps tend to have the posted images take a lot of the screen real estate, overflowing the message panel, or the Faceook 's like/comment brand specific icons in the comments panel.

A poster component would be simple enough to integrate though...

A question related to UI is the image quality, I replaced the column_14 (posted image) URL with a '_b.jpg' sufix, to get a higher res picture, but don't know if it was the best thing to do.

Stream model:

More explicit schema attribute names are great, so looking forward to it.

Also I've still not found were to get more about info about the Friends schema, I want to try and take a look in the Friends repo but haven't had the time, for the time my source of info has been Gwibber's code.

For example how can I filter the streammodel to only show messages from a specific user ?

Or how to get a stream of direct messages ?

Are Facebook photos posted in the wall integrated with the messages stream? I'm referring to photos added to albums, Facebook shows them in the news feed.

Events: This will be a great addition to the friends API.

List of friends: How to get a list of friends for a specific account ?

Photos and albums: This is another must have feature !

Other needs: I currently call the graph API to get the post reply messages count, It's working but It would be nice to have that in friends.

(?)

Work Items

Work items:
[ken-vandine] QML Friends model component for Notification model: TODO
[robru] friends backend for notifications based on errors and notifications from the providers: TODO
[ken-vandine] Add UI to friends-app for notifications: TODO
[ken-vandine] call for feedback from developers: TODO
[ken-vandine] join weekly facebook app weekly meeting: TODO
[dpm] Send invite to Ken to join the weekly Facebook meeting: TODO
[robru] add location tagging to posts: TODO
[ken-vandine] bindings for location tagging: TODO

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.