Bien sûr, cette question concerne la commodité, mais le cadre actuel de l'application doit être pris en compte :
Utilisez les rappels comme mentionné ci-dessus. Mais notez que, comme les rappels sont référencés par des variables statiques, les rappels sont généralement des classes internes anonymes, ce qui peut provoquer des fuites de mémoire.
Utilisez le bus d'événements. Il implémente également la couche intermédiaire et transmet les résultats via le bus d'événements.
Recommandation : Puisqu'il s'agit d'un refactoring, vous pouvez envisager de permettre à tous les contrôles d'avoir pour fonction d'obtenir des résultats onActivityResult, interface onActivityResult {
.
boolean onResult();
> Les contrôles personnalisés qui doivent écouter les rappels implémentent cette interface. Dans BaseActivity, enregistrez ces contrôles et transmettez-les à ces contrôles lorsque les résultats sont renvoyés : class BaseActivity {
List<onActivityResult> resultViewList = new ArrayList();
void onCreate() {
ResultView view = ...;
resultViewList.add(view);
}
onActivityResult() {
for (onActivityResult view : resultViewList) {
boolean ret = view.onResult();
if (ret) {
break;
}
}
}
> Cela résout complètement le problème dont le contrôle a besoin pour obtenir le résultat de l'activité.
Ce qui précède est un code approximatif, mais il y a en fait d'autres considérations : le problème des requêtes répétées, toutes les vues doivent être enregistrées.
Ce que vous avez dit ci-dessus est bon. Définissez une interface et utilisez les rappels d'interface pour le faire. Pour d'autres vues courantes, implémentez simplement cette interface.
Notre approche consiste à écrire la prise de photo et l'album photo en tant que module, puis à ajouter un événement de clic au composant qui définit l'avatar, à cliquer pour accéder à l'interface de traitement, puis à revenir. Le composant de configuration n'est pas inclus dans le module et est défini par l'utilisateur du module. Une autre façon consiste à utiliser la surveillance des événements comme mentionné ci-dessus. Après avoir sélectionné la photo de l'album ou pris une photo pour confirmer la photo, déclenchez cet auditeur. Je vous propose de demander à votre patron si vous êtes sûr d'écrire la Vue d'entrée dans le Module
Créez un entrepôt maven local et encapsulez les fonctions de contrôle, de fenêtre contextuelle et de saut. Ensuite, téléchargez-le directement dans l'entrepôt maven local, puis dépendez-en pour le projet via Gradle Construisez l'entrepôt maven local, configurez Gradle et téléchargez votre propre bibliothèque sur l'entrepôt
Généralement, cela peut être fait pour les bibliothèques avec quelques fonctions de base, et une seule personne peut en assurer la maintenance
Utiliser onActivityResult n'est pas un problème, c'est ainsi que Bilibili gère la boxe Si vous ne voulez pas que l'appelant traite onActivityResult, vous pouvez écrire un intermédiaire Activity et après le traitement onActivityResult, transmettre le résultat via le rappel Transmettez-le à l'appelant ou personnalisez une caméra ;
Pour ce type de logique qui implique d'autres interfaces, j'écris généralement un module séparé. Lors de l'appel, j'utilise l'interface qui utilise une activité intermédiaire pour terminer la sélection/le traitement des images, et revient finalement via un rappel. . Vous n'avez même pas besoin d'écrire ces choses vous-même, il existe de nombreuses roues prêtes à l'emploi sur GitHub, il suffit de trouver un ImagePicker et de l'utiliser.
Merci à tous, cette réponse correspond essentiellement à ce que je voulais dire. Ma question n'est pas claire. Ma refactorisation n'est pas de créer un contrôle d'avatar universel. Ce que je veux, c'est mettre cette vue d'avatar dans la présentation de l'activité commerciale, et l'appelant n'a alors rien d'autre à faire. Quel réseau demande de mettre à jour l'avatar, de télécharger l'avatar, de sélectionner la photo... tout est encapsulé, au lieu de lui rappeler pour le gérer lui-même, car les interfaces liées à l'avatar de ces applications dans notre entreprise sont courantes
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Bien sûr, cette question concerne la commodité, mais le cadre actuel de l'application doit être pris en compte :
Utilisez les rappels comme mentionné ci-dessus. Mais notez que, comme les rappels sont référencés par des variables statiques, les rappels sont généralement des classes internes anonymes, ce qui peut provoquer des fuites de mémoire.
Utilisez le bus d'événements. Il implémente également la couche intermédiaire et transmet les résultats via le bus d'événements.
Recommandation :
.Puisqu'il s'agit d'un refactoring, vous pouvez envisager de permettre à tous les contrôles d'avoir pour fonction d'obtenir des résultats onActivityResult,
interface onActivityResult {
>
Les contrôles personnalisés qui doivent écouter les rappels implémentent cette interface. Dans BaseActivity, enregistrez ces contrôles et transmettez-les à ces contrôles lorsque les résultats sont renvoyés :
class BaseActivity {
>
Cela résout complètement le problème dont le contrôle a besoin pour obtenir le résultat de l'activité.
Ce qui précède est un code approximatif, mais il y a en fait d'autres considérations : le problème des requêtes répétées, toutes les vues doivent être enregistrées.
Gérez-le simplement sous la forme d'un auditeur.
Ce que vous avez dit ci-dessus est bon. Définissez une interface et utilisez les rappels d'interface pour le faire. Pour d'autres vues courantes, implémentez simplement cette interface.
Notre approche consiste à écrire la prise de photo et l'album photo en tant que module, puis à ajouter un événement de clic au composant qui définit l'avatar, à cliquer pour accéder à l'interface de traitement, puis à revenir. Le composant de configuration n'est pas inclus dans le module et est défini par l'utilisateur du module.
Une autre façon consiste à utiliser la surveillance des événements comme mentionné ci-dessus. Après avoir sélectionné la photo de l'album ou pris une photo pour confirmer la photo, déclenchez cet auditeur.
Je vous propose de demander à votre patron si vous êtes sûr d'écrire la Vue d'entrée dans le Module
Créez un entrepôt maven local et encapsulez les fonctions de contrôle, de fenêtre contextuelle et de saut. Ensuite, téléchargez-le directement dans l'entrepôt maven local, puis dépendez-en pour le projet via Gradle
Construisez l'entrepôt maven local, configurez Gradle et téléchargez votre propre bibliothèque sur l'entrepôt
Généralement, cela peut être fait pour les bibliothèques avec quelques fonctions de base, et une seule personne peut en assurer la maintenance
Utiliser
onActivityResultn'est pas un problème, c'est ainsi que Bilibili gère la boxeSi vous ne voulez pas que l'appelant traite
onActivityResult, vous pouvez écrire un intermédiaireActivityet après le traitementonActivityResult, transmettre le résultat via le rappel Transmettez-le à l'appelantou personnalisez une caméra ;
Pour ce type de logique qui implique d'autres interfaces, j'écris généralement un module séparé. Lors de l'appel, j'utilise l'interface qui utilise une activité intermédiaire pour terminer la sélection/le traitement des images, et revient finalement via un rappel. .
Vous n'avez même pas besoin d'écrire ces choses vous-même, il existe de nombreuses roues prêtes à l'emploi sur GitHub, il suffit de trouver un ImagePicker et de l'utiliser.
Merci à tous, cette réponse correspond essentiellement à ce que je voulais dire. Ma question n'est pas claire. Ma refactorisation n'est pas de créer un contrôle d'avatar universel. Ce que je veux, c'est mettre cette vue d'avatar dans la présentation de l'activité commerciale, et l'appelant n'a alors rien d'autre à faire. Quel réseau demande de mettre à jour l'avatar, de télécharger l'avatar, de sélectionner la photo... tout est encapsulé, au lieu de lui rappeler pour le gérer lui-même, car les interfaces liées à l'avatar de ces applications dans notre entreprise sont courantes