Arraylist pomiędzy aktywnościami

0

Rzecz wygląda następująco

Jest klasa bazowa Point (PUNKT)

no i wyprowadzam z niej klasy
PUNKT_BAZOWY dziedziczy po PUNKT
PUNKT_TYP_A - dziedziczy po PUNKT_BAZOWY
PUNKT_TYP_B - dziedziczy po PUNKT_BAZOWY

tworzę w AKTYWNOŚCI 1 ArrayLisy<PUNKT_BAZOWY>

a dodaje do niej obiekty klas PUNKT_TYP_A i PUNKT_TYP_B

czyli w ArrayLisy<PUNKT_BAZOWY>mam
PUNKT_TYP_A
PUNKT_TYP_A
PUNKT_TYP_B
PUNKT_TYP_B

teraz chcę tą ArrayLisy<PUNKT_BAZOWY> przesłać do AKTYWNOŚCI 2

próbowałem

  • parcelable
  • serilizable

ale nie ma dużych sukcesów - tj ArrayList sie przesyła między aktywnościami, ale w AKTYWNOŚCI 2 w ArrayList są obiekty typu bazowego Point (PUNKT)

czyli wygląda to tak
PUNKT
PUNKT
PUNKT
PUNKT

no i w związku z tym mam pytanie - jak tak skonstruowaną ArrayList przekazać między aktywnościami?

z góry dziękuję za odpowiedź

0

Po czym rozpoznajesz ze sa to Punkty? Wywolujesz jakas metode ktora nadpisujesz w podlklasach i dzialanie jest nie takie jak powinno czy jak?

0

Po pierwsze skoro próbowałeś używać serializacji - to czy każda klasa z rodziny PUNKT ma swoje unikalne pole serialVersionUID?
Bo jeżeli nie, to nie dziw się, że nie działa poprawne odtwarzanie obiektów. Wtedy nie inicjują się poprawnie tablice wirtualne - w efekcie wszystkie metody obiektów mapują się na klasę bazową, więc obiekt widziany jest jakby był bazowy - nawet mimo innych rozmiarów (np. dodatkowych pól potomków). Tak czy inaczej Runtime nie potrafi rozpoznać takiego obiektu jako obiektu klasy potomnej.

0
Olamagato napisał(a)

Po pierwsze skoro próbowałeś używać serializacji - to czy każda klasa z rodziny PUNKT ma swoje unikalne pole serialVersionUID?

ma coś takiego
private static final long serialVersionUID = UUID.randomUUID().getLeastSignificantBits();

0

W takim razie upewnij się czy w każdej aktywności te pola mają takie same wartości. Jako drugi krok poleciłbym dołożenie tymczasowego pola licznika, który będąc inkrementowany w konstruktorze nada każdemu obiektowi unikalną i znaną wartość - to pozwoli określić czy deserializowane obiekty (nie klasy!) są tymi samymi co serializowanymi z punktu widzenia zawartości. Ostatnim krokiem powinno być porównanie czy obiekty o tych samych wartościach licznika w obu aktywnościach mają ten sam typ dynamiczny widziany przez runtime. To razem powinno pozwolić wykryć przyczynę problemu i ustalić czy z założenia "te same" obiekty w obu aktywnościach są rzeczywiście tymi samymi. Można też do tego wykorzystać dobrze napisane metody hashCode() oraz equal().

0
Olamagato napisał(a)

Po pierwsze skoro próbowałeś używać serializacji - to czy każda klasa z rodziny PUNKT ma swoje unikalne pole serialVersionUID?
Bo jeżeli nie, to nie dziw się, że nie działa poprawne odtwarzanie obiektów. Wtedy nie inicjują się poprawnie tablice wirtualne - w efekcie wszystkie metody obiektów mapują się na klasę bazową, więc obiekt widziany jest jakby był bazowy - nawet mimo innych rozmiarów (np. dodatkowych pól potomków). Tak czy inaczej Runtime nie potrafi rozpoznać takiego obiektu jako obiektu klasy potomnej.

Co ty pierdzie|isz? Serializacja zapisuje klase ktora serializuje, i odczytywany obiekt jest obiektem tej klasy. Gdy zapisywane sa podklasy, to odtwarzane sa podklasy. serialVersioID czy jak mu tam jest zupelne od czegos innego - do okreslania kompabybilnosci zmienajacych sie klas.
To pole wcale nie musi byc unikalne, bo ono nie jest do okreslania jaki typ ma dany zserializowany obiekt.
Poczytaj o tym. Zawsze miales niezle odpowiedzi, ale teraz to mnie zrzuciles z mostu. Pozniejszego posta nie bede komentowal bo pisales go tkwiac nadal w przeswiadczeniu ze serialVersionUID ma jakies znaczenie w okreslaniu typow.

ja_ja_ja napisał(a)

private static final long serialVersionUID = UUID.randomUUID().getLeastSignificantBits();

Czyli twoja wersja klasy jest losowa, i rozna praktycznie przy kazdym starcie JVM? Czyli jak zapiszesz jakas klase, wylaczysz app, wlaczysz, odcyztasz to dostajesz na twarz blad ze klasy sa niekompatybilne. Zonk.

0
szok napisał(a)

Czyli twoja wersja klasy jest losowa, i rozna praktycznie przy kazdym starcie JVM? Czyli jak zapiszesz jakas klase, wylaczysz app, wlaczysz, odcyztasz to dostajesz na twarz blad ze klasy sa niekompatybilne. Zonk.

no gut
czyli mam tam wpisać jakąś stałą?

0

Dokladnie. Jak to jest pierwsza wersja tej klasy, wpisz 1. Gdy klase zmienisz w ten sposob ze serializacja sobie nie poradzi i nie dasz rady zrobic aby kompatybilne, to wstawiasz 2 itp. To jest przyklad, inni maja inne schematy.
Niech sie jeszcze Olomogato wypowie, moze dorzuci jakies ciekawe schematy...

0

dobra już rozkminiłem w czym jest problemem

w klasie bazowe

klasa bazowa to:
http://code.google.com/p/osmdroid/source/browse/trunk/osmdroid-android/src/org/osmdroid/util/GeoPoint.java?r=667

i od niej wywodzą się wszystkie pozostałe

no i cokolwiek po niej dziedziczę - zrobiłem sobie taki test

public class Test extends GeoPoint {

public final Property<Integer> position = new Property<Integer>();

public Test(int pos)
{
super(17L,61L);
position.set(pos);
}

}

i gdy klasa bazową była inna klasa to serializacja działała bez zarzutu, gdy jest ta następuje jakas dziwna konwersja do typu bazowego

i nie wiem skąd to się bierze

0
        public static final Parcelable.Creator<GeoPoint> CREATOR = new Parcelable.Creator<GeoPoint>() {
                @Override
                public GeoPoint createFromParcel(final Parcel in) {
                        return new GeoPoint(in);
                }

                @Override
                public GeoPoint[] newArray(final int size) {
                        return new GeoPoint[size];
                }
        };

To pole CREATOR jest wymagane przez androida (http://developer.android.com/reference/android/os/Parcelable.Creator.html) i tworzy GeoPoint. Musisz pewnie zrobic podobne cudo w Twojej klasie.

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