Jak poprawnie zaprogramować aplikacje z okienkami?

0

Planuję zrobić aplikację która będzie miała ~ 10 okienek. Chciałbym móc zrobić to w ten sposób że z jednego okienka można "przejść" do innego. Tj klikam "Next", poprzednie okienko znika, pojawia się nowe.

Nie wiem tylko jak przekazywać informacje z jednego okna do drugiego. Np skąd okno1 ma wiedzieć co wcześniej użytkownik wpisał w jTextField w okno2.

Jedyny pomysł jaki mam to zrobienie jakiejś klasy statycznej i przy każdej zmianie okna (ukryciu aktualnego i pokazaniu nowego) zapisywać wszystkie rzeczy tam, ale to nie wydaje mi się dobrym rozwiązaniem

Nie wiem jak też pokazywać odpowiednie okna. Chciałbym np z okna1,okna2,okna3 móc pokazać pozostałe przyciskiem. Czy te wszystkie okna powinny być dziećmi jakiejś wspólnej klasy?

Pamiętam że w ide od borland (Delphi/c++ builder) każde okno z osobnych unitów wystarczyło zaincludować unit ii można było sobie wszystkie informacje z poprzedniej formy pobrać.

Jak to się robi w większych firmach. Tj jak takimi oknami się zarządza?

1

Nie ma znaczenia ile będzie okienek i jak wywoływane. Okienka zasadniczo mają tylko wyświetlać Twój model danych w pamięci. I warto pamiętać, że tylko to mają robić. W przypadku okien, które mają być od siebie niezależne ich rodzicem ma być null. W przypadku okien zależnych takich jak np. okna dialogowe ich rodzicem powinno być okno wywołujące. Wtedy dopóki okna potomnego nie zamkniesz nie będziesz miał dostępu do okna rodzica. I jest to sensowne bo okno typu child odpala się właśnie dlatego, żeby zablokować dostęp do okna rodzica.
Również w drugą stronę wszelkie informacje z okna mają lecieć do modelu, a nie do żadnego kolejnego okna. Inaczej będziesz mieć totalny bajzel.
Dzisiaj oknami zarządza się tak jak każdym innym typem danych bo informacja o oknie - czy jest zadokowane i gdzie - jest taką samą informacją jak każda inna. Dlatego ją też czasem zapisuje się (poprzez serwer) w bazie danych.

Mylić mogą tylko niektóre operacje takie jak przeciąganie i dokowanie okien. Na przykład wydokowanie okna i przerzucenie go na drugi ekran składa się z trzech operacji:

  1. Wypięcia z okna typu child z okna swojego rodzica i usunięcia go (potomka) bo jest to okno, które pracuje tylko wewnętrznie w kontenerze, którym jest okno rodzica,
  2. Przeciągnięcie obrazka (mapy bitowej) stworzonego z dotychczasowego widoku zadokowanego okna,
  3. W miejscu puszczenia kursora myszy utworzenie okna typu top (bez rodzica).
    I podobnie w odwrotną stronę.

Pamiętaj, że okna to tylko narzędzie prezentacji. Nic więcej. Twoje dane siedzą w modelu.

Nie wiem tylko jak przekazywać informacje z jednego okna do drugiego. Np skąd okno1 ma wiedzieć co wcześniej użytkownik wpisał w jTextField w okno2.

Okno2 ma sobie zpisać do modelu, a okno1 powinno wtedy nasłuchiwać za pomocą jakiegoś changelistenera czy dane w modelu zmieniły się. A jeżeli tak, to dostanie wywołanie i dzięki temu w obsłudze zaktualizujesz sobie odpowiednio widok okna1.

0

A jak przekazać informacje "wstecz"? Mamy główną klasę która trzyma wszystkie informację ii jak trzeba to wyświetla okno z prośbą o wpisanie czegoś. Moim pomysłem jest tylko przekazanie głównej klasy jako referencja oknu, ii w momencie gdy klikam przycisk to okno wykorzystując referencję zapisuje potrzebne informacje. Innego pomysłu nie mam jak przekazać informacje do klasy głównej czy jak to nazwałeś modelu.

1

http://www.journaldev.com/1739/observer-design-pattern-in-java-example-tutorial

najprostsze czego możesz użyć.

Generalnie zasada:

Masz kontroler który trzyma model. Masz widok który obserwuje zmiany modelu. Kliknięcie na widoku powoduje odpalenie kontrolera który zmienia model i tak w koło macieju. Tak najlepiej chyba apki swingowe i najprościej tłumaczyć :) Przynajmniej ja tak robię i nikt się za bardzo nie denerwuje :P

0

I jeszcze pytanie. Czy metoda update() z klasy MyTopicSubscriber w tutorialu który podałeś musi być w jakiejś pętli? W sensie trzeba ją wywołać za każdym razem kiedy chce się sprawdzić czy jest jakaś zmiana tak?

Moim zdaniem lepiej by było gdyby to subject ją sam wywoływał.

0

Generalnie odnosząc się do Twojego komentarza, tutaj masz prosty wzór jak to ma wyglądać

http://shulgadim.blogspot.com/2012/01/model-view-controller-mvc-pattern_13.html

Odnośnie pytania w poście.

Właśnie źle rozumujesz. Może ten przykład co tutaj podałem a propoS patternu Observer nie jest najszczęśliwszy, bo nie używa nazw Observer, Observed.

O to właśnie chodzi że Obserwatora nie obchodzi kogo i co obserwuje, nie wie jaka to klasa co robi i go to nie obchodzi, on ma tylko zareagować na jakąś zmianę.

Podam przykład.

Masz napisany termometr który pobiera sobie informację z jakiejś strony internetowej. Więc piszesz sobie klasę która pobiera informację z http i daje w wyniku jakąś liczbę.

Teraz masz jakiś widok który ma pokazać tą temperaturę. więc używasz patternu observer i obserwujesz tą klasę która odczytuje tą temperaturę. I nie obchodzi Cię co to za klasa, ważna jest tylko temperatura.

W zwiazku z czym jak się zmienia, update Obserwera następuje i zmienia się wyświetlana temperatura. Żadne klasy nie wiedzą o sobie jakimi w rzeczywistości są obiekatami, wszystko jest ładnie i schludnie :)

http://www.go4expert.com/articles/design-pattern-simple-examples-t5127/
http://www.fluffycat.com/Java-Design-Patterns/

Tutaj masz kilka dodatkowych przykładów na ładnie opisane design patterny (tzw. Wzorce projektowe)

i jakbyś miał problem to jeszcze kilka przykładów po polsku wraz z wytłumaczeniem
http://www.algorytm.org/wzorce-projektowe/

0
private List<Observer> observers;
 public void register(Observer obj) {
        // [...]
        if(!observers.contains(obj)) observers.add(obj);
        // [...]
    }

Dla mnie to wygląda jak trzymanie referencji w Liście.

1 użytkowników online, w tym zalogowanych: 0, gości: 1