Lors de la création d'une application native sur Android ou iOS, je pense que la plupart du temps, elle communique avec une sorte de serveur via API. Cependant, si vous ne gérez pas correctement les données de l'API, Il plante ou est considéré comme une application instable qui fonctionne étrangement. Cette fois, nous allons résumer les plantages / dysfonctionnements que nous avons rencontrés jusqu'à présent et introduire des mesures pour les empêcher de planter.
Le serveur ne renvoie pas toujours 200 (système normal). Si vous envoyez une demande frauduleuse, elle retournera 404 ou 422, Si le serveur est sur-accédé et en panne, il renverra une erreur. Il ne renvoie rien et peut expirer.
À ce moment-là, si la considération de «que faire si une valeur d'erreur est renvoyée» est omise, elle peut tomber en raison d'une erreur d'analyse, ou diverses valeurs peuvent commencer à se déplacer dans l'état de valeur nulle ou initiale, conduisant à un fonctionnement anormal.
Veillez à ajouter la gestion des erreurs lorsqu'une erreur de série 400 ou 500 est renvoyée. De plus, si l'analyse échoue, elle sera traitée comme une erreur et l'utilisateur sera averti qu'il y a une erreur de communication.
--Crash car la valeur de 〇〇 n'est pas dans les anciennes informations utilisateur ――La valeur de 〇〇 était toujours présente au moment de l'implémentation, mais il fut un temps où ce n'était pas une réparation côté serveur et ça plantait.
Lors du choix des spécifications avec le développeur côté serveur Il se peut que l'on vous dise: "Cette valeur n'existe pas lorsqu'elle est nulle, vous n'avez donc pas besoin de vérifier la valeur null." Ne croyez pas ces mots. La personne n'a pas toujours une compréhension complète des spécifications des données, ** Ce n'est peut-être pas la personne qui réparera la pièce plus tard **
Puisque nous ne savons pas quand null sera renvoyé, toutes les classes de données qui reçoivent la réponse doivent être Nullable et String.
UserApiData.kt
data class UserApiData(
val id : String?,
val name : String?,
val age : String?,
val birthDay : String?
)
(Écrit en Kotlin)
Cependant, si vous le faites, vous devrez effectuer une vérification Null et une conversion de type à chaque fois que vous l'utiliserez dans l'application, et le code deviendra très compliqué. pour cette raison, ① Classe de données qui reçoit la réponse ② Classe de données utilisée dans l'application Créez-en deux et créez une méthode de conversion qui crée ① en ②.
User.kt
data class User(
val id : String,
val name : String,
val age : Int,
val birthDay : Date
)
UserConverter.kt
class UserConverter(){
fun convert(data: UserApiData): User {
if (data.id == null) throw IllegalArgumentException("user_id is null")
return User(
data.id,
data.name ?: "",
data.age?.toIntOrNull() ?: 0,
parseData(data.birthDay)
)
}
}
Dans cette méthode de conversion, la vérification Null est effectuée et la valeur est entrée sous la forme NonNull. Si vous êtes coincé dans le contrôle nul
Selon le cas, nous utiliserons la correspondance telle que. Ensuite, vous pouvez ** effectuer une vérification Null en un seul endroit tout en recevant correctement la réponse du serveur **.
--La boîte de dialogue qui s'affiche uniquement lorsque false est toujours affichée. --Processus qui ne sont toujours exécutés que lorsque l'état de l'utilisateur est 0
Cela conduit à un bug lors de la définition des exigences. En Java, int et boolean sont initialement définis sur 0 et false, respectivement, et ne sont pas nuls. Il est implémenté en supposant qu'une valeur différente de 0 provient de l'api, et si la valeur ne vient pas, le processus sera exécuté avec 0 tel quel.
Vous pouvez le définir sur String de la même manière que ↑, ou vous pouvez le recevoir avec la classe wrapper Int, Boolean au lieu du type primitif int, boolean.
Si vous le faites, la valeur initiale sera nulle, donc si la valeur initiale ne change pas involontairement, un plantage ou une erreur se produira au lieu d'une opération illégale.
Je veux également éviter les plantages / erreurs, mais c'est encore mieux car il est inclus dans Crashlytics et est plus facile à détecter lors des tests.
En fait, certaines mesures ne peuvent pas être prises en ajustant le temps de montage et les spécifications, mais je pense que ce serait bien si nous pouvions prendre des mesures autant que possible pour créer une application stable.
Recommended Posts