Jak używać Fragmentu w Switchu?

Chodzi mi o to, że chcę mieć kod w stylu (mówimy o aplikacji na androida):

                Fragment fragment;

                switch (position)
                {
                    case 0:
                            fragment = new Jeden();
                            break;
                    case 1:
                            fragment = new Dwa();
                            break;

i tak dalej, a po switchu całym chcę mieć resztę kodu i niestety kompilator czepia się linijki (słówka "fragment"):

ft.replace(R.id.fragment_spot, fragment);

Chodzi mu, że trzeba zainicjować, czyli gdybym nad switchem dał linijkę

fragment = new Jeden();

to by przestał się czepiać, ale nie wiem czy tak wolno, bo to moje początki z javą. Nie próbowałem nawet odpalić programu z tą dopisaną linijką, wolę was zapytać co w takiej sytuacji robić. Gdyby była metoda fragment.free, to bym pewnie nie zakładał tego tematu. Napiszcie mi co w ogóle dzieje się w tej linijce z new, czy tworząc jedną rzecz, nadpisuje mi poprzednią, czy może przypisuje dwie rzeczy do fragmentu? Bo jak nadpisuje, to w sumie chyba mógłbym nad switchem tę inicjację zrobić, która i tak w switchu byłaby nadpisana.

Prosiłbym by ktoś spróbował udzielić się w tym temacie, będę wdzięczny. Pozdrawiam.

daj nad switchem:

Fragment fragment=null;

dzięki

Krwawy Mleczarz napisał(a):

daj nad switchem:

Fragment fragment=null;

i pozniej szok ze null ref exception leci...

imo lepiej pod case 0 i case 1 dolozyc labela default gdzie obiekt jest inicjalizowany do czegos domyslnego lub rzuca spodziewany wyjatek typu 'niezdefiniowana pozycja (...)'

używam 'default' właśnie na te przypadki, ale nad switchem chyba i tak muszę mieć tamtą linijkę choćby z nullem by skompilowało mi apkę. Uruchomiłem aplikację i wygląda na to, że działa dobrze, czyli chyba tak zostawię.

frfrrfrrffrr napisał(a):

używam 'default' właśnie na te przypadki, ale nad switchem chyba i tak muszę mieć tamtą linijkę choćby z nullem by skompilowało mi apkę

chyba? rozumiem ze odpalenie kompilatora wykracza poza zakres metod poznawczych...

frfrrfrrffrr napisał(a):

Uruchomiłem aplikację i wygląda na to, że działa dobrze, czyli chyba tak zostawię.

that's the spirit! kompiluje sie, wyglada ze dziala, jazda na produkcje i idziemy na urlop :)

bez nullu by nie odpaliło jej (mimo, że w switchu byłby default)

miales tylko 2 odpowiedzi do wyboru, nastepnym razem sie uda :)

W javie nie możesz użyć niezainicjowanej zmiennej. Jeżeli w default przypiszesz do niej jakąś wartość, albo rzucisz wyjątkiem to nie ma możliwości żeby fragment który z niej korzysta nie wiedział na jakiej wartości pracuje.

Jeżeli zostawisz null, to narażasz się ścieżkę w której ta wartość zostanie przekazana dalej, czyli sytuację niepożądaną. Zrób jak pisze @katelx i pomyśl dlaczego jej rozwiązanie jest lepsze.

A ja bym się w ogóle zastanowił nad tą konstrukcją. Bo często takie drabinkowe switche / ify oznaczają że masz bląd projektowy :)

@Shalom rozwiniesz to? To banalny switch w kodzie ze zmienną position, która przykładowo przyjmuje wcześniej wartość np. od zera do 6 (nie ma opcji by wartość była inna niż ten zakres), a fragmenty są by we FrameLayout podmieniać okna (siedem okien dla przykładu jest).
Jako, że cały kod podmiany okna wygląda tak:

            fragment = new MyFragmentOne();
            FragmentManager fm = getFragmentManager();
            FragmentTransaction ft = fm.beginTransaction();
            ft.replace(R.id.fragment_place, fragment);
            ft.addToBackStack(null);
            ft.commit();

to jako, że mam siedem okien możliwych do wyświetlenia, to używałem SWITCH, w którym tylko fragment = new MyFragmentOne(); chcę zmieniać w zależności od zmiennej position, która jak wspomniałem ma wartości od 0 do 6 (nie ma szans na inną wartość), także switcha zbudowałem tak jak ten fragment kodu z pierwszego postu, z tym, że tam brakuje w switchu default:, który też mam i w tym default inicjuję sobie pierwsze okno tak na wszelki wypadek, ale, że kompilator dowalał się, że nie było inicjacji (czyli nie pozwolił nawet odpalić projektu), tu musiałem przykładowo użyć tego NULL we fragmencie przed switchem i wszystko działa perfekcyjnie, zero błędów, aplikacja się uruchamia, 100% bezbłędnie, cudownie chodzi więc tak planuję zostawić z tym nullem, ale jako, że wy udzielacie się dalej i mam wrażenie, że wg niektórych coś jest źle (mimo, że program działa świetnie w stu procentach) to teraz właśnie piszę ten post opisując wszystko. Jeśli wg was coś źle zrobiłem (program działa perfekcyjnie), to proszę byście mi napisali co mam poprawić, co zrobić inaczej (bo skoro ja nie mam żadnych błędów, nie widzę też możliwości by w programie błąd jakiś spowodować, bo zwyczajnie wszystko idealnie działa, to nie wiem czego chcecie).

I chciałbym wam bardzo podziękować, że poświęcacie mi chwilę czasu i udzielacie się w temacie, dzięki wam jako tako zyskuję wiedzę, cenię was za to. Na razie to tyle co chciałem napisać, dziękuję i klikam "wyślij".

To że program działa to o niczym nie świadczy ;) Programy są dla ludzi do czytania a nie dla komputera do wykonywania. Pisząc programy trzeba myśleć o tym że kiedyś coś może trzeba będzie w nim zmienić, albo go rozwinąć. Wyobraź sobie że piszesz grę kółko i krzyżyk i rozpatrujesz sobie "na pałe" wszytkie możliwości ustawień bo dla planszy 3x3 to jest wykonalne. Ot masz trochę ifów i tyle. A potem przychodzi klient i mówi że on my chciał żeby to się jednak skalowało np. do 10x10. Albo 100x100. Czy myślisz że rozpatrywanie wszystkich przypadków nadal jest dobrym rozwiązaniem? Ale przecież działało perfekcyjnie! Więc to musi być dobry sposób! ;)

To jest właśnie błąd projektowy. On nie oznacza że program będzie działał źle, tylko że pisanie/rozwijanie tego programu będzie znacznie trudniejsze i bardziej skomplikowane i w efekcie będzie bardziej podatne na blędy.

Czy gdybyś w programie mógł mieć 1000 okien to też byś to zrobił tym switchem? A może jednak pomyślałbyś czy nie da się inaczej? Może na przykład wygodniej byłoby zrobić sobie mapę Map<Integer, Fragment> która dla id zwraca odpowiedni obiekt? A taką mapę wygenerować sobie jedną pętlą choćby za pomocą refleksji jeśli inaczej się nie da. I nagle zamiast switcha na 1000 case'ów masz 3 linijki na utworzenie mapy i 1 na pobieranie fragmentu. Nie mówie że to akurat jest rozwiązanie dla ciebie bo nie znam projektu, ale chcę tylko zasygnalizować że często "proste" rozwiązanie wcale nie jest zbyt dobre.

Aha, to o to ci chodzi. Ten program nie będzie w ogóle rozwijany. Wyglądać będzie na zawsze tak, że będzie np. 7 okien. Mógłbym dać 8 buttonów i każdy button otwierałby nowe okno we FrameLayout, ale wolałem użyć Spinnera, a w nim np. 7 pozycji, czyli w zmiennej position będą istniały tylko liczby od 0 do 6 i na ich podstawie podmieniałem okno we FrameLayout.
Niby istnieje jakiś inny bajer (komponent, czy coś) do przełączania okienek, ale nie interesowałem się nim, bo stawiam na razie na prostotę, bo doświadczenia nie mam.
Co więc oferujesz mi skoro chcę zostawić przy Spinnerze, który ma 7 pozycji (nigdy nie będzie miał więcej) i okienka w jednym FrameLayout będę podmieniał na podstawie wybranej pozycji w Spinnerze? Dasz jakiś przykładowy pseudokod?

a swoją drogą mogę sobie jakąś tablicę lub coś zrobić w stylu:
tablica = (OknoJeden, OknoDwa, OknoTrzy)
i później fragment utworzyć przez = new tablica
? :D

Aha, to o to ci chodzi. Ten program nie będzie w ogóle rozwijany.

Nie w ty rzecz. Rzecz w tym że tak będziesz pisał jak sie nauczysz. Jak od początku będziesz to robił źle to ci tak zostanie.

a swoją drogą mogę sobie jakąś tablicę lub coś zrobić w stylu:

Możesz, to zresztą sugerowałem...

Fragment[] fragmenty = {new Jeden(), new Dwa()};
//
int x = 5;
Fragment f = fragmenty[x];

dziękuję