Lancement de notre SDK Android récemment réécrit

Ifedapo Olarewaju

Développeur · Lagos, Nigeria · Afficher la bio

En avril 2018, nous avons présenté une version réécrite du SDK Android⁠. Bien que notre SDK Java⁠ puisse déjà être utilisé dans des projets Android, et qu’une intégration Android antérieure ait existé, cette réécriture offrait une API plus cohérente avec le reste de nos SDK.

Construite sur le SDK Java, l’intégration Android ajoutait la soumission asynchrone des Assemblies et la possibilité de mettre en pause puis de reprendre les envois. Une application pouvait continuer à répondre à l’utilisateur pendant l’envoi et le traitement des fichiers, et recevoir au fil de l’eau des callbacks de progression et de fin.

Mise à jour de sécurité, septembre 2026 : l’exemple 0.0.2 d’origine transmettait un Auth Secret au SDK dans une activité Android. Le secret aurait ainsi été distribué avec l’application. Les exemples d’activité exécutables ont été remplacés ci-dessous ; conservez l’Auth Secret sur un backend de confiance, même pour une application distribuée en interne. Le backend doit authentifier l’utilisateur et autoriser l’envoi avant de signer le moindre paramètre. Suivez notre guide sur la Signature Authentication et exigez des signatures pour le Workspace ou le Template utilisé par l’application.

Le client Android 0.0.2 n’exposait pas de constructeur SignatureProvider. Conserver le code d’activité de cette version basé sur le secret en y ajoutant simplement une URL de backend ne corrigerait pas le problème ; une intégration a besoin d’une API de signature externe prise en charge ou d’un autre chemin de requête.

La version d’origine utilisait la configuration Gradle compile et indiquait Maven Central et JCenter comme sources d’installation. Il s’agissait des instructions d’installation de 0.0.2, et non d’une configuration de build actuelle. Son flux de travail en arrière-plan était le suivant :

1. Implémenter un écouteur d’Assembly pour recevoir la progression de l’envoi, la fin de l’envoi, la fin du traitement, les échecs d’envoi et les échecs de mise à jour du statut.
2. Créer le client Android et une Assembly asynchrone associée au contexte et à l’écouteur de l’activité.
3. Joindre une image locale et ajouter un Step /image/resize, avec une largeur et une hauteur de 75 pixels et resize_strategy défini sur pad.
4. Soumettre l’Assembly et poursuivre d’autres tâches pendant que l’écouteur rend compte de sa progression. La fin de l’envoi et la réussite du traitement sont des événements distincts.

L’ancien exemple mélangeait les noms de variables androidAsyncAssembly et assembly et ne constitue pas une activité utilisable à copier dans un projet actuel. L’exemple plus court ci-dessous conserve l’opération de redimensionnement et montre la frontière de signature introduite plus tard, sans dépendre du cycle de vie d’une activité.

Il utilise le SDK Android 0.2.0 avec le SDK Java 2.2.4, tous deux publiés sur Maven Central. Il s’agit de versions ultérieures, et non des versions annoncées en 2018. Le POM publié de l’artefact Android omet ses déclarations de dépendances ; ne supposez donc pas que l’ajout de l’AAR seul installe ses dépendances. Pour une intégration Android complète, utilisez la liste de dépendances du build Android étiqueté⁠ et vérifiez-la dans le build de votre application.

Cette classe utilitaire accepte un SignatureProvider implémenté par l’intégration backend dont vous disposez déjà. Elle ne contient ni secret ni endpoint de signature :

import com.transloadit.android.sdk.AndroidTransloadit;
import com.transloadit.sdk.Assembly;
import com.transloadit.sdk.SignatureProvider;
import java.io.File;
import java.util.HashMap;
import java.util.Map;

public final class ImageUpload {
  private ImageUpload() {}

  public static AndroidTransloadit createClient(
      String authKey, SignatureProvider approvedSignatures) {
    return new AndroidTransloadit(authKey, approvedSignatures);
  }

  public static void addImage(Assembly assembly, File image) {
    assembly.addFile(image, "image");

    Map<String, Object> stepOptions = new HashMap<>();
    stepOptions.put("width", 75);
    stepOptions.put("height", 75);
    stepOptions.put("resize_strategy", "pad");
    assembly.addStep("resize", "/image/resize", stepOptions);
  }
}

Le fournisseur reçoit les paramètres sérialisés et renvoie la signature du backend pour ces octets exacts, ou lève une exception si l’autorisation ou la signature échoue. Votre serveur doit imposer les Steps ou le Template autorisés, les destinations, les limites de fichiers et une expiration courte. Il ne doit pas signer un corps JSON arbitraire simplement parce que l’appelant est connecté. Pour un flux de travail fixe, un Template choisi par le serveur, avec allow_steps_override désactivé, peut garder les instructions de traitement sous le contrôle du serveur. Ne renvoyez pas l’Auth Secret au fournisseur.

Dans une application Android, l’API ultérieure crée un objet AndroidAssembly avec newAssembly(listener, context), où l’écouteur implémente AndroidAssemblyListener. Cette Assembly peut être transmise à ImageUpload.addImage, puis soumise avec saveAsync(). Le callback de progression s’appelle onUploadProgress. Gardez le travail réseau hors du thread UI et liez les callbacks au cycle de vie réel de l’application. Examinez le statut de la réponse et hasError(), en plus de gérer les exceptions ; une réponse d’erreur de l’API n’est pas nécessairement levée sous forme d’exception. La classe utilitaire ci-dessus couvre la configuration du client et de l’image ; elle n’implémente pas la planification en arrière-plan et ne vérifie pas le comportement de pause et de reprise sur un appareil.

Pour plus de détails sur la version que vous intégrez, consultez le code source du SDK Android⁠ et sa référence d’API⁠. La version d’origine a facilité l’intégration des envois sur Android ; conserver la signature sur votre backend est essentiel pour reprendre ce flux de travail dans une application aujourd’hui.