There are two types of mobile widgets:
- user-specific widgets (that are linked to a current user)
- common widgets (not linked to any user).
I.e. user-specific widget mobile-header contains information about important events for a user widget is linked to. On other hand common widget mobile-header-small only contains a panel with OK logo and no any user-specific content.
User-specific widgets are acquired via REST methods signed by user session key.
Common widgets are acquired with requests signed by application secret key.
Mobile widgets MUST be used according to the following rules: * User-specific widgets should be placed in any application at the top of it’s page. * Our policy allows caching of user-specific widgets for a period no longer than 5 minutes. * With each application launch from odnoklassniki.ru all cached data about user-specific widget must be * If during API request to acquire user-specific widget an error has occurred or API did not respond at all, your application must use common widget instead of user-specific one. This is the only case when user-specific widget can be replaced by common widget of the same use. * Our policy allows caching of common widgets for a period no longer than 24 hours.
This table contains all widgets that are available via OK API. To get a widget methods widget.getWidgetContent and widget.getWidgets can be used.
|(header_widget) that is specified in GET parameters of an application URL||In some cases Odnoklassniki itself can specify widget for a game to display via GET parameter header_widget. If this parameter is specified this widget myst be displayed in a game|
|mobile-header-small||Visually this widget looks like a return button and must be placed at top of every application’s page.|
It supports multiple styles and sized that are listed in an example
|mobile-header||Deprecated widget. Does not support custom styles or sizes.|
This widget contains a title “Odnoklassniki” and must be placed at the very top of every application’s page. It is a user-specific widget and must be acquired via API with user session (requests must be signed with user’s session key)