Friend Presence Library

Contents

Overview

Overview

Introduction

With the Wii U, every account has a friend list, a blacklist, and a request list (a list of friend requests sent to the local user) that can be shared for use by all applications. There is also a Wii U system feature called the Friend List Viewer that can manage these lists.
This library provides features that allow applications to get and update information such as these lists, and the current online status of friends (the friend presence) from the application.

To use the Friend List Viewer, install Wii U Menu Changer.
You can also manage these lists and update settings using the Friend Manager tool included in the SDK.

Accounts

Because user accounts have been introduced with the Wii U, use the Nintendo Network ID for identification instead of using a friend code as with the Wii and 3DS platforms.
For this reason, you need a network account to use the features of this library.

For more information about the Wii U accounts, see Wii U Account System Developer's Guide.

What Applications Can Do

Applications can use this library to perform the following tasks.

▲ Top

Data Linked to Accounts

With some exceptions, the data linked to accounts is managed on the friend server.

The data managed on the friend server can only be retrieved while connected to the friend server.

Data Managed on the Friend Server

Data Accessible by Friends

Data Description
Account ID The Nintendo Network ID that the user specified when the network account was created.
Principal ID The unique ID that was assigned by the account server when the network account was created.
This ID is linked on a one-to-one basis with the account ID, but because account IDs can change, this library uses principal IDs to distinguish users.
Mii Characters The Mii character that the user specified when the network account was created.
When a Mii character is changed, it is updated when the user connects to the friend server.
Profile The country and region of residence that the user specified when the network account was created.
When a profile is changed, it is updated when the user connects to the friend server.
Status Message A message of up to 16 characters specified using the Friend List Viewer.
It cannot be retrieved or updated by applications.
Friend Presence See Friend Presence.
An application can get only the Friend Presence of the local user that was set by the application, even though the user is offline.

Data That Only the Local User Can Access

Data Description
Settings Information
Setting Initial Value Description
Privacy setting for online status non-public Sets whether to publicize the online status.
If set to private, even friends do not know when the local user is online.
Friend presence information is not sent to other users either.
Privacy setting for currently playing software non-public Sets whether to publicize to friends what software the user is currently playing.
If set to private, friend presence information is not sent to others users.
Setting to deny friend requests Under age 13: Deny
Ages 13 and over: Do not deny
Sets whether to deny friend requests that are received.
If set to deny, friend requests are not delivered.
If the local user is under the age of 13, he or she cannot change this setting.

Applications cannot update this setting.
To update this setting, use the Friend List Viewer.
Blacklist This is a list for managing players with whom the user does not want to communicate.
For more information, see Blacklist.
Request List This is a list of friend requests that have been sent to the local user.
For more information, see Request List.
For the friend request blocking setting only, the setting of all users can be accessed, not just those of the local user and friends.

Synchronization With the Friend Server

This data is updated with the newest information by using push notifications from the friend server.
The communications process for this purpose is performed by the friend presence daemon (the FPD) running in the background.

Applications can also receive this push notification and update data in real time.
For more information, see Notifications.

Data Managed on the Console

Data Description
Player History A record of users played with over the network.
For more information, see Player History.

▲ Top

Friend Presence

Friend Presence is a feature that enables users to check the gameplay status of their friends.
Use this feature to learn which games friends are playing, and to check information such as the game mode description strings that describe what friends are doing inside games, console information, and parameters for joining games.

Get and Update Information

Get

Only the following gameplay status of friends can be obtained by applications: their online status, console information, and parameters used to join their game.
Use the Friend List Viewer to check Now Playing and the game mode description string.

Update

Applications can update their own game mode description strings and join-in parameters.

Game Mode Description String

The game mode description string is displayed in the friend Details screen in the Friend List Viewer.
The application can get and update its own game mode description string, but it cannot get the game mode description strings of friends.

In addition, even applications that do not use the join-in feature can update only their own game mode description string.

The Friend List Viewer can display a width of 32 double-byte characters, and a height of two lines.
Use "\n" to indicate a newline.

Console Information

The console information includes the following data.

Data Description
Region Code The region code of the console.
Language Code The language code of the console.
Platform Code The code for identifying the platform.
Currently, the Wii U is the only supported platform.
This information is added by the library when the presence is updated.
Applications cannot set this information.

Join-In Parameter

For more information, see Join-In.

Frequency of Access

Friend Presence is implemented through the friend server.
To reduce the load on the server, the library restricts updates to once every ten seconds.
If Friend Presence is updated more quickly than this library restriction, only the last update is valid.

See the guidelines for limitations other than library limitations.

▲ Top

Join-In

Join-In is a feature for notifying friends that they can join a game that the local user is playing, and for allowing those notified friends to join the game.
Join-In notifications are implemented using Friend Presence.

Example Implementations of the Join-In Process

There are two ways to perform the join-in process.
The following examples show ways to implement the join-in process.

Using the Join-in Feature Inside Applications

  1. Watch for friend presence notifications.
  2. After a friends presence notification arrives, determine whether join-in is possible.
  3. If join-in is possible, inform the user that there is a friend available for join-in and prompt the user to select whether to join.
  4. If the user selects to join, begin the join-in process.

Joining a Game Using the Friend List Viewer Join-In Feature

  1. In Friend List Viewer, click the Join currently playing game button.
  2. Immediately after the application starts, check whether it was started from Join currently playing game and if so, start the join-in process.

Determining Joinability

Joinability is determined based on the friend's join-in parameter and the setting configured by the local user for the join-in game mode mask.
The actual determination process is easy because it involves simply passing this data to the API provided by this library.

Join-In Parameter

Flags That Determine Joinability

There are three kinds of flags for determining the possibility of joining in.

Flag Description
nn::fp::JOIN_AVAILABILITY_NOT_JOINABLE Use this flag if join-in is not supported, or when reverting from the joinable to not-joinable state.
nn::fp::JOIN_AVAILABILITY_JOINABLE Use this flag if joining from the Friend List Viewer.
If this flag is used, determine joinability immediately after starting the application.

If this flag is set, it does not mean that the join-in process cannot be performed from inside the application.
nn::fp::JOIN_AVAILABILITY_JOINABLE_APP_ONLY Use this flag when using the join-in feature without supporting join-in from the Friend List Viewer.

Matchmaking System Type

The matchmaking type of the matchmaking group in which the local user is participating.
The following types are available.

Flags Description
nn::fp::MATCHMAKE_SYSTEM_TYPE_ANYBODY Anybody can be accepted to participate.
nn::fp::MATCHMAKE_SYSTEM_TYPE_FRIEND Only friends of the owner of the matchmaking group are accepted to participate.

Join-in Game ID

This ID identifies joinable game titles. The game server ID issued by OMAS is used.

If the game that the local user is playing and the game that a friend is playing have different join-in game IDs, the friend presence of the user is not sent to the friend's application.
Also, the Friend Presence is not delivered to the friend's application if the join-in game ID is 0.

If the same join-in game ID has been assigned to multiple game titles, the Friend Presence is also delivered to different game titles.

This value is set by the Application Configuration Tool and read by the system. The application cannot make dynamic changes to it.If join-in is not supported and Friend Presence is not being used either, set the join-in game ID to 0 by using the Application Configuration Tool.
After you have set the join-in game ID, export the meta.xml file and store it under $CAFE_META_DIR.
If meta.xml already exists, update the file.

Join-In Game Mode

This value identifies joinable game modes. You can specify any value between 0 and 63.
For more information about how to use this value, see Examples of Using Join-in Game Mode Masks later in this document.

Matchmaking Group Owner

Specifies the principal ID of the owner of the local host's matchmaking group.

If the matchmaking system type is Only friends accepted, players cannot join unless the owner is the local user's friend.
Any value can be specified for the matchmaking group owner in other cases, because it is not used to determine whether other players can join.

Join-In Group ID

Specifies the ID of the matchmaking group in which the local user is participating.
Any nonzero value can be specified.

For example, if you are using NEX, specify the gathering ID of the matchmaking session.

Application-Defined Data

This data consists of 20 bytes of data that the application is free to use.

Examples of Join-In Parameter Settings

Friend Matchmaking Using NEX When the Local User is the Matchmaking Group Owner

Parameter Value
Flags That Determine Joinability nn::fp::JOIN_AVAILABILITY_JOINABLE
Matchmaking System Type nn::fp::MATCHMAKE_SYSTEM_TYPE_FRIEND
Join-in Game ID - (Specified using the Application Configuration Tool.)
Join-In Game Mode Arbitrary value
Matchmaking Group Owner Principal ID of the local user.
Join-In Group ID The gathering ID of the created matchmaking group.
Application-Defined Data An optional parameter.

Playing an MMORPG Using an Independent Server When the Local User Is Logged In to the Game Server

Parameter Value
Flags That Determine Joinability nn::fp::JOIN_AVAILABILITY_JOINABLE
Matchmaking System Type nn::fp::MATCHMAKE_SYSTEM_TYPE_ANYBODY
Join-in Game ID - (Specified using the Application Configuration Tool.)
Join-In Game Mode Arbitrary value
Matchmaking Group Owner Arbitrary value (because the matchmaking system type is not FRIEND).
Join-In Group ID The ID of the area currently being played.
Application-Defined Data An optional parameter.

Join-In Game Mode Mask

The join-in game mode mask provides a way to make games joinable or not joinable under certain conditions even when they share the same join-in game ID. A game is joinable if the bitwise AND of the join-in game mode mask and (1<< game mode) is nonzero.

To support the join-in feature of the Friend List Viewer, you must use the Application Configuration Tool to set this value.
The Friend List Viewer loads this value from the game title settings information and uses it to determine whether players can join the game.

Examples of Using Join-in Game Mode Masks

When a title that supports all regions is using a single game server, there may be times when you want to make it impossible to perform matchmaking with players from other regions.
To achieve this, you can assign a different join-in game mode for each region and then configure join-in game mode masks such as the following.

Game Region Join-In Game Mode Join-In Game Mode Mask
Japan 0 0x0000000000000001
North America 1 0x0000000000000002
Europe 2 0x0000000000000004

Local User's Game Region Friends in Japan (Join-in game mode = 0) Friends in North America (Join-in game mode = 1) Friends in Europe (Join-in game mode = 2)
Japan
Join-In Game Mode Mask
=0x0000000000000001
(0x0000000000000001 & (1 << 0)) = 1
Joinable
(0x0000000000000001 & (1 << 1)) = 0
⇒ Not joinable
(0x0000000000000001 & (1 << 2)) = 0
⇒ Not joinable
North America
Join-In Game Mode Mask
=0x0000000000000002
(0x0000000000000002 & (1 << 0)) = 0
⇒ Not joinable
(0x0000000000000002 & (1 << 1)) = 2
Joinable
(0x0000000000000002 & (1 << 0)) = 2
⇒ Not joinable
Europe
Join-In Game Mode Mask
=0x0000000000000004
(0x0000000000000004 & (1 << 0)) = 0
⇒ Not joinable
(0x0000000000000004 & (1 << 0)) = 1
⇒ Not joinable
(0x0000000000000004 & (1 << 2)) = 4
Joinable

▲ Top

Friend List

The friend list can be shared by all Wii U game titles.

Up to 100 users can be registered to the friend list.This includes users who are tentatively registered and users requesting to be friends.

Registering Users to the Friend List

Users can be registered to friend lists in the following ways.

Entering Account IDs

You can use the Friend List Viewer to register users to the friend list by entering their account IDs.
The Friend List Viewer sends friend requests if requests can be sent to that recipient; otherwise, it makes a tentative registration.

If the Friend List Viewer makes a tentative registration, the individual registered is not notified of the registration.

Sending Friend Requests From Player History

You can select users from Player History in the Friend List Viewer and send them friend requests.

Friend requests cannot be sent when the local user is under the age of 13 or the recipient has blocked friend requests.
The friend request also does not reach the other party if the local user has been registered to their blacklist. (However, the sending process itself succeeds.)

Registering a User on the Friend List From an Application

Users can be registered on the friend list from applications.
Applications can offer original user interfaces for temporarily registering friends, and send friend requests.

It may cause confusion if a friend request is sent from one user to another that the user has never played with.
We recommend that you adopt a specification where users can send friend requests to other users that they have never played with.
For information about the restrictions for this practice, see the guidelines.

Initial Friend List Settings

If a user has never updated Settings Information, a friendship may be established without the user knowing the existence of privacy settings for online status and the game being played.
To prevent this problem, an error results if a friend is temporarily added or a friend request is sent by a local user who has never updated settings information.

The Friend List Viewer is used to make initial settings.
We recommend that you activate the HOME Button menu when a local user adds a friend.

Friendship Status

A friendship becomes established after both parties have registered each other to their friend lists or have accepted the friend requests.
The status of the friendship transitions as follows.

Status Description
Initial state Complete strangers.
Tentative registrant This status indicates that the local user has entered an account ID to add another user to the friend list, and is waiting for that user to add the original user to the friend list.
Requesting The local user has sent a friend request to second party, and is now waiting for the second party to accept the request.
The friend request has an expiration period (of around 30 days), and after that has expired it becomes invalidated and is deleted.
Friendship established Both parties have registered each other on their friend lists.
This status is required to get real-time notifications of online status, the game title currently being played and other information about friends.

Dissolving a Friendship

The friendship is dissolved if the second party deletes the local user from their friend list, or if local user deletes the second party from its friend list.
Unlike with the 3DS, at the time the friendship is dissolved, the user information is deleted from both friend lists, and the users revert to the initial state of being complete strangers.

Parental Controls

Registration to friend lists can be restricted using Friend Registration in the Parental Controls.

▲ Top

Blacklist

The blacklist is used for managing players with whom the user does not want to communicate.
The blacklist can be shared by all Wii U game titles.

Up to 100 users can be registered on the blacklist.If the number of people on the lists reaches this maximum, entries are removed starting from the oldest.

Registering Users to the Blacklist

You can register users to the blacklist by selecting them from Player History in the Friend List Viewer.

Registering a User on the Blacklist From an Application

Users can be registered on the blacklist from applications.

For information about the restrictions for this practice, see the guidelines.

Using the Blacklist

The blacklist is used mainly by NEX.
For more information, see the NEX documentation.

We recommend supporting blacklists if at all possible in titles that do not involve the use of NEX for matchmaking.

▲ Top

Request List

This list manages friend requests that have been sent to the local user.
The request list can be shared by all Wii U game titles.

Approve

Accepts the friend request and establishes the friendship.
The friend is added to the friend list, and the friend request is deleted from the request list.

Delete

Deletes the friend request.
The other user is not notified that the request was deleted.

Rejected

Rejects the friend request and adds the requesting user to the blacklist.
The user is added to the blacklist and the friend request is deleted from the request list.
The other user is not notified that the request was rejected.

▲ Top

Player History

Player History is the Wii U feature for managing the history of play over the network with other users.

Up to 100 users can be added to the Recent Players list.
If the number of people on this list reaches this maximum, entries are removed starting from the oldest.

This "100 registrations" does not mean 100 players.
If any of the following conditions are met, the same user can be registered any number of times.

You can browse Player History from the Friend List Viewer, and from there you can send friend requests or register users to the blacklist.

Registering to Player History

Applications that use NEX add P2P session participants to the Player History automatically.
For more information, see the NEX documentation.

Applications that use an independent server must register other users played with over the network to the Player History.
For more information, see the guidelines.

▲ Top

Relationship Between the Local User and Other Users

The figure shows the transitions in the relation between the local user (A) and another user (B).

Transitions in the status of the relationship between the local user and another user.

▲ Top

Implementation Basics

Initializing and Finalizing the Library

To use the Friend Presence Library API, you must first call the nn::fp::Initialize function to initialize the library.
If you are not going to use the library any longer, call the nn::fp::Finalize function to end the library.

This library has a counter to internally track how many times it has been initialized.

If you call the nn::fp::Initialize function multiple times, you need to call the nn::fp::Finalize function the same number of times to completely end the library.

Use the nn::fp::IsInitialized function to check whether the library has been initialized.

▲ Top

Connecting to the Friend Server

The Wii U is said to be online when it is connected to the friend server, and offline when it is not connected to the friend server.
Use the nn::fp::IsOnline function to determine whether the Wii U is in the online state.

While the system is online, data linked to accounts that are managed on a friend server can be obtained and updated.
When the local system is online, the title and game mode of the game being played is published to friends. The same information can be received from friends who are also online.

Connecting Autonomously

The friend presence daemon (the FPD) autonomously tries to connect to the friend server and put the Wii U in the online state if possible, even without any explicit request from an application.

Connecting From the Application

If an application is actively using the features of this library, it can issue login requests to put the Wii U online, regardless of its autonomous connection status.

Applications must issue a login request when using features that expect the system to be online (such as adding friends, getting the friend list, and changing join-in parameters).
Conversely, applications do not need to issue login requests if autonomous connection is expected when using features where online status does not matter (such as changing the descriptive text for a game mode).

Use the nn::fp::LoginAsync function to issue login requests.
If the login request has been issued and the Wii U has transitioned to the online state, the nn::fp::HasLoggedIn function returns true.

To issue a login request, you must have already established an Internet connection using the AC (automatic connection) library.

If it is no longer necessary to log in, you can cancel the login request by logging out.
Even if a user does not explicitly log out, the login request is canceled if this library shuts down or the application terminates.

If autonomous connection is still enabled even after logging out, the online status is maintained.

Protocol Used For the Friend Presence Features

Protocol:UDP
Source port: 9103
Destination ports: 50000 through 60000

If this communication is being blocked, the error 101-0502 is generated at login time.
If this error happens frequently, check your network configuration.

▲ Top

Receiving Notifications

You can receive notifications from the FPD to keep tabs on changes in the status of the local user, friends, and updates to lists without resorting to polling.

Use the nn::fp::SetNotificationHandler function to receive these notifications.

Select which notifications you want to receive from among nn::fp::NotificationMask.

In addition, the application issues notifications when lists are updated.
For example, if the nn::fp::AddFriendAsync function is run, one of the following notifications is sent when the asynchronous process is successful.

Types of Notifications

The application can receive the following 16 types of notifications.

Notification Type Update Target Notification Timing
nn::fp::NOTIFICATION_ONLINE All When the local user goes online.
nn::fp::NOTIFICATION_OFFLINE All When the local user goes offline.
nn::fp::NOTIFICATION_PREFERENCE Local user's information. When the local user's preferences have been changed.
nn::fp::NOTIFICATION_FRIEND_ONLINE Friend List When a friend goes online.
nn::fp::NOTIFICATION_FRIEND_OFFLINE Friend List When a friend goes offline.
nn::fp::NOTIFICATION_FRIEND_PRESENCE Friend List When the presence information for a friend has changed.

This notification is not received if the join-in game ID is not the same.
For more information, see the "Join-In Game ID" part of the Join-In section.
nn::fp::NOTIFICATION_FRIEND_MII Friend List When a friend's Mii character has changed.
nn::fp::NOTIFICATION_FRIEND_PROFILE Friend List When a friend's profile has changed.
nn::fp::NOTIFICATION_FRIEND_ADDED Friend List When a friend has been added to the friend list.
nn::fp::NOTIFICATION_FRIEND_REMOVED Friend List When a friend has been deleted from the friend list.
nn::fp::NOTIFICATION_MY_REQUEST_ADDED Friend List When a tentative registrant or a user requesting to be friends has been added to the friend list.
nn::fp::NOTIFICATION_MY_REQUEST_REMOVED Friend List When a tentative registrant or a user requesting to be friends has been deleted from the friend list.
nn::fp::NOTIFICATION_MY_REQUEST_UPDATED Friend List When a friend request is sent to a tentative registrant or a user requesting to be friends.
nn::fp::NOTIFICATION_BLACKLIST_ADDED Blacklist When a user has been added to the blacklist.
nn::fp::NOTIFICATION_BLACKLIST_REMOVED Blacklist When a user has been removed from the blacklist.
nn::fp::NOTIFICATION_BLACKLIST_UPDATED Blacklist When the user registration information in the blacklist has been updated.
nn::fp::NOTIFICATION_REQUEST_ADDED Request List When a friend request is received.
nn::fp::NOTIFICATION_REQUEST_REMOVED Request List When a received friend request has been deleted.

Notifications Issued When Tentative Registrants or Users Requesting to Be Friends Get Upgraded to Friend Status

When tentative registrants and users requesting to be friends get upgraded to the status of a friend, the following series of notifications are issued in the order shown.

  1. nn::fp::NOTIFICATION_MY_REQUEST_REMOVED
  2. nn::fp::NOTIFICATION_FRIEND_ADDED

These notifications indicate that the tentative registrant or user requesting to be a friend is first deleted from the friend list, and after that is added to the friend list.  

Core Used to Receive Notifications

The core that calls the nn::fp::SetNotificationHandler function first after nn::fp::Initialize executes is used to handle notifications.
To change the core being used to handle notifications later, you must completely shut down this library once.

▲ Top

Updating Friend Presence

Use the nn::fp::UpdateGameMode function to update the Friend Presence.
If you are updating only the game mode description string, use the nn::fp::UpdateGameModeDescription function.

▲ Top

Registering Users to the Friend List

Use the following methods to register friends to the friend list from the application.

Registering a Friend by Specifying an Account ID or Principal ID

Use the nn::fp::AddFriendAsync function to register the friend.
Use the nn::fp::GetFriendListAll function to check the registration status of the friend list.

Sending Friend Requests

Use the nn::fp::AddFriendRequestAsync function to send a friend request.
If the other user is already on the friend list, the function returns an error, but if that user is a tentative registrant or the request is pending, the friend request is updated.

Applications are prohibited from sending friend requests if the local user is 13 years old or younger.
Use the nn::fp::IsFriendRequestAllowed function to check whether the local user is allowed to send friend requests.

This function returns an error if the other user has blocked friend requests.
Use the nn::fp::GetRequestBlockSettingAsync function to check whether the other party has been set to deny the acceptance of friend requests.

The Friend List Viewer shows friend requests according to the following specifications.
If the user is sending an user-generated message, be sure to check it for profanity.

Common Errors When Registering Friends to the Friend List

Error Description of Error
nn::fp::ResultFpdAddFriendProhibited Local parental control prohibits the user from adding friends.
nn::fp::ResultFpdFriendAlreadyAdded The friend is already on the friend list.
nn::fp::ResultFpdFriendRequestBlocked The other user has blocked friend requests.
nn::fp::ResultFpdPreferenceNotInitialized Friend list settings have never been made.
nn::fp::ResultFpdFriendRequestNotAllowed The local user is not allowed to send friend requests.

▲ Top

Registering Users to the Blacklist

Use the nn::fp::AddBlackListAsync function to register players to the blacklist from the application.

When the limit is reached on the number of users that can be registered to the blacklist, the earliest user is pushed out.
Use the nn::fp::NOTIFICATION_BLACKLIST_REMOVED notification to check which user has been pushed out.

▲ Top

Registering Users to the Player History

Use the nn::fp::AddRecentPlayRecord function to register to Player History.
The Player History data is stored locally, so users can be registered even when the Wii U is offline.

To get the network time, you must connect to the account server at least once.
This is required because the library adds the time that entries are added (network time) during record keeping.

If the network time cannot be obtained, the function returns nn::fp::ResultNetworkClockInvalid.

The system connects to the account server whenever you connect to the friend server or game server, or when you get a service token for an independent service.

▲ Top

Handling Errors

Synchronous API Functions

If a call to a synchronous API function fails, it is an implementation mistake.
Revise your program.

Asynchronous API Functions

If a call to an asynchronous API function fails, it may be an implementation mistake or it may be that too many calls to asynchronous functions have been made.
Revise your program.

If an asynchronous process has returned failure and ended, you can get the error code by passing its nn::Result object to the nn::fp::ResultToErrorCode function.

After you have gotten the error code, pass the error code to the Error Viewer and display the error.
However, you do not need to display errors in situations where the game can continue without inconveniencing the user, such as when login has failed and automatically retries immediately.

When the content of the nn::Result object is converted into an error code, information is added about the state of the FPD at that time.
For this reason, when getting error codes promptly call the nn::fp::ResultToErrorCode function after receiving a failure result.

▲ Top

Calling Frequency and Response Speed for API Functions

The features of this library may decreases response times because of increased system load.
Frequent API function calls result in an increased system load. Avoid implementing code that polls for information every game frame.

The following program examples execute continuously while online. One has a high system load and the other a low system load.

Example of Programming With a High System Load

void Func()
{
    while (nn::fp::IsOnline())
    {
        // processing...
    }
}

Example of Programming With a Low System Load

Handling Notifications

void NotificationHandler(nn::fp::NotificationType notificationType, nn::fp::PrincipalId principalId, void* pContext)
{
    if (notificationType == nn::fp::NOTIFICATION_OFFLINE)
    {
        OSSignalEvent(&s_eventOffline);
    }
}

void Func()
{
    if (nn::fp::IsOnline())
    {
        while (1)
        {
            if (OSWaitEventWithTimeout(&s_eventOffline, 0)) break;

            // processing...
        }
    }
}

Getting Information Once Every Few Frames

void Func()
{
    bool isOnline = nn::fp::IsOnline();

    int counter = 0;

    while (isOnline)
    {
        if (++counter >= 60)
        {
            isOnline = nn::fp::IsOnline();
            counter = 0;
        }

        // processing...
    }
}

▲ Top

Revision History

2013-08-30 Revised information about the friend registration sequence in the Friend List Viewer because of changes.
2013-07-24 Revised information about the API functions that handle friend request operations because they were made public.
2013-07-23 Revised information about the Friend List Viewer because it now supports the join-in feature.
2013-04-05 Revised the description of applications making connections.
2013-03-06 Revised the description for the join-in game ID.
2013-02-22 Revised the description for the join-in game ID.
2013-01-16 Added a description of the protocol used for the friend presence features.
2013-01-11 Corrected typos in the update targets for sending and notifying about friend requests.
2013-01-10 Revised some descriptions in line with the availability of the Friend List Viewer.
2012-10-19 Added Calling Frequency and Response Speed for API Functions.
2012-10-09 Revised the format and layout.
2012-08-22 Revised some descriptions because request lists can now be obtained.
2012-08-06 Initial version.


WUP-06-0146-003-D


CONFIDENTIAL