Validation of Implementation: Rick and Morty API App

Introduction

This document details the validation process of the Rick and Morty API application, focusing on technical decisions, optimizations, and SDK-like architecture designed to create a mobile solution that allows the developers to implement the product and track its performance.

Core SDK-Like Architecture

1. SDK Encapsulation with Clean API Interface

Description: Designed the application with a complete abstraction layer.

Implementation:

public class RickAndMortySDK {
    // Clean public API
    public void getCharacters(ApiCallback<Resource<List<CharacterBean>>> callback) {...}
    public void loadMoreCharacters(ApiCallback<Resource<List<CharacterBean>>> callback) {...}
    public void refreshCharacters(ApiCallback<Resource<List<CharacterBean>>> callback) {...}
    
    // Built-in instrumentation APIs
    public void startNetworkTracking(String requestId) {...}
    public void startUiTracking(String eventId) {...}
}

Justification:

• Allows internal evolution without affecting public interfaces
• Follows SOLID principles, particularly the Single Responsibility Principle
• Somewhat similar to real-world advertising SDK structure with clear integration points

2. Dual Performance Monitoring System

Description: Implementation of two specialized monitoring systems:

• NetworkMonitor: For tracking network request performance
• UiPerformanceMonitor: For measuring UI rendering latencies

Implementation:

public void startNetworkTracking(String requestId) {
    networkMonitor.startTracking(requestId);
}

public long stopNetworkTracking(String requestId, boolean fromCache) {
    return networkMonitor.stopTracking(requestId, fromCache);
}

Justification:

• Adaptive threshold system customized by operation type enables tracking of targeted optimization

3. HTTP Caching Strategy

Description: Implementation of a HTTP caching system with specific expiration policies.

Implementation:

OkHttpClient okHttpClient = new OkHttpClient.Builder()
        .cache(cache)
        .addInterceptor(chain -> {
            Request.Builder builder = request.newBuilder();
            builder.addHeader("Cache-Control",
                    "public, max-age=120, max-stale=86400");
            return chain.proceed(builder.build());
        })
        .build();

Justification:

• Should reduce redundant network requests

4. Resource Pattern for State Management

Description: Implementation of the Resource pattern to unify state handling throughout the application.

Implementation:

public class Resource<T> {
    public enum Status { LOADING, SUCCESS, ERROR, EMPTY }
    private final Status status;
    private final T data;
    private final RMError error;
    
    // Factory methods for different states
    public static <T> Resource<T> loading() {...}
    public static <T> Resource<T> success(T data) {...}
    public static <T> Resource<T> error(RMError error) {...}
    public static <T> Resource<T> empty() {...}
}

Justification:

• Improves testability and error handling

5. Preloading

Description: System for background preloading of content before user demand.

Implementation:

private void preloadNextPages(int currentPageNumber) {
    if (!PRELOAD_ENABLED) return;
    
    for (int i = 1; i <= PRELOAD_DISTANCE; i++) {
        int pageToPreload = currentPageNumber + i;
        
        if (pageToPreload <= totalPages &&
                !pageCache.containsKey(pageToPreload) &&
                !loadingPages.contains(pageToPreload)) {
            
            loadingPages.add(pageToPreload);
            fetchPageBackground(pageToPreload, "preload");
        }
    }
}

Justification:

• Eliminate perceived latency while navigating content

Possible improvements

• Encapsulation of the CharactersAdapter into the SDK
• Encapsulation of the callback logic, to hide completely all code complexity on Sdk-user's end.
• Automatic/Manual performance tracking for UI
• SDK configurability: Enable/Disable logging, Preload pages amount, Cache size limit, etc.
• Several UI and functionalities adaptations could be added such as text filters, data filters, sorting, list and detail screen improvements, etc. But that is not the main focus of this excersise.

Conclusion

This implementation demonstrates some of what I have recently learned in building SDK-like architectures with a focus on performance, reliability, and resource optimization. Some of the technical features like the monitoring systems, caching strategy, and multithreaded operations are the type of things that we could expect to work on.

This is a very basic approach to mirror real-world ad SDK architecture with clean public interfaces, performance instrumentation, and intelligent resource management.