Android网络请求UI处理最佳实践：Model层重复请求控制问询

Great question! When you want to prevent duplicate requests (like repeated login button clicks) while keeping the View layer lightweight, the Model layer is the perfect place to enforce this constraint. Here are the most robust RxJava-based practices tailored to your scenario:

1. Use AtomicReference to Track Active Requests #

This approach gives you explicit control over whether a request is already in flight. You’ll maintain a reference to the ongoing Observable, and return it instead of creating a new one if a request is already running. Once the request completes (success or failure), you clear the reference to allow future requests.

Example Implementation (Java): #

public class AuthModel {
    private final AtomicReference<Observable<LoginResponse>> currentLoginRequest = new AtomicReference<>();
    private final ApiService apiService;

    public AuthModel(ApiService apiService) {
        this.apiService = apiService;
    }

    public Observable<LoginResponse> login(String email, String password) {
        // Check if a request is already active
        Observable<LoginResponse> existingRequest = currentLoginRequest.get();
        if (existingRequest != null) {
            return existingRequest;
        }

        // Create new request, and clear reference once done
        Observable<LoginResponse> newRequest = apiService.login(email, password)
                .doFinally(() -> currentLoginRequest.set(null)) // Runs on success/failure/complete
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread());

        // Atomic update to avoid race conditions from concurrent clicks
        if (currentLoginRequest.compareAndSet(null, newRequest)) {
            return newRequest;
        } else {
            // Another request was created in the meantime—return that one
            return currentLoginRequest.get();
        }
    }
}

Why this works: #

• The AtomicReference ensures thread-safe checks and updates, so even rapid consecutive clicks won’t spawn duplicate requests.
• The doFinally operator guarantees the reference is cleared no matter how the request terminates (success, error, or cancellation).
• The View/Presenter only needs to call login() and handle the Observable—no extra logic to track request state.

2. Use share() to Share a Single Request Subscription #

If you prefer a more declarative approach, share() converts a cold Observable (which triggers a new request on each subscription) into a hot Observable that shares the same request with all subscribers. This means multiple calls to subscribe will reuse the ongoing request instead of creating new ones.

Example Implementation: #

public Observable<LoginResponse> login(String email, String password) {
    return apiService.login(email, password)
            .subscribeOn(Schedulers.io())
            .observeOn(AndroidSchedulers.mainThread())
            .share();
}

Why this works: #

• When the first subscription triggers the request, any subsequent subscriptions during the request will receive the same emission once it completes.
• Once the request finishes and all subscribers unsubscribe, the Observable resets—so future calls to login() will trigger a new request (which is exactly what you want for fresh login attempts).
• This is simpler for basic use cases where you don’t need explicit control over the request reference.

3. Bonus: switchMap for Canceling Stale Requests #

While not exactly your use case, it’s worth mentioning switchMap if you want to cancel older requests when a new one is triggered (e.g., if the user clicks login multiple times quickly and you only care about the latest request). This is useful if you want to avoid processing outdated responses, though it doesn’t prevent multiple requests entirely—just cancels the old ones.

Example (Presenter Layer): #

// In Presenter (connecting View clicks to Model)
CompositeDisposable disposables = new CompositeDisposable();

public void onLoginClicked(String email, String password) {
    disposables.clear(); // Cancel previous subscription
    disposables.add(authModel.login(email, password)
            .subscribe(response -> handleLoginSuccess(), error -> handleLoginError()));
}

Or using RxBinding for click streams:

RxView.clicks(loginButton)
        .switchMap(ignored -> authModel.login(email, password))
        .subscribe(response -> handleLoginSuccess(), error -> handleLoginError());

Key Takeaways #

• AtomicReference is best for explicit control and thread safety in complex scenarios.
• share() is ideal for simple, declarative request sharing with minimal code.
• Both approaches keep the View layer lightweight—no need for button disabling logic (though you can add it for UX polish, it’s not required for request safety).

内容的提问来源于stack exchange，提问作者Alessandra Maria