Autor Wątek: Android Java organizowanie kodu  (Przeczytany 1926 razy)

Offline TDM

  • Użytkownik

# Lipiec 17, 2012, 12:33:33
Witam!

Od niedawna mam styczność z Javą oraz Androidem, napisałem parę aplikacji ale pojęcia nie mam jak powinien wyglądać dobrze zorganizowany kod.
Załóżmy że mam klasę ListActivity jest t główna aktywność i co powinno a co nie powinno się znaleźć w tej klasie ? Wiadomo metody odpowiadające za zachowanie muszą być ( onCreate, onBackPressed itp ). Od czasu kiedy piszę w owej Javie jestem w szoku gdy w klasie aktywności mam klasę typu public class myArrayAdapter extends ArrayAdapter<myListItem> {
...
}
Coś takiego mogę zrobić nawet w instrukcji warunkowej przy tworzeniu DialogInterface.OnClickListener ale czy tak powinno być ? Czy może ładniej/lepiej jest utworzyć osobną klasę ? Co jak co ale robi się bałagan...

A jak z zmiennymi statycznymi przeznaczonymi tylko i wyłącznie do informacji/rozpoznawania jakiegoś zdarzenia ? W C++ używałem zwykłego #define, a tutaj ? Chodzi mi o używanie że został kliknięty jakiś przycisk czy coś zostało zaznaczone to żeby nie pracować na ID przycisku czy numerkach to miał bym coś takiego: static int ACTION_BUT = 0; Trzymać to w klasie ? czy wywalić poza nią ? I jakoś sensownie nazwać ?
Druga sprawa co jeżeli planuje mieć dwie aktywności typu ListActivity które maja pracować na tych samych danych ? Przy zmianie aktywności dane są gubione więc chyba lepiej mi stworzyć nową klasę zawierająca statyczne metody oraz zmienne i na nich pracować ? Ale czy to ładne rozwiązanie ?

Jak na chwilę obecną to tyle.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Xion

  • Redaktor
    • xion.log

# Lipiec 17, 2012, 12:49:01
Adapter zwykle jest dość dużą klasą więc nie definiowałbym jej inline w jakiejś funkcji, tylko na tym samym poziomie co metody ListActivity.

Stałe to w Javie statyczne zmienne finalne. Jeśli używane są tylko w jednej klasie i są jej szczegółem implementacyjnym, powinny być w niej zadeklarowane jako prywatne.

Cytuj
Druga sprawa co jeżeli planuje mieć dwie aktywności typu ListActivity które maja pracować na tych samych danych ?
Wyodrębnij adapter jako publiczną klasę i używaj jej w obu activity.

Offline m4tx

  • Użytkownik
    • m4txblog

# Lipiec 17, 2012, 13:50:51
Zamiast stałych mógłbyś używać enumów.

Nazwy klas w Javie rozpoczyna się dużą literą. Poczytaj sobie: Code Conventions for the Java Programming Language

Offline deadeye

  • Użytkownik

# Lipiec 17, 2012, 14:52:46
Zamiast stałych mógłbyś używać enumów.
Enumy w Androidowej maszynie wirtualnej są znacznie wolniejsze od stałych, więc autorzy odradzają ich używanie. Tak, wiem, sic.

Offline TDM

  • Użytkownik

# Lipiec 18, 2012, 00:45:38
Wyodrębnij adapter jako publiczną klasę i używaj jej w obu activity.
Chodziło mi o to że najpierw pierwsza aktywność "ładuje" jakieś dane potem odpalam drugą aktywność która pracuje na tych danych, i potem znowu pierwsza aktywność pracuje na tych danych.

Dobra a jak z DialogInterface.OnClickListener ? NIe ma jakieś innej możliwości utworzenia tego niż:DialogInterface.OnClickListener listener = new DialogInterface.OnClickListener() {
Chodzi mi o to żeby wyodrębnić to poza klasę aktywności żeby jej nie zaśmiecać....

@m4tx Dzięki wielkie, poczytam.

Offline Xion

  • Redaktor
    • xion.log

# Lipiec 18, 2012, 12:58:30
Chodziło mi o to że najpierw pierwsza aktywność "ładuje" jakieś dane potem odpalam drugą aktywność która pracuje na tych danych, i potem znowu pierwsza aktywność pracuje na tych danych.
Dane muszą być we wspólnym obiekcie, to chyba dość oczywiste.

Cytuj
Dobra a jak z DialogInterface.OnClickListener ? NIe ma jakieś innej możliwości utworzenia tego niż:DialogInterface.OnClickListener listener = new DialogInterface.OnClickListener() {
Chodzi mi o to żeby wyodrębnić to poza klasę aktywności żeby jej nie zaśmiecać....
Jak to "zaśmiecać"? Jeśli dialog jest częścią logiki danej activity, to ów listener jest także jej częścią. Dlaczego niby miałby być "śmieciem" do umieszczenia gdzie indziej?

Offline TDM

  • Użytkownik

# Lipiec 18, 2012, 13:09:48
Chodzi o to że nie mogę się przyzwyczaić do tego że mam pełno tego i tamtego w jednej klasie, myślałem żeby w aktywności trzymać tylko metody które odpowiadają za jej zachowanie. Dialog jest częścią logiki ale myślałem że ciało klasy: new DialogInterface.OnClickListener() { ... } warto jest wyciągnąć poza klasę aktywności, i trzymać w niej tylko obiekt a nie dodatkowo ciało.

Offline deadeye

  • Użytkownik

# Lipiec 18, 2012, 16:01:12
No to wyciągnij - jeśli dialog ma wystarczająco dużo logiki żeby było sens go wyciągać, to to zrób. Wszystko zależy od konkretnego przypadku.

Offline TDM

  • Użytkownik

# Lipiec 19, 2012, 12:56:32
No dobra a teraz zakładając że mam taką sytuację że z tego samego adaptera będą korzystać dwie aktywności typu ListActivity ale będą miały różne dane, i będą modyfikować sobie te dane tzn pierwsza aktywność będzie modyfikować dane drugiej. Czyli jak wiadomo adapter wyodrębnić jako osobną klasę, a z danymi adaptera dla drugiej aktywności ? Wydaje mi się że nie ma co się bawić w wysyłanie danych pomiędzy aktywnościami bo w tym wypadku mogę sobie bardzo utrudnić sprawę tylko lepiej chyba będzie stworzyć klasę/strukturę którą pierwsza aktywność będzie wypełniała/modyfikowała i przy starcie drugiej aktywności dopiero będę pakował dane do adaptera. Chyba dobrze myślę ?