GSoC Report 2: Foursquare in GNOME

I know, I know, you just can not wait to read another wonderful post from this blog (sorry, bad joke). Either way, here I am, with another GSoC 2014 progress report.

If you have read my previous post, you'll remember that the next step for this project is to start working with the Foursquare API to implement its backend in GNOME Online Accounts and then, code some examples to perform check-ins in Foursquare.

What was done?

New Foursquare backend in GNOME Online Accounts

As you can see, we have now the Foursquare backend working in GNOME Online Accounts. Fortunately and unexpectedly for me (since I am a ignorant in GObject in C and even more in Autotools), was relatively easy, through existent backend codebase like Facebook and Pocket backends.

This progress is in review process at GNOME Bugzilla and I hope this should be part of GNOME in a matter of days. You can check the ticket #729847 to get more information.

Foursquare Check-In examples

A lot of progress has been made in the check-in code examples, now the code is more service-agnostic and the service-specific code is well separated. During the development of these examples, I've been able to get a more suitable code to be used directly in GNOME Maps

As I hope you remember, this code is available here

Check-In GUI Discussion

Mattias Bengtsson, Andreas Nilsson and I were discussing at IRC about the future GUI in GNOME Maps, we benefit a lot from this discussion since there were certain aspects of social services that should be taken into account during the design.

Broadly, the Check-In will work as follows:

1. User selects a Point Of Interest (POI) or maybe his/her current location in the Map.
2. A popover shows with information about POI, a "Check-In" button is showed in that popover
3. User press the button
4. An account selector dialog is showed so the user can select the account under which to perform the check-in. If the user has only one account, this dialog is ommited.
5. Based on the POI information, Maps search a related place page in the social service (Facebook or Foursquare) so we can perform the check-in in that place.
6. If the social service return to us results with ambiguity (i.e. the POI has more than one related page in Facebook), a place selector dialog is showed so the user can select the correct place. If there is not ambiguity, that dialog is ommited
7. A dialog is showed to inform the user where he/she is going to perform the check-in and with which account, and also a text entry to associate a message to the check-in. We don't have discussed this yet, but maybe we can add some check-in privacy configuration or other extra options.

Hacking libgfbgraph

During the development of the example code, I've detected some issues in the libgfbgraph library (the glib based library to use Facebook API) related to the OAuth2 Access Token handling. Basically, the library does not use the Access Token provided by GOA, so the applications are forced to reload the Access Token at startup regardless of whether or not the token is expired.

I've discussed this with the library author, Álvaro Peña and we agreed that this must be changed.

What's next?

The next step is to start to code the Check-In GUI that will be used in Maps, so I hope to show you some screenshots for the next report :) .

Stay tuned!

GSoC Report 1: Checking-in at Facebook with Gjs

Ladies and gentlemen, this is my first GSoC progress report, I hope you enjoy it. As you should remember, my GSoC project aims to integrate GNOME Maps with Facebook and Foursquare. Technically speaking, the project consists in the following modification in GNOME.

• Add a new Feature called Check-In to GNOME Online Accounts (GOA) (in the vocabulary of GOA, a feature is something like Chat, Photos, Printers, Files, etc.)
• Add the Check-In feature to the Facebook backend.
• Implements the Foursquare backend with the Check-In feature.
• Implements some sort of libraries that holds the API calls logic (there is actually one for Facebook called libgfbraph). Actually, maybe this is not going to be part of the GSoC project for the moment and the logic would be implemented in GNOME Maps source code, but in the future, this should be changed!
• Add the Check-In related features to GNOME Maps

During the last weeks, I deeply entered to the GOA and Gjs world, my goals for that period was to implement the two first items mentioned above (that is, finish the Facebook backend modifications) and then implements some example scripts that performs Check-In using the Online Accounts configured in the system, plus, some code to be reused GNOME Maps should start to be crafted at this point.

What was done?

Facebook backend modification

The first thing that I did was to implements the modifications to the Facebook GOA backend. Since this backend is already implemented, this task was relatively easy but it helped me a lot to better understand technologies like D-Bus and GObject C programming.

The result? roughly, this fully functional switch (inside the red rectangle) :P

You can check this progress at my GOA development repository, wip-checkin branch

Two example scripts

There are also two example scripts that shows how to perform a Check-In, those scripts only use the Facebook backend since as of today the Foursquare backend is not implemented. One of the scripts, called listFacebookPlaces.js just lists Facebook Places Pages information from geo coordinates and distance parameters, this is necessary since Facebook needs a Place Page ID to associate a user post to a location. The other script, called performCheckIn.js performs a Check-In in Facebook using the message and place passed by parameter.

Both examples uses common code (basically checkIn.js) that will be candidate to be part of GNOME Maps codebase

You can check those and future examples in this repository

What's next?

I think that the next step is to enter to the Foursquare world and its API. The first thing to do is to implement the Foursquare backend in GOA and then, write the examples, as I did with Facebook. This also will help us to understand the particularities of each service so we can design a better GUI to the users of those services. For example, when a was working with the Facebook examples, I had no idea beforehand that I was going to need a list of Facebook Places to get a Place ID, this give us a clue of the existance of a Combo Box or something like that in the future GUI design to allow user to select the place to Check-In, something that would not have imagined beforehand. I expect that something similar will happen with Foursquare.

Stay tuned for more reports!