Dawno nic nowego nie napisałem, a to dlatego, że następny wpis miał być o refactoringu. Skoro ma być o refactoringu, to trzeba go zrobić. Noo i się zaczęło 😉 Ale po kolei.
Założenia wstępne były takie, że chcę dodać nadklasę, w której będą metody odpowiedzialne za rzeczy wspólne dla wszystkich aktywności. Noo właśnie, ale co to tak właściwie znaczy rzeczy wspólne? Wymyśliłem, że każda aktywność kończy się wypełnieniem ekranu i po kliknięciu uruchamia nową aktywność. Noo dobrze, ale ekran możemy wypełnić jednym lub drugim widokiem w zależności od tego, czy poprzednie zadanie zakończyło się sukcesem, czy porażką. I co wtedy, oddzielne metody, czy zmienna typu boolen w parametrze wywołania? Takich pytań nasuwa się setki, a nad odpowiedziami na niektóre naprawdę długo myślałem. Nawet takie rzeczy jak decyzja o nazwie metody, to wszystko dosyć mocno mnie przytłoczyło, dlatego też długo nie mogłem skończyć ani poprawek, ani tego wpisu. Ostatecznie jednak sądzę, że mi się udało i staram się nie dopuszczać do siebie myśli, że to mogło być zrobione inaczej 😉
Klasa nadrzędna przejęła całkiem sporo funkcji, np przy pomocy ButterKnife podpinam kilka rzeczy właśnie w klasie nadrzędnej:
@Bind(R.id.fab) FloatingActionButton fab; @Bind(R.id.layoutSuccess) ViewGroup layoutSuccess; @Bind(R.id.successView) ImageView successView; @Bind(R.id.layoutFailure) ViewGroup layoutFailure; @Bind(R.id.failureView) ImageView failureView;
Wymuszam też przeciążenie metody createViews(), aby w aktywności docelowej wywołać ją w metodzie onCreate. Dzięki temu nie muszę tych samych kawałków kodu pisać wszędzie, i mam kilka rzeczy załatwionych zaraz na starcie (np metoda calculateValues() ustawia wartości dla animacji circularReveal).
public void createViews() {
setNaviBarColor();
calculateValues();
ButterKnife.bind(this);
Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
assert getSupportActionBar() != null;
getSupportActionBar().setDisplayHomeAsUpEnabled(true);
}W tej klasie obsługuję też wypełnienie ekranu i cofnięcie tego wypełnienia, oraz start aktywności z przygotowaniem całej animacji etc.
Używam tego w ten sposób, że teraz moja metoda onCreate() wygląda tak:
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_compare);
createViews();
}
dyrektywa super w metodzie createViews() zapewnia mi wywołanie wszystkich uniwersalnych zadań, a ja mogę zająć się tym co jest istotne, czyli logiką.
Start nowej aktywności też zajmuje już tylko kilka linii:
@Override
@OnClick(R.id.successView)
public void onClickSuccessView() {
nextActivity(true, CompareActivity.this, CompareCheckActivity.class);
}
Podsumowując, próba zrobienia tego refactoringu całkiem sporo mi dała. Musiałem zadać sobie kilka pytań i uświadomić, czego jeszcze nie wiem. A wiedza o tym, czego się nie wie, to już całkiem sporo. Wiem, że jeszcze dużo muszę się nauczyć. I pewnie kiedyś jeszcze napiszę wpis o refactoringu, jak na razie wiem, że nic nie wiem 😉
Projekt na github, gdyby ktoś chciał obejrzeć zmiany, porównywać z 288370c
Pozdrawiam!