Właściwie powinienem napisać to już dawno temu. W związku z tym, że jestem na etapie pisania pracy dyplomowej, a uznał, że najlepszy do mojego tematu będzie język PHP, tak jak to już widać zresztą od dłuższego czasu, zawieszam swoją działalność blogową.

Jeśli ktoś z odwiedzających miałby jakiś problem, na który nie może znaleźć odpowiedzi na forum, może pisać na mejla, jeśli tylko znajdę czas z chęcią pomogę, żeby trochę oderwać się od PHP no i nie tracić całkowicie kontaktu z Java, bo sam na pisanie czegoś ciekawego nie mam po prostu czasu.

Pozdrawiam

…no i wróciłem z wygnania za chlebem, stając od razu przed kampanią wrześniową w szkole (czytaj ukończeniem piekielnego projektu), który stwierdzam teraz jest trochę bezsensowny, bo zaprzęganie Java do tworzenie zwykłej aplikacji desktop-owej mija się trochę z celem, chciałbym zacząć powoli bawić się w coś bardziej związanego z ideą Java, ale jak mus to mus, trzeba walczyć…

Pozdrawiam wszystkich dotychczas oceniających moje notki, za wszelkie uwagi jestem bardzo wdzięczny.

Mamy okres wakacyjny, dla wielu w tym i mnie jest to czas wyjazdów do pracy, aby zarobić trochę pieniążków na chleb (czyt. kolejny rok studiów, itd.). Pomimo tego, że czasu nie mam za wiele, postanowiłem napisać cokolwiek, żeby blog nie był taki martwy. Temat dzisiejszej rozkminy prosty, ale na pewno przyda się początkującym adeptom Java którzy podobnie jak ja jeszcze nie dawno, staną w pewnym momencie do walki o ujarzmienie JTable.

Z moich obserwacji wynika, że kłopoty z prawidłową obsługą tabeli ma duża część początkujących. Zwykle wybierana przez nich droga rozwiązania nie jest najlepsza i kończy się dużą ilością kompletnie nie potrzebnego kodu, koszmarnego w utrzymaniu, zwłaszcza jeśli w programie mamy wiele różnych tabel. Wydaje mi się, że wynika to przede wszystkim z faktu nie znajomości wzorców projektów, szczególnie MVC, z którego to biblioteka Swing czerpie pełnymi garściami, gdzie nawet najmniejszy JButton jest przykładem tego wzorca.

Ale do rzeczy, model dla JTable jest implementacją interfejsu TableModel, programiści API wyręczyli nas z bezpośredniej implementacji tego interfejsu, tworząc jego szkieletową implementację AbstractTableModel, dzięki czemu odpada nam dużo roboty.

Przykład, model tabeli operujący na obiektach klasy Person:

public class PersonTableModel extends AbstractTableModel {

    private List<Person> persons = null;
    private final static Object[] columnNames = {"", "Imię", "Nazwisko", "Płeć",
        "Ulica","Nr. d/m", "Miasto", "Kod pocztowy", "Województwo",
        "Tel. kom", "Tel. dom", "Email"};

    private final static int HIDDEN_IDX = 0;
    private final static int NAME_IDX = 1;
    private final static int SURNAME_IDX = 2;
    private final static int GENDER_IDX = 3;
    private final static int STREET_IDX = 4;
    private final static int APARTMENT_IDX = 5;
    private final static int CITY_IDX = 6;
    private final static int ZIPCODE_IDX = 7;
    private final static int PROVINCE_IDX = 8;
    private final static int CELL_IDX = 9;
    private final static int PHONE_IDX = 10;
    private final static int EMAIL_IDX = 11;

    public PersonTableModel() {}

    @Override
    public int getRowCount() {
        if(persons==null) return 0;
        return persons.size();
    }

    @Override
    public int getColumnCount() {
        return columnNames.length;
    }

    @Override
    public Object getValueAt(int rowIndex, int columnIndex) {

        if(persons == null) return null;
        Person p = (Person) persons.get(rowIndex);
        switch (columnIndex) {
            case HIDDEN_IDX:
                return p.getId();
            case NAME_IDX:
                return p.getName();
            case SURNAME_IDX:
                return p.getSurname();
            case GENDER_IDX:
                return p.getGender().toString();
            case STREET_IDX:
                return p.getStreet();
            case APARTMENT_IDX:
                return p.getApartment();
            case CITY_IDX:
                return p.getCity();
            case ZIPCODE_IDX:
                return p.getZipCode();
            case PROVINCE_IDX:
                return p.getProvince().toString();
            case CELL_IDX:
                return p.getCellNumber();
            case PHONE_IDX:
                return p.getPhoneNumber();
            case EMAIL_IDX:
                return p.getEmail();
            default:
                return p;
        }
    }

    @Override
    public String getColumnName(int column) {
        return columnNames[column].toString();
    }

    @Override
    public boolean isCellEditable(int row, int column) {
        return false;
    }

    public void setModelData(List<Person> persons) {
       this.persons =  persons;
    }
    public Person getPerson(int position) {
        return persons.get(position);
    }

}

Aby stworzyć model o podstawowej funkcjonalności wystarczy zaimplementować 3 metody abstrakcyjne:

• public int getRowCount() – zwracającą liczbę wierszy w tabeli
• public int getColumnCount() – analogicznie liczbę kolumn
• public Object getValueAt(int rowIndex, int columnIndex) – zwracają wartość o podanych współrzędnych

Bardzo często w modelu dodaję się obsługę nagłówka tabeli, zwłaszcza jeśli mamy pewność, że liczba kolumn w tabeli nie będzie się zmieniać, wtedy należy przesłonić metodę public String getColumnName(int column), a jeśli chcemy zablokować możliwość edycji komórek tabeli przeciążamy metodę public boolean isCellEditable(int row, int column)
Jak widać model tabeli przechowuje referencję do kolekcji obiektów Person, gdy stan tej listy zmieni się wystarczy wywołać metodę fireTableDataChanged(), aby odświeżyć stan tabeli.

I to już wszystko, jak widać nie takie to straszne, więcej przydatnych informacji przechowuje skarbonka wiedzy suna: JTable Tutorial.

Wszyscy znamy opcję reset spotykaną chociażby w zwykłych formularzach html. Na pierwszy rzut oka z kodzenie takiej funkcjonalności w aplikacji okienkowej wydaje się banalnie proste, bierzemy wszystkie komponenty typu JTextComponent, lub jeszcze inne, wkładamy je do kolekcji i w odpowiedniej metodzie, przywracamy pierwotny stan kontrolek (np. setText(null);).

I co wszystko jest tip top? Otóż mamy zonka połamaliśmy co najmniej kilka z podstawowych zasad programowania obiektowego z SRP i DRY na czele. Czyli ogólnie wszystko jest do dupy. Wystarczy pomyśleć co by było w przypadku 10 różnych formularzy w aplikacji, a pasuje każdemu dodać taką funkcjonalność. Ile zbędnych, koszmarnych w utrzymaniu linii kodu nabazgrzemy?

Postanowiłem pobawić się w małą, nie doskonałą jeszcze, ale jednak refaktoryzację…
W standardowej bibliotece Java mamy bardzo przyjemny interfejs ContainerListener i nim właśnie zamierzam się posłużyć, powołując do życia interfejs ContainerClearer.

package view;
import java.awt.event.ContainerListener;

public interface ContainerClearer extends ContainerListener {

   void clearComponents();

}

Mając już podstawę na potrzeby klas konkretnych, pasuje skodzić jakąś implementację.

package view;

import java.awt.Component;
import java.awt.event.ContainerEvent;
import java.util.*;
import javax.swing.*;

public class SimpleFormClearer implements ContainerClearer {

    private List<Component> components;

    public SimpleFormClearer() {
        components = new ArrayList<Component>();
    }

    public void clearComponents() {
        for(Component c : components) {
            if (c instanceof JTextComponent)
                ((JTextComponent)c).setText(null);
            if (c instanceof JComboBox)
                ((JComboBox)c).setSelectedItem(null);
        }
    }

    public void componentAdded(ContainerEvent e) {
        components.add(e.getChild());
    }

    public void componentRemoved(ContainerEvent e) {
        components.remove(e.getChild());
    }

}

W celu zmniejszenie ilości kodu, można posunąć się jeszcze dalej, tworząc klasę abstrakcyjną i zaimplementować w niej interfejs ContainerClearer, jak to jest często wykorzystywane w standardowych bibliotekach Java (Abstract + nazwa interfejsu)

public abstract class AbstractContainerClearer implements ContainerClearer {

    protected java.util.List<Component> components;

    public AbstractContainerClearer() {
        components = new java.util.ArrayList<Component>();
    }

    abstract public void clearComponents();

    public void componentAdded(ContainerEvent e) {
        components.add(e.getChild());
        addClearerToChildContainer(e.getChild());
    }

    public void componentRemoved(ContainerEvent e) {
        components.remove(e.getChild());
        addClearerToChildContainer(e.getChild());
    }

    protected void addClearerToChildContainer(Component c) {

        if (c instanceof Container) {

            Container cont = (Container) c;
            cont.addContainerListener(this);

            Component[] children = cont.getComponents();

            for (int i = 0; i < children.length; i++) {
                addClearerToChildContainer(children[i]);
            }
        }
    }
}

Dzięki temu, że jest to klasa abstrakcyjna nie musimy implementować w niej metod narzucanych przez interfejs, dorzucamy abstract i wszystko śmiga. Powyższy zabieg uświadomił mi jeszcze jedną ważną kwestią, otóż aby klasa SimpleFormClearer działała poprawnie chociażby w okienku dialogowym zawierającym wiele zagnieżdżonych paneli musielibyśmy dodawać go do każdego panela, co w przypadku bardziej rozbudowanego GUI staje się dość wkurzające. Metoda addClearerToChildContainer rozwiązuje ten problem, a implementacja tej klasy staję się znacznie bardziej przejrzysta:

public class BasicFormClearer extends AbstractContainerClearer {

    @Override
    public void clearComponents() {
        for(Component c : components) {
            if (c instanceof JTextComponent)
                ((JTextComponent)c).setText(null);
            if (c instanceof JComboBox)
                ((JComboBox)c).setSelectedItem(null);
        }
    }
}

Teraz wystarczy dodać go do kontenera najwyższego poziomu:

getContentPane().addContainerListener(new BasicFormClearer());

i po sprawie…

Zalety: dużo prościej, ładniej i przejrzyście, tworząc kilka klas konkretnych można jeszcze pokusić, a nawet należy dodać odpowiednią fabrykę.
Wady: na pierwszy rzut oka widać że kod metody clearComponents() nie jest doskonały (OCP, rzutowanie), mi jak na razie nie przychodzi lepsze rozwiązanie, może ktoś przedstawi jakąś sugestię?

W każdym razie i tak jest dużo lepiej, warto zaglądać do dokumentacji w poszukiwaniu przydatnych narzędzi i zawsze należy dążyć do uzyskania jak największej jakości kodu.

Postanowiłem oderwać się od swojej piekielnej potyczki z wyrażeniami regularnymi i napisać coś w końcu zgodnego z tytułem blogu. Temat na początek łatwy, ale od czegoś trzeba zacząć, a dokładnie wykonywanie długotrwałych procesów programu za pomocą klasy SwingWorker
Postanowiłem o tym napisać bo sam dosyć często lekceważyłem tę kwestię i jakoś nie przeszkadzało mi kilku-sekundowe przywieszenie się UI podczas np. łączenia z bazą danych w prostych programikach na zaliczenia. W końcu stało się to bardzo wkurzające i jest to po prostu duży przypał jeśli widzi się takie działanie programu. Drugim powodem było to, że nie tak wiele osób umie prawidłowo korzystać ze “świątyni wszechwiedzy” Google, widziałem nawet jak nie którzy sami próbowali implementować “ciężkie” zadania zrzucając je na własne wątki, czyli prostować poziomicę.

Co do tych ciężkich procesów, to ogólna zasada mówi że każde zadanie ktorego czas trwania moze spowodowac zauwazalne ‘zamrozenie’ interfejsu uzytkownika, nie powinno być wykonywane w wątku operującym GUI. Do takich długotrwałych procesów zalicza się m.in:

• Łączenie z bazą danych oraz operacje na bazie danych
• Wczytywanie dużych plików np. (jpg-ów) (ogólnie operacji IO)
• Długotrwałych obliczeń (np.operacji morphingu)
• Odświeżanie dużych tabel

W Java wątek odpowiadający za obsługę GUI zwie się Event Dispatch Thread (jakby ktoś nie wiedział;)), czyli po prostu EDT. Jak sama nazwa mówi zajmuję się on obsługą kolejki zdarzeń i informowaniem o nich obiektów nasłuchujących (czyt. z reguły ActionListener-ów), dodatkowo zarządza rozłożeniem komponentów, ich wyświetleniem, zmianą właściwości komponentów (np. dezaktywacja przycisku) i obsługą zadań. Zadaniami tymi powinny być tylko i wyłącznie krótkotrwałe procesy. Niektórzy myślą że to…:

public static void main(String[] args) {

    SwingUtilities.invokeLater(new Runnable(){
        @Override
        public void run() {
            JFrame f = new JFrame();
            f.setSize(200,200);
            f.setVisible(true);
        }
    });
    }
}

lub

public static void main(String[] args) {

    EventQueue.invokeLater(new Runnable(){
        @Override
        public void run() {
            JFrame f = new JFrame();
            f.setSize(200,200);
            f.setVisible(true);
        }
    });
    }
}

…załatwia sprawę, ale to dopiero początek, każda nie banalna aplikacja powinna odpalać GUI w EDT za pomocą powyższych technik (pierwsza jest ciut mniej pracochłonna, ponieważ wystarczy zaimportować tylko pakiet javax.swing.*;), ale jak zwał tak zwał wszystko to jeden ciul ważne że mamy prawidłowo zainicjalizowane GUI i jak na razie wszystko jest wporządku .

Teraz potrzebujemy obsługi długotrwałych zadań, która nasza spłodzona w pocie czoła aplikacja ma wykonywać.
Pierwszy krok…
…a jakże ulubiona dokumentacja

Rozkminimy sobie co ten wspaniały produkt programistów Sun-a ma nam do zaoferowania.
Pierwsze co rzuca się w oczy to deklaracja klasy:

public abstract class SwingWorker<T,V> extends Object
implements RunnableFuture

Jak widać SwingWorker to klasa abstrakcyjna, czyli możemy utworzyć obiekt tylko i wyłącznie klasy po niej dziedziczącej. Drugą rzeczą rzucającą się w oczy są parametry T i V, tak SwingWorker czerpie pełnymi z garściami z dobrodziejstw typów uogólnionych dodanych w Java 1.5. Implementowany interfejs jest połączeniem interfejsów Runnable i Future (z niego właśnie pochodzi metoda get() zwracająca rezulat obliczeń).
Parametr T – określa typ zwracany przez metody doInBackground() i get() o których później. Jest to po prostu rezultat naszego zadania np. obrazek.
Parametr V – określa typ danych pośrednich, które może produkować zadanie, przykładowo linie tekstu z wczytywanego pliku. Dane te można wyłuskać za pomocą metody process(List dane), a które przekazuje do niej metoda publish(V... dane), która powinna być używana w implementacji metody doInBackground() .
Uwaga!
Aby metody zwracały typ void (a dokładniej żadnego konkretnego typu), bo taką możliwość naturalnie też mamy, w deklaracji klasy należy podstawić parametr Void.

Użyteczne metody klasy SwingWorker:

• abstract protected doInBackground()

  Zaimplementowanie tej metody najbardziej nas interesuje, ba, nawet musimy to zrobić ponieważ jest to metoda abstrakcyjna. To w niej powinniśmy dostarczyć zadanie do wykonania. Jeśli przesłonimy także metodę process(List dane), możemy przy pomocy publish(V... dane) przekazywać do process(List dane) cząstkowe wyniki działania zadania.

• protected process(List dane)

  Dzięki tej metodzie możemy operować na pośrednich danych zwróconych przez publish(V... dane). W tej metodzie możemy bezpiecznie operować na komponentach graficznych, np. dodawać linijki tekstu to JTextArea, ponieważ działa ona asynchronicznie w EDT.

• protected void publish(V... chunks)

  Metoda ta przesyła szczątkowe dane metodzie protected process(List dane), nie ma potrzeby jej przesłaniania, ale można to zrobić w przypadku gdy np. chcemy wykonać jakieś extra operację na dostarczanych danych.

• protected void done()

  Metoda wywoływana po zakończeniu zadania, wykonywana w EDT, można w niej przeprowadzić sprzątania i zaprezentować w GUI główny rezultat wykonywanego zadania, czyli pobrać rezultat działania doInBackground() przy pomocy metody get().

To nie wszystkie ciekawe rzeczy związane ze SwingWorker-em, polecam zaglądnięcie do dokumentacji, jest to bardzo dobrze udokumentowana klasa.

A teraz kodzik prostego przykładu, pełny program można pobrać stąd.

button.addActionListener(new ActionListener(){
           public void actionPerformed(ActionEvent e) {
               SwingWorker<Icon, Void> worker = new SwingWorker<Icon, Void>(){

                    @Override
                    protected Icon doInBackground() throws Exception {
                        progressBar.setIndeterminate(true);
                        return loadImage(textField.getText());
                    }

                    @Override
                    protected void done() {
                        try {
                            imageLabel.setIcon(get());
                            progressBar.setIndeterminate(false);
                        } catch (Exception ex) {
                            ex.printStackTrace();
                        }
                    }

               };
               worker.execute();
           }
        });

Dla ułatwienia jak widać posłużyłem się klasą anonimową, tutaj ktoś może się zastanowić dlaczego za każdym razem tworzę nowy obiekt, a to dlatego, że nie ma możliwości powtórnego wykorzystania obiektu tego typu.
I na tym kończę ten arcik, mam nadzieję że nie popełniłem żadnych byków i polecam wszystkim nie stosującym do tej pory, specjalnie przeznaczonego do wykonywania długich zadań SwingWorker-a.

]]>