With the Q4 2011 deployment the StreamWork Method API was deprecated. Since then no new methods are accepted that use the Method API. New methods have to make use of the OpenSocial API.
If you already have implemented a StreamWork method using the Method API you need to consider adjusting you implementation to use the OpenSocial API as the Method API will be turned off at some point in the future.
There are some things of which you should be aware when porting your method to the Open Social API. There are some areas were OpenSocial makes your life easier, there are some area where OpenSocial is just different and there are very few things which are no longer possible with OpenSocial.
Simplifications/Improvements
- In case the Method makes use of PBE this is done differently with OpenSocial. It is no longer necessary to define individual update handlers. OpenSocial gagdets have to make use of the streamwork.pbe feature.
- OpenSocial provides you with more flexibility when storing data within StreamWork. It is up to the developer to decide about the data structures (JSON objects, arrays,…)
Required Adjustments
- Bundle XML has to hosted on a server which is accessible for StreamWork. With the Method API you had to upload the bundle XML from you hard disc
- When using the Method API your Method is attached to a <DIV> of the StreamWork page. The OpenSocial API runs gadgets in an <IFRAME>. As a result
- With OpenSocial the gadget is declared via the Bundle XML instead of using streamwork.module(). As a result it is up to the OpenSocial gadget to listen for specific events like when all the resources are fully loaded. This can be done by using gadgets.util.registerOnLoadHandler().
- Accessing remote content changes slightly from the Method API to the OpenSocial API. When using the Method API remote content was accessed using streamwork.io.makeRequest. In OpenSocial this call is called gadgets.io.makeRequest
- gadgets.io.makeRequest supports more authentication capabilities including OAuth and signed request
- Some resources like JavaScript and CSS are cached to increase speed. While the gadget is in development this caching is disabled. However,Shindig still caches the resources and serves them to the browser. The cache is refreshed with every call, so that caching is disabled. The consequence of this mechanism is that resources have to be publically available even trough development as caching will not work otherwise.
- Raising custom events is done differently for OpenSocial gadgets. You need to make use of osapi.activities.create() to raise customer events.
No longer possible
- The reference manager is no longer available
- It is no longer possible to read the unique item ID via the OpenSocial API. However, there is an OpenSocial gadget instance ID as part of the item URL.
This list might not be complete. In case you are missing something in here please let me know and I will update my blog.
