2014-10-05 35 views
18

Mam następujący kodnie jest dostępna w bieżącym kontekście

public abstract class BaseAdapter<T, V extends BaseAdapter.ViewHolder> extends ArrayAdapter<T> { 
    public BaseAdapter(Context context, int resource, Collection<T> collection) { 
     // typical constructor logic 
    } 

    // some other custom defined methods 

    public static class ViewHolder { 
     // custom defined logic 
    } 
} 

public class ModelAdapter extends BaseAdapter<Model, ModelAdapter.ModelViewHolder> { 
    public ModelAdapter(Context context, int resource, Collection<Model> collection) { 
     super(context, resource, collection); 
     // typical constructor logic 
    } 

    public static class ModelViewHolder extends ViewHolder { 
     // custom defined logic 
    } 
} 

BaseAdapter i ModelAdapter są w plikach rozdzielone. Problem polega na tym, że mam błąd kompilacji podczas próby zdefiniowania ModelAdapter: ModelViewHolder nie jest dostępna w bieżącym kontekście

ja nie bardzo rozumiem ten błąd i nie można dowiedzieć się, co robię źle. Czy ktoś może mi wyjaśnić ten problem lub link, który może wyjaśnić tę sytuację?

+0

Czy możesz opublikować kompletną wiadomość kompilatora? – Fildor

+0

To jest kompletny komunikat kompilatora – CipQuestion

Odpowiedz

32

Creation Martwe Blokada

użyć ModelAdapter.ModelViewHolder jako parametr szablonu z BaseAdapter i niech ModelAdapter rozciąga BaseAdapter, następnie kompilator próbował stworzyć ModelViewHolder pierwszy, ale klasa ModelAdapter.ModelViewHolder (typ jest Klasa) nie jest jeszcze utworzony. Musi poczekać, aż zostanie utworzone ModelAdapter, ponieważ ModelViewHolder jest w zakresie ModelAdapter.

Sposób rozwiązania tego problemu polega na umieszczeniu klasy ModelViewHolder w nowym pliku * .java.

+0

Dobra odpowiedź! Byłem tym kompletnie zakłopotany. –

+1

Miałem to samo zadanie. Prawdopodobnie byłoby wygodniej przenieść klasę ViewHolder w celu oddzielenia pliku * .java. –

+0

Nadal nie rozumiem tego ... Czy nie jest możliwe, aby statystyka ModelViewHolder rozwiązała to? Modyfikator statyczny powinien umożliwić zainicjowanie tej klasy bez inicjowania klasy nadrzędnej ... – BamsBamx

0

Zdarzyło mi się to samo, gdy rozszerzałem klasę podstawową. Ale tym razem miałem to w ten sposób (po podanym przykładzie w pytaniu)

BaseAdapter.java

public abstract class BaseAdapter<T, V extends BaseAdapter.ViewHolder> extends ArrayAdapter<T> { 
    public BaseAdapter(Context context, int resource, Collection<T> collection) { 
     // typical constructor logic 
    } 

    // some other custom defined methods 

    public static class ViewHolder { 
     // custom defined logic 
    } 
} 

ModelAdapter.java

import com.mypackage.ModelAdapter.ModelViewHolder; ***//NOTE THIS IMPORT!!!*** 

public class ModelAdapter extends BaseAdapter<Model, ModelAdapter.ModelViewHolder> { 
    public ModelAdapter(Context context, int resource, Collection<Model> collection) { 
     super(context, resource, collection); 
     // typical constructor logic 
    } 

    public static class ModelViewHolder extends ViewHolder { 
     // custom defined logic 
    } 
} 

Że sposób, w jaki ostrzeżenie zniknęło i nie trzeba było oddzielać ModelViewHolder na inny ".java" plik. Zauważ, że są one w dwóch różnych plikach i zaimportować w ModelAdapter.java.

myślę odpowiedź Fei Liang jest częściowo błędna, ponieważ będąc ModelViewHolder statyczny powinien umożliwiać zainicjować ModelViewHolder bez inicjowania jej nadrzędnej klasy ModelAdapter

+0

Używam Androida Studio 1.5.2 i to nie działa dla mnie. Android Studio twierdzi, że import jest nieużywany i nadal podaje błąd. – ThomasW

0

I w obliczu tego problemu wcześniej, nie jestem pewien, dlaczego tak się stało,

ale postanowiłem go

podejmowania the not-accessible inner klasa stand-alone klasa (nie wewnętrzną co oznacza w oddzielnym pliku)

1

Oto, jak to rozwiązano. Zasadniczo nie powinno być problemu z zależnością cykliczną, ponieważ zagnieżdżone klasy wizualizatorów są statyczne. Na przykład. spójrz na notoryczną hierarchię LayoutParams, która jest zbudowana dokładnie w ten sam sposób: klasa dziedziczy inną klasę, a ich statyczne zagnieżdżone klasy mają odpowiednią relację dziedziczenia.
Wygląda na to, że cykliczność pochodzi raczej z kwestii zasięgu widoczności.ModelViewHolder może przedłużyć ViewHolder tylko wtedy, gdy zapozna się z nim po zewnętrznym ModelAdapter dziedziczy zakres widoczności BaseAdapter. Tymczasem ModelAdapter nie może odziedziczyć BaseAdapter, dopóki klasanie zostanie zainicjowana zgodnie z wymaganiami dla parametru ogólnego. Z drugiej strony, ModelViewHolder jest statyczną klasą zagnieżdżoną i technicznie nie zależy od jej klasy zewnętrznej.

Tym samym rozwiązaniem jest pełna identyfikacja nazwy ViewHolder podczas zadeklarowania ModelViewHolder. Zanotuj część extends BaseAdapter.ViewHolder w poniższym fragmencie. W ten sposób, ModelViewHolder nie musi używać zakresu ModelAdapter, aby wiedzieć o ViewHolder.

ModelAdapter.java

public class ModelAdapter extends BaseAdapter<Model, ModelAdapter.ModelViewHolder> { 
    public ModelAdapter(Context context, int resource, Collection<Model> collection) { 
     super(context, resource, collection); 
     // typical constructor logic 
    } 

    public static class ModelViewHolder extends BaseAdapter.ViewHolder { 
     // custom defined logic 
    } 
} 

Uwaga na temat Androida Studio: Choć sam problem nie jest związany z systemem Android Studio, pobiegłem do niego za pomocą funkcji jak w "class Copy" (przy użyciu AS 3.0). Podczas kopiowania "upraszczał" kod dla mnie, usuwając pełną nazwę. Więc uważaj na szaleństwo AS!

Powiązane problemy