Discussion :

[clem_alain]

Bonjour,
Je fais face à un problème qui me laisse perplexe.
Lorsque j'appelle l'API pour me fournir la liste des employées lors du premier lancement de l'activité, donc lors onResume() faisant suite au onCreate() tout se passe bien, j'ai bien la bonne liste. Par contre lorsque après modification d'un employé je rappelle la liste en exécutant exactement le même code, mais sans passer par le onCreate(), mais uniquement par le onResume() la liste n'est pas rafraîchie !
Si j'introduit une temporisation que ce soit côté serveur via un simple Log::info("Liste"); ou côté client via une tempo TimeUnit.SECONDS.sleep(1); la liste est correctement rafraîchie et quand je dis rafraîchie je parle bien des données pas seulement de l'affichage à l'écran. le code d'appel est tout ce qu'il y a plus de standard comme vous pouvez le constater ci-dessous :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
            Callback<List<Employee>> cble = new Callback<List<Employee>>() {
                @Override
                public void onResponse(Call<List<Employee>> call, Response<List<Employee>> response) {
                    if (response.isSuccessful()) {
                        if (response.body() != null) {
                            employees = response.body();
                            afficherListe();
                        }
                    } else {
                        String msg = response.errorBody().source().toString();
                        Toast.makeText(EmployeesActivity.this, msg, Toast.LENGTH_LONG).show();
                    }
                }

Ci dessous le code de la modification de l'employé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
                public void onResponse(Call<Employee> call, Response<Employee> response) {
                    if(response.isSuccessful()){
                        if (response.body() != null){
                            Toast.makeText(EmployeeActivity.this, "Employé modifié.", Toast.LENGTH_LONG).show();
                            finish();
                        }
                    }else {
                        String msg = response.errorBody().source().toString();
                        Toast.makeText(EmployeeActivity.this, msg, Toast.LENGTH_LONG).show();
                    }
                }

Pour mon malheur si je mets des points d'arrêt, le problème disparaît, c'est d'ailleurs ce qui m'a incité à mettre une temporisation !
J'ai essayé de mettre systématiquement la List employees = null; avant tout appel, rien de changé. J'ai essayé aussi de mettre le cache à null dans le client Retrofit, mais sans succès. Le pire dans l'affaire c'est que via les log côté serveur j'ai bien constaté que les appels se faisaient bien. je vais essayer de trouver une deuxième machine pour y installer l'API et faire des capure avec WireShark, mais pour le moment je n'en ai pas, donc si quelqu'un pouvait me donner une piste, cela m'aiderait.
Merci d'avance.

[clem_alain]

Bonjour,
Finalement j'ai fini par trouver et ce grâce à WireShark qui m'a permis de bien voir le dialogue HTTP entre l'application Android et le service Web.
Quand je mets à jour un employé, le service web me retourne cet employé, ce qui est le standard. Sauf que dans mon code je ne récupérais pas le jSon retourné, je me contentais d'envoyer un Toast pour dire que tout était OK et ensuite je quittais l'activité pour retourner à l'activité appelante et redemander la liste des employés. Le problème c'est que je ne captais pas le retour de la liste mais celui de la mise à jour de l'employé ! Normalement j'aurais dû récupérer le jSon de l'employé modifié, le transmettre à l'activité appelante, dans l'activité appelante rechercher cet employé dans la collection ds employés et lui substituer les nouvelles valeurs. Cela m'a paru bien trop lourd et du coup la "rustine" qui consistait à mettre une tempo histoire de laisser passer le retour de l'employé modifié et après de relancer une demande de liste complète des employés, cette rustine donc m'a paru bien plus simple et efficace, même si en termes de consommation de bande passante ce n'est pas vraiment top :-(
Au passage, cela soulève une question, dans la communication asynchrone comment être sûr de savoir que l'on récupère bien le résultat de l'appel que l'on a effectué. Imaginons par exemple qu'on lance trois demandes à une API comment savoir que le premier retour que l'on capte est bien la réponse à la première demande, le deuxième retour à la deuxième demande et ainsi de suite ?
Si certains ont des pistes de réponse je serais bien preneur :-)