188 finish();
189 }).addOnFailureListener(e -> {
190 progressBar.setVisibility(View.GONE);
191 Toast.makeText(this, e.getMessage(), Toast.LENGTH_SHORT).show();192 });
193 });
194 }
140 if(pet.getUrlImagem() != null){
141 pet.salvar();
142 }else{
143 Toast.makeText(this, "Selecione uma imagem para o pet.", Toast.LENGTH_SHORT).show();144 }
145 }
146
80
81 @Override
82 public void onPermissionDenied(List<String> deniedPermissions) {
83 Toast.makeText(FormAdicionarPet.this, "Permissão negada", Toast.LENGTH_SHORT).show(); 84 }
85 };
86
80
81 @Override
82 public void onPermissionDenied(List<String> deniedPermissions) {
83 Toast.makeText(FormAdicionarPet.this, "Permissão negada", Toast.LENGTH_SHORT).show(); 84 }
85 };
86
82 usuario.salvar();
83 atualizarReservas(nome,telefone);
84 progressBar.setVisibility(View.GONE);
85 Toast.makeText(this, "Perfil atualizado", Toast.LENGTH_SHORT).show(); 86 }else {
87 edit_telefone.requestFocus();
88 edit_telefone.setError("Informe seu número de telefone.");
Methods show()
, setVisible()
, and pack()
must not be invoked on the main thread.
With each invocation, these methods create the peer for the associated JFrame
. Creation of the peer involves creation of the event dispatch thread.
At this point, the event dispatch thread could be in the middle of notifying listeners while show()
, setVisible()
, or pack()
is still executing.
As a result, we could have two threads going through the Swing component-based GUI at the same time, which is a serious issue that might lead to deadlocks or other multithreading bugs.
public void method() {
// These are problematic.
frame.show();
frame.setVisible(true);
frame.pack();
}
Consider calling these methods on the event dispatch thread.
public void method() {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
frame.show();
frame.setVisible(true);
frame.pack();
}
}
}