Пытаюсь реорганизовать еще лучше

Question

Я переработал checkLogin(), который живет в классе LoginActivity, но я все еще думаю, что его можно реорганизовать еще лучше.

private void checkLogin(final String email, final String password) { 
    // Tag used to cancel the request 
    String tag_string_req = "req_login"; 

    pDialog.setMessage("Logging in ..."); 
    showDialog(); 

    LoginRequest loginRequest = new LoginRequest(Request.Method.POST, AppConfig.getUrlLogin(), ReqSuccessListener(), ReqErrorListener()) { 

     protected Map<String, String> getParams() { 
      // Posting parameters to login url 
      Map<String, String> params = new HashMap<String, String>(); 
      params.put("email", email); 
      params.put("password", password); 
      return params; 
     } 
    }; 
    // Adding request to request queue 
    AppController.getInstance().addToRequestQueue(loginRequest, tag_string_req); 
} 

Реализация ReqSuccessListener() и ReqErrorListener() также живет в LoginActivity классе. Что выглядит так:

private Response.Listener<String> ReqSuccessListener() { 
    return new Response.Listener<String>() { 
     @Override 
     public void onResponse(String response) { 
      Log.d(TAG, "Login Response: " + response.toString()); 
      hideDialog(); 
      try { 
       session.setLogin(true); 
       JSONObject jObj = new JSONObject(response); 
       JSONObject user = jObj.getJSONObject("user"); 
       String uid = user.getString("id"); 
       String name = user.getString("name"); 
       String email = user.getString("email"); 

       // Inserting row in users table 
       db.addUser(name, email, uid); 

       // Launch main activity 
       Intent intent = new Intent(LoginActivity.this, MainActivity.class); 
       startActivity(intent); 
       finish(); 
      } catch (JSONException e) { 
       // JSON error 
       Toast.makeText(getApplicationContext(), "Json error: " + e.getMessage(), Toast.LENGTH_LONG).show(); 
      } 
     } 
    }; 
} 

private Response.ErrorListener ReqErrorListener() { 
    return new Response.ErrorListener() { 
     @Override 
     public void onErrorResponse(VolleyError error) { 
      int statusCode = error.networkResponse.statusCode; 
      NetworkResponse response = error.networkResponse; 
      Log.d("testerror", "" + statusCode + " " + new String(response.data)); 
      if (statusCode != 200) { 
       Toast.makeText(getApplicationContext(), new String(response.data), Toast.LENGTH_LONG).show(); 
       hideDialog(); 
      } 
     } 
    }; 
} 

Мой вопрос простой, как я могу реорганизовать это еще лучше? Или я уже переработал его достаточно хорошо?

Также здесь моя ссылка, чтобы показать вам, как выглядит код до и после того, как я его обработал. Вот ссылка, если вы хотите ее увидеть: https://github.com/superzaky/Kenzup/compare/3b30426bc02873607806525d62d2744921481cd5...command-loginrequest

Итак, на левой стороне находится код перед рефакторингом, а с правой стороны - код после рефакторинга.

Answer 1

Отличная работа, вы почти у цели. Но ваш код может быть «чистым»

«Чистый код» совсем не субъективен, его можно легко определить. После это сделает ваш код блеск -

• SOLID
• Testablity.
• Читаемость.
• Структурирование (сплоченность).

Читаемость очень важна, но и очень обширная тема, поэтому я не буду ее обсуждать, а скорее рекомендую вам прочитать об этом. Такие вещи, как fluent API, делают код более понятным и поддерживаемым. И я рекомендую книгу дяди Боба Clean code.

Несколько вещей, которые я узнал будучи Android разработчик -

класс активности Андроида по (вероятно, отсутствием) дизайн делает все виды и слишком много вещей, уже, к сожалению, нет никакого спасения, мы должны наследовать от него , Но это не означает, что нужно добавить к нему больше обязанностей и сделать код более жестким.

Не обманывайтесь сайтом разработчиков Android и многими блогами и сайтами. Когда они используют решение, они не беспокоят себя разделением проблем. Естественно, они просто хотят раскрывать технику, а не «чистое» решение (что несколько понятно).

Имея менталитет написания проверяемого кода, необязательные письменные тесты сделают ваш дизайн намного лучше. Лично я считаю, что тесты необходимы, но я понимаю, почему многие разработчики Android не пишут их. Отсутствие хорошей и быстрой структуры тестирования в долгосрочной перспективе Android-каркаса делает очень неудобным, чтобы иметь лучшие практики. Но это не должно мешать кому-либо писать тестовый код! Тестируемый код лучше код

В коде -

1. Иметь четкое определение того, что вы хотите, чтобы ваш класс активности делать. Естественной вещью будет Контроллер или Ведущий. Как только вы это сделаете, у вас есть , он делает это и ничего больше. Стремитесь сделать его очень тонким.
2. Имейте слой абстракции над вашими бизнес-правилами. Очень вероятно, что некоторые правила будут соблюдаться до выполнения запросов. Может быть, не так много в логине, но, как правило, это делает вещи более удобными, проверяемыми и расширяемыми. Например, вы можете теперь «макет» процесса входа в систему, чтобы протестировать пользовательский интерфейс.
3. Имейте абстракцию над вашими транспортными уровнями, которые будут вызываться исключительно бизнес-слоем. Опять же, это делает вещи более удобными, проверяемыми и расширяемыми. Например, вы можете теперь высмеять транспортный уровень, чтобы вернуть предопределенный ответ.