Can I use USER RELATIONSHIPS instead of FRIENDLIST??

You certainly can. I did not have the time to create an adapter module between heartbeat and user relations but you could easily do so yourself.
Check friends_activity submodule and do the same implementation of hook_heartbeat_related_uids_info ... , this way the relational heartbeat will know about the friends. This is in fact the only heartbeat core stream that encounteres "friends of a user".

I have a lot of work lately but i will try to create that submodule as well, or gather it together in a friends_activity module (with setting which kinds of module is describing the friends relations , friendlist, buddylist, user relations or flag_friend ...

regards,

Stalski

Take the dev version for the moment untill next release, some critical bugs with js polling has been reported and is fixed in nightly release (dev version)

Check the patch. This allows to configure which api to use (implemented for friendlist_api and user_relationships_api). This can be configured at Configure Heartbeat relational activity form.
I hope this is helpful and the approach was correct.

Regards

The approach is good. I will run it and review it.
Thx sarhugo!

subscribe

Sarhugo, i ran the patch and it was ok. Than it got me thinking after seeing the old code from it.

Let's take "heartbeat_add_friends_to_personal" setting. Intentionally, this would make the query for personal heartbeat, take the user releations with him. This does not make sense as heartbeat exists now. The stream (access type) is the query builder and things are done there. So, this is the situation: a stream is created and the query is done for heartbeat_relations. This means that the only thing that needs to be done, is to make sure the user object has the user's relations. Whoever is the source module for this relation.

So I left out the stupid variable "", but left you api selection as it is. So that is the way heartbeat will know which function to run to obtain the $user's heartbeat relations. Besides , ConnectedHeartbeat is only an example of a heartbeat stream.

In the future i will move this stream and the hook invocation to heartbeat submodule friends_activity. This will be more clear i think for what is does.

Hope you guys understand what i am whobbling about.

Let me see if I understand...
You want to leave all query's operations within each stream. That is if you want to add the activity of friends or not, will require two streams, one for each logic. This would eliminate the variable "heartbeat_add_friends_to_personal" (which, btw, I didn't find where is this setting on backend)

Am I right?

The stream objects were already the ones that perform the query. ConnectedHeartbeat is only a example stream like the others.
The only thing that it does , is using the variable heartbeat_relations in the global user object. So:

$sql = "
    AND (
      (ua.uid in( %s )
       AND ua.access >= 0
    )
    OR (
    	ua.uid_target = %d AND ua.nid <> 0
    )
   )";

Here we fetch messages for all actors in the users' relations. If you add a new (custom) stream , then it is the choice of the module builder to use this variable or not. So you can create as many relational activiy streams as you which.
So you will only need one stream in most cases. If you want two, then you can just create a new class and register it to heartbeat access types. You can see the example module for this.

heartbeat_include('ConnectedHeartbeat');

/**
 * Class CustomActivity
 * Concrete class to prepare messages in a custom way
 *
 */
class CustomActivity extends ConnectedHeartbeat {

}

That's it. Registering the class goes like this:

/**
 * Implementation of hook_heartbeat_register_access_types()
 */
function yourmodule_heartbeat_register_access_types() {
  return array(
    0 => array(
      'name' => 'Custom activity',
      'class' => 'CustomActivity',
      'path' => 'customactivity.inc',
      'module' => 'yourmodule'
    ),
  );
}

The variable "heartbeat_add_friends_to_personal" did not make sense anymore. You could see it in the admin heartbeat global settings page.

But i think you understood yes.

duplicate with #705408: User Relationships and is fixed.

- connected heartbeat is only a query that fetches from "my relations" immediately, using a variable in the user object (user->heartbeat_relations). The only thing that the friendlist_activity module does in fact, is calculate the friends of a given uid, where these uids can come from user_relationships or friendlist or some other module.

- Available now as well is the possibility to let users opt in or out of message types in their streams.