User overview
Learn about user profiles, friendships, friend requests, blacklists, and online status in the Android SDK.
OpenIM Android SDK identifies each user by userID. When implementing profile cards, friend requests, contacts, or a blocklist, distinguish an application's public user profile from the current user's friend relationship and blocklist state.
Group member lists, in-group nicknames, group roles, and member administration belong to the Groups domain. User APIs cover profiles, friendships, friend requests, blacklists, and online status.
User objects
Android SDK returns different user objects for different scenarios:
| Type | Use case | Main APIs |
|---|---|---|
LocalUser | The current user's local profile, settings page, avatar, nickname, and account-level receive setting | getSelfLocalUserInfo(), setSelfInfo() |
PublicUserInfo | Application user lookup, friend candidates, and profiles for users who are not friends | getUsersInfo() |
UserInfo | Combined Android wrapper object that can carry public, friend, or blacklist information | getFriendListPage(), getFriendsInfo(), getBlacklist() |
FriendInfo | The current user's friend list, friend remarks, and relationship extension data | searchFriends(), getFriendListPage() |
FriendApplicationInfo | The parties, handling state, and message for a friend request | Friend request queries and callbacks |
BlacklistInfo | Users blocked by the current user and their blocklist relationship fields | getBlacklist(), addBlacklist(), removeBlacklist() |
UsersOnlineStatus | User online status and connected platforms | subscribeUsersOnlineStatus(), getSubscribeOnlineUsersStatus() |
The same userID can appear in public profile, friend, blocklist, and group member data. Prefer UserInfo.getFriendInfo() when displaying a contact, PublicUserInfo when only a public account profile is needed, and UserInfo.getBlackInfo() on a blocklist screen. Conversation list and chat page titles belong to conversation data and should use the conversation display name.
Use userID as the stable key for user lists and events. A friend request contains both parties, so use fromUserID:toUserID to identify one request.
Feature entry points
| Requirement | Recommended page |
|---|---|
Retrieve public profiles by userID for friend candidates or profile cards | Get specified user profiles |
| Page through, search, or retrieve friend relationships by ID | Get the friend list by page |
| Send, retrieve, accept, or reject friend requests | Get received friend requests |
| Update friend data | Update friend profiles |
| Delete a friend relationship | Delete a friend |
| View and maintain the current user's blocklist | Get the blacklist |
| Read or update the current user's nickname, avatar, and extension data | Update the current user profile |
| Configure account-level message reception and notification behavior | Set global message reception |
| Subscribe to and retrieve online status | Subscribe to user online status |
State updates
Each user-related capability page owns the listener and merge behavior for its events:
- Current user profile changes: Update the current user profile.
- Friend request changes: Get received friend requests.
- Friend relationship and profile changes: Get the friend list by page.
- Blocklist changes: Block a user.
- Online status changes: Subscribe to user online status.
UserInfoManager and FriendshipManager each retain one listener. setOnUserListener() and setOnFriendshipListener() replace the current listener. Combine the required callbacks in a shared state layer and set each listener once; multiple pages must not overwrite one another's listeners.
Was this page helpful?