Replace fields _ID_OWNER and _ID_SERVICE i Sharing. Urgent!!! TBD before Monday 11. March

UbiCollab / UbiCollabSDK

One jar file to rule them all.

1 stars 0 forks source link

Replace fields _ID_OWNER and _ID_SERVICE i Sharing. Urgent!!! TBD before Monday 11. March #26

Open JacquelineFloch opened 11 years ago

JacquelineFloch commented 11 years ago

Following our discussions, the two fields _ID_OWNER and _ID_SERVICE should be replaced by GLOBAL_ID_OWNER and GLOBAL_ID_SERVICE

Since thomas is leaving next week, this should be done before our integration meeting on Monday 11. March

BabakFarshchian commented 11 years ago

These fields already exist and are deprecated. Can I ask one of you to write down the reason we want to go back to the old solution? GLOBAL_ID_OWNER should in theory be found in the People table if you search for a row where _ID=_ID_OWNER. The same applies for _ID_SERVICE. If this is a quick fix for the demo we can still use the deprecated fields.

JacquelineFloch commented 11 years ago

I have already explained it! :-(

The sharing information in a community is shared between members of the communities. This means that the owner and service identifiers should be understood by all members. If you use local ids for those filed, the sync adapter has to transform the fields to global ids during synchronisation. Kato told he does no so. He simply adds a file in the community with the shared contents. Anyway, it makes sense to use global ids. Both People and Services are global tables, so global ids should always exist for entities in these.

The issue is similar to the filed ACTOR and TARGET in activities. When referring to entities, global ids should be used such that the activity can be understood by all members. The sync adapter to box.com does not transform these fields during sync.

BabakFarshchian commented 11 years ago

This is a bug in the content provider. Content provider should translate from local _IDs to remote GLOBAL_IDs and back. Apps on the device should not use GLOBAL_IDs if not for displaying it to the user for inspection. The whole content provider functions locally based on local _IDs that are integers. I will talk to @KatoStoelen today and see how we can solve it. It seems to me this has a quick fix (doing a look-up in the Service table and replacing the _ID with GLOBAL_ID).

In the meanwhile, is it possible to use the deprecated fields for this purpose so your demo can move on?

JacquelineFloch commented 11 years ago

Fo me using _ID or GLOBAL_ID it is exactly the same in that case. But I am tired of updating code. The demo works locally in any case. SO now I expect sync of sharing to be in place ASAP.

Note that I have two cases where GLOBAL_ID should be used by applications:

Activities as already explained, e.g. ACTOR and TARGET. The sync adapter ís not aware of the semantics of these fields and cannot transform them during sync. I we wish to do we have to add additional fields indicating the type for values set in those fields (e.g. community, people,...)
Checking whether a service is installed or not on a device. The GLOBAL_ID of service is used for that purpose. We cannot assume that all Apps are downloaded from GooglePlay.

BabakFarshchian commented 11 years ago

According to @KatoStoelen local _IDs are translated to GLOBAL_IDs when synching sharing. Kato is going to look into this as it seems to be a bug.

The issue of _ID and GLOBAL_ID and how to use them is now described in more details in the wiki for UbiShare and the javadoc for GLOBAL_ID. You can use GLOBAL_IDs for setting ACTOR and TARGET if you want.