Logging

Network Activity Monitoring

Monitor and debug network activities in your social.plus SDK integration with comprehensive logging capabilities.
Best Practice: Enable network logging during development to troubleshoot issues, but disable it in production to avoid performance overhead.
The observeNetworkActivities() function provides real-time insights into all HTTP requests and responses within the SDK, enabling effective debugging and performance analysis.

Key Features

  • Request/Response Logging: Monitor all API calls with detailed information
  • Performance Metrics: Track request timing and response sizes
  • Error Debugging: Identify network-related issues quickly
  • Development Tool: Essential for troubleshooting SDK integration
/// Observe ongoing network activities in sdk
client.observeNetworkActivities { request, response, data in
    
    // request: URLRequest // Request
    // response: HTTPURLResponse // HTTP Protocol response
    // data: Data // Payload returned from server
    
}

Troubleshooting

Common Issues

Error Handling

Effective error handling is crucial for building reliable social applications. social.plus SDK provides structured error information to help you handle different scenarios gracefully.

Error Types

social.plus errors are categorized into two main types:

Server Errors

Issues on the social.plus backend (400xxx, 500xxx codes)

Client Errors

Issues in the SDK or client environment (800xxx codes)

Common Server Errors

Client Errors

CodeErrorDescription
800000UnknownUncategorized client-side error
800110InvalidParameterInvalid parameter data type
800210ConnectionErrorNetwork connectivity issues

Error Handling Implementation

Basic Error Parsing

func parseError(_ error: Error) {
    let sdkError = error as NSError
    guard let amityError = AmityErrorCode(rawValue: sdkError.code) else {
        // Unknown error occurred. Please report this error code to Amity
        return
    }
    
    // ...
    // Process AmityError here..
}

Global Ban Handling

A global ban error means that the user is banned from the system resulting in the inability to have a connection with the system. If the user already has a session, the session will be revoked, and will be unable to create a new session.
var client: AmityClient?
client.clientErrorDelegate = self // set yourself as the delegate

...

// Implement this delegate method which gets called when error occurs
func didReceiveAsyncError(_ error: Error) {
        let error = error as NSError
        guard let amityError = AmityErrorCode(rawValue: error.code) else {
            assertionFailure("unknown error \(error.code), please report this code to Amity")
            return
        }
        
        if amityError == .globalBan {
            // Handle global ban event here
        }
    }
}

Best Practices

Do’s ✅

  • Provide specific error messages based on error codes
  • Log errors for debugging and monitoring
  • Implement retry logic for network errors
  • Handle global bans with appropriate user communication
  • Use error boundaries in React applications
  • Show loading states during error recovery

Don’ts ❌

  • Don’t ignore errors - always handle them appropriately
  • Don’t show technical error codes to end users
  • Don’t retry indefinitely - implement maximum retry limits
  • Don’t expose sensitive information in error messages
Pro Tip: Use network logging to identify performance bottlenecks, monitor error rates, and validate that your app is making expected API calls during development.