Jak poradzić sobie z ponowną aktualizacją zdalnego serwera za pomocą SyncAdapter

Krótka odpowiedź, jeśli kierujesz ~ API poziom 7, to "nie". Sytuacja mogła się poprawić w późniejszych API, ale tak było... Zdecydowanie zalecam całkowite unikanie SyncAdapter; jest to udokumentowane bardzo słabo, a "automatyczne" zarządzanie kontem/uwierzytelnianiem ma wysoką cenę, ponieważ API jest również zawiłe i niedostatecznie udokumentowane. Ta część API nie została przemyślana poza najbardziej banalnymi przypadkami użycia.

Oto wzór, z którym skończyłem. Wewnątrz moich działań miałem Handlera z prostym dodatkiem z niestandardowej superklasy Handlera (mogłem sprawdzić dla m_bStopped bool):

private ResponseHandler mHandler = new ResponseHandler();

class ResponseHandler extends StopableHandler {

    @Override
    public void handleMessage(Message msg) {
        if (isStopped()) {
            return;
        }
        if (msg.what == WebAPIClient.GET_PLANS_RESPONSE) {
            ...
        } 
        ...
    }
}

Aktywność wywoła prośby o resztę, jak pokazano poniżej. Zauważ, że handler jest przekazywany do klasy WebClient (klasy pomocniczej do budowania/wykonywania żądań HTTP itd.). WebClient używa tej funkcji obsługi, gdy otrzymuje odpowiedź HTTP na wiadomość z powrotem do aktywności i informuje ją, że dane zostały odebrane i, w moim przypadku, przechowywane w Bazy danych SQLite (co polecam). W większości działań wywołałbym mHandler.stopHandler(); in onPause() i mHandler.startHandler(); in onResume(), aby uniknąć zasygnalizowania odpowiedzi HTTP z powrotem do nieaktywnej aktywności itp. Okazało się to dość solidnym podejściem.

final Bundle bundle = new Bundle();
bundle.putBoolean(WebAPIRequestHelper.REQUEST_CREATESIMKITORDER, true);
bundle.putString(WebAPIRequestHelper.REQUEST_PARAM_KIT_TYPE, sCVN);       
final Runnable runnable = new Runnable() { public void run() {
    VendApplication.getWebClient().processRequest(null, bundle, null, null, null,
                    mHandler, NewAccountActivity.this);
    }};
mRequestThread = Utils.performOnBackgroundThread(runnable);

Handler.handleMessage() jest wywoływany w głównym wątku. Możesz więc zatrzymać okna dialogowe postępu i bezpiecznie wykonywać inne czynności.

Zadeklarowałem treść:

<provider android:name="au.com.myproj.android.app.webapi.WebAPIProvider"
          android:authorities="au.com.myproj.android.app.provider.webapiprovider"
          android:syncable="true" />

I zaimplementował go do tworzenia i zarządzania dostępem do SQLite db:

public class WebAPIProvider extends ContentProvider

Więc możesz uzyskać Kursory nad bazą danych w swoich działaniach w następujący sposób:

mCursor = this.getContentResolver().query (
          WebAPIProvider.PRODUCTS_URI, null, 
          Utils.getProductsWhereClause(this), null, 
          Utils.getProductsOrderClause(this));
startManagingCursor(mCursor);

Uznałem, że klasa org.apache.commons.lang3.text.StrSubstitutor jest niezmiernie pomocna w konstruowaniu niezgrabnych żądań XML wymaganych przez REST API, z którymi musiałem się zintegrować np. w WebAPIRequestHelper miałem metody pomocnicze takie jak:

public static String makeAuthenticateQueryString(Bundle params)
{
    Map<String, String> valuesMap = new HashMap<String, String>();
    checkRequiredParam("makeAuthenticateQueryString()", params, REQUEST_PARAM_ACCOUNTNUMBER);
    checkRequiredParam("makeAuthenticateQueryString()", params, REQUEST_PARAM_ACCOUNTPASSWORD);

    valuesMap.put(REQUEST_PARAM_APIUSERNAME, API_USERNAME);
    valuesMap.put(REQUEST_PARAM_ACCOUNTNUMBER, params.getString(REQUEST_PARAM_ACCOUNTNUMBER));
    valuesMap.put(REQUEST_PARAM_ACCOUNTPASSWORD, params.getString(REQUEST_PARAM_ACCOUNTPASSWORD));

    String xmlTemplate = VendApplication.getContext().getString(R.string.XMLREQUEST_AUTHENTICATE_ACCOUNT);
    StrSubstitutor sub = new StrSubstitutor(valuesMap);
    return sub.replace(xmlTemplate);
}

Którą dopisałbym do odpowiedniego adresu URL punktu końcowego.

Oto kilka szczegółów na temat tego, jak Klasa WebClient wykonuje żądania HTTP. Jest to metoda processRequest() o nazwie wcześniej w biegu. Zwróć uwagę na parametr handler, który służy do przesyłania wyników z powrotem do ResponseHandler, który opisałem powyżej. syncResult jest parametrem in out używanym przez SyncAdapter do wykładniczego cofania itp. Używam go w executeRequest(), zwiększając liczbę błędów itp. Ponownie, bardzo słabo udokumentowane i PITA do pracy. parseXML() wykorzystuje znakomity prosty XML lib .

public synchronized void processRequest(Account account, Bundle extras, String authority, ContentProviderClient provider, SyncResult syncResult, Handler handler, Context context)
{
    // Helper to construct the query string from the query params passed in the extras Bundle.
    HttpUriRequest request = createHTTPRequest(extras);
    // Helper to perform the HTTP request using org.apache.http.impl.client.DefaultHttpClient.
    InputStream instream = executeRequest(request, syncResult);

    /*
     * Process the result.
     */
    if(extras.containsKey(WebAPIRequestHelper.REQUEST_GETBALANCE))
    {
        GetServiceBalanceResponse xmlDoc = parseXML(GetServiceBalanceResponse.class, instream, syncResult);
        Assert.assertNotNull(handler);
        Message m = handler.obtainMessage(WebAPIClient.GET_BALANCE_RESPONSE, xmlDoc);
        m.sendToTarget();
    }
    else if(extras.containsKey(WebAPIRequestHelper.REQUEST_GETACCOUNTINFO))
    {
      ...
    }
    ...

}

Powinieneś umieścić kilka timeoutów na żądaniach HTTP, aby aplikacja nie czekała wiecznie jeśli dane komórkowe wypadną lub przełącza się z Wifi na 3G. spowoduje to wyrzucenie wyjątku, jeśli wystąpi limit czasu.

    // Set the timeout in milliseconds until a connection is established.
    int timeoutConnection = 30000;
    HttpConnectionParams.setConnectionTimeout(httpParameters, timeoutConnection);
    // Set the default socket timeout (SO_TIMEOUT) in milliseconds which is the timeout for waiting for data.
    int timeoutSocket = 30000;
    HttpConnectionParams.setSoTimeout(httpParameters, timeoutSocket);
    HttpClient client = new DefaultHttpClient(httpParameters);          

Więc ogólnie rzecz biorąc, sprawy SyncAdapter i konta były całkowitym bólem i kosztowały mnie dużo czasu za brak zysku. ContentProvider był dość przydatny, głównie do obsługi kursora i transakcji. Baza danych SQLite była naprawdę dobra. A zajęcia z obsługi są świetne. Użyłbym teraz klasy AsyncTask zamiast tworzenia własnych wątków, jak to zrobiłem powyżej aby wywołać żądania HTTP.

Mam nadzieję, że to bełkotliwe Wyjaśnienie pomoże komuś trochę.