Android Custom Issue Reporting - Manual Error Tracking

Manual Reporting: Use the single-line API to report anticipated issues and logic/ functional issues.

Type: 1 | Default Severity: Minor

The Appxiom SDK provides a powerful custom issue reporting system that allows you to manually report anticipated failures, logic errors, and user workflow issues. Use the Ax.reportIssue() API to track issues that don't cause crashes but impact user experience.

Java

public class PaymentActivity extends AppCompatActivity {
    
    private void paymentCompleted(String userIdentifier, int type) {
        // Handle successful payment
        processPaymentSuccess(userIdentifier, type);
    }
    
    private void paymentFailed(String userIdentifier, String reason) {
        // Add context with activity marker
        Ax.setActivityMarker(this, "User identifier: " + userIdentifier);
        
        // Report the payment failure with severity
        Ax.reportIssue(this, "Payment Failed", reason, Severity.MAJOR);
        
        // Handle payment failure UI
        showPaymentErrorDialog(reason);
    }
}

Kotlin

class PaymentActivity : AppCompatActivity() {
    
    private fun paymentCompleted(userIdentifier: String, type: Int) {
        // Handle successful payment
        processPaymentSuccess(userIdentifier, type)
    }
    
    private fun paymentFailed(userIdentifier: String, reason: String) {
        // Add context with activity marker
        Ax.setActivityMarker(this@PaymentActivity, "User identifier: $userIdentifier")
        
        // Report the payment failure with severity
        Ax.reportIssue(this@PaymentActivity, "Payment Failed", reason, Severity.MAJOR)
        
        // Handle payment failure UI
        showPaymentErrorDialog(reason)
    }
}

For tracking complete user journey success rates like payment flows or others, consider using Goal Friction Impact (GFI) tracking.

API Parameters

The Ax.reportIssue() method accepts the following parameters:

Ax.reportIssue(Context context, String description, String detailedDescription, byte severity)

Parameters:

• context: Android Context (Activity, Fragment, or Application context)
• description: Short, descriptive title for the issue (e.g., "Payment Failed")
• detailedDescription: Detailed description with error details and context
• severity: Severity level using Severity constants (Severity.MINOR, Severity.MAJOR, or Severity.FATAL)

Advanced Usage Examples

User Authentication Issues

Java

private void handleAuthenticationFailure(String userId, String failureReason) {
    // Set user context
    Ax.setCustomId(userId);
    Ax.setActivityMarker(this, "Authentication attempt for: " + userId);
    
    // Report authentication issue
    Ax.reportIssue(this, "Authentication Failed", 
                       "User login failed: " + failureReason, Severity.MAJOR);
    
    // Clear sensitive session data
    clearUserSession();
}

Kotlin

private fun handleAuthenticationFailure(userId: String, failureReason: String) {
    // Set user context
    Ax.setCustomId(userId)
    Ax.setActivityMarker(this, "Authentication attempt for: $userId")
    
    // Report authentication issue
    Ax.reportIssue(this, "Authentication Failed", 
                       "User login failed: $failureReason", Severity.MAJOR)
    
    // Clear sensitive session data
    clearUserSession()
}

When not to Use Custom Issue Reporting

Inappropriate Use Cases

Avoid using custom issue reporting for:

• General application logging
• Debug information
• Performance metrics
• Regular user actions or events

---

Frequently Asked Questions (FAQ)

Q: When should I use custom issue reporting?

A: Use custom issue reporting for anticipated failures and logic errors that don't crash the app, such as payment failures, API errors, or user workflow interruptions.

Q: What parameters does the Ax.reportIssue() method accept?

A: The method accepts four parameters: Context (Activity/Fragment context), description (short title), detailedDescription (detailed error information), and severity (using Severity.MINOR, Severity.MAJOR, or Severity.FATAL constants).

Q: Can I report custom issues from any part of my Android application?

A: Yes, you can call Ax.reportIssue() from any Activity, Fragment, Service, or any component that has access to a valid Android Context.

Q: Is there a limit to how many custom issues I can report?

A: There's no hard limit, but use custom issue reporting judiciously for actual problems rather than general logging to maintain meaningful analytics data.

Q: What makes a good custom issue title and description?

A: Use clear, concise titles that identify the problem area (e.g., "Payment Failed"). Include detailed descriptions with error codes, user context, and relevant state information.

Q: Should I include sensitive user data in custom issue reports?

A: No, avoid including passwords, personal information, or sensitive data. Use user identifiers and general context information instead.

Q: How do I add context to custom issues for better debugging?

A: Use Ax.setActivityMarker() before reporting issues to add context like user identifiers, workflow steps, and relevant state information.

Q: What happens if I call Ax.reportIssue() without setting activity markers?

A: The issue will still be reported with the title and description, but won't include additional context. Activity markers are optional but recommended for better debugging.

Q: Can I report custom issues from background services or workers?

A: Yes, as long as you have a valid Context. Use the Application context for background operations to avoid memory leaks.

Q: What's the difference between custom issues and exceptions reported with try-catch?

A: Custom issues are manually reported anticipated failures, while try-catch exception reporting captures unexpected runtime exceptions. Use custom issues for logic failures.

Q: Can I group similar custom issues together for analysis?

A: Yes, issues with identical titles are automatically grouped in the dashboard. Use consistent naming conventions for similar issue types.

Q: How do I correlate custom issues with user actions or app features?

A: Use activity markers to capture user workflow steps and feature usage before reporting issues. This provides valuable context for issue analysis.

Q: Can I set different severity levels for custom issues?

A: Yes, you can explicitly set severity levels when reporting custom issues using the fourth parameter in Ax.reportIssue(). Use Severity.MINOR for minor issues, Severity.MAJOR for significant problems, or Severity.FATAL for critical failures. If not specified, custom issues default to Minor severity.

---