Niestandardowe sprawdzone metody UIView i UIViewController?

Question

Obecnie mam prostą aplikację na iPhone'a, która ładuje niestandardową podklasę UIView. W tej chwili jest tylko jeden kontroler dla całej aplikacji, chociaż istnieje kilka UIViews do logicznego oddzielenia programu.

Moja obecna struktura wygląda mniej więcej tak:

mainView : UIScrollView 
    \__ has one subView : myCustomUIView : UIView 
      \__ has many subSubView : myOtherCustomUIView : UIView 

Mam nadzieję, że to jest jasne; dwukropek oczywiście reprezentuje dziedziczenie.

Mój problem jest następujący: muszę przechwytywać zdarzenia na najniższym poziomie, subSubView. Prawdopodobnie mogę to zrobić w kontrolerze aplikacji, jeśli potrzebuję, ale czy powinienem zamiast tego mieć subSubViewController? Czy powinienem też mieć subViewController?

Jeśli tak, czy ktoś może wskazać mi jakieś odniesienia do ręcznego wykonania? Mogę oczywiście tworzyć klasy, ale łączenie ich z niestandardowymi widokami wydaje się nietrywialne. W ogóle nie używam budowniczego interfejsu poza głównym stalowkiem, który trzyma obiekt okna.

Moje główne zamieszanie wynika z tego, co się stanie, gdy mam widok zagnieżdżony w widoku z innym kontrolerem. Załóżmy, że mam subSubViewController, ale mainView nadal ma swój mainViewController. Ponieważ subSubView jest zawarty w mainView, czy nie spowoduje to problemu?

Czy powinienem w ogóle używać tych osób?

Każde uderzenie w odpowiednim kierunku zostanie docenione.

Answer 1

Widoki i kontrolery widoku istnieją w parach. Każdy kontroler widoku steruje widokiem i widokami widoku. Jest to konieczne, ponieważ kontrolery widoku znajdują się w łańcuchu respondentów dla zdarzeń. Jeśli wiele widoków kontrolerów jest aktywnych w tym samym widoku, łańcuch respondera staje się kodowany.

Kontrolery widoku standardowego nie mają atrybutu subController i nie rozumieją, czy inny kontroler jest aktywny w tym samym łańcuchu. Kontrolery nawigacji i kontrolerów kart istnieją dokładnie w celu obsługi kontrolerów hierarchicznych. Jednak robią to, zamieniając jedną parę widoków/kontrolerów widoku na inną. Nie można używać kontrolerów nawigacyjnych ani kontrolerów kart, aby zapewnić różne kontrolery dla subskrybentów.

Tak więc, niezależnie od tego, ile subskrybentów masz do oglądania przez kogokolwiek, otrzymujesz tylko jeden kontroler na ekranie.

Być może zechcesz ponownie rozważyć swój projekt. Jeśli subviews każdy z nich wymaga wysoce dostosowywalnych zachowań, możesz chcieć przenieść je do poszczególnych widoków w hierarchii kontrolera, na przykład we wzorcu projektu typu szczegół.

Jeśli musisz mieć wszystkie subviews na tym samym ekranie, to sugerowałbym spojrzenie na jak UITableView i UITableViewController obsługują rzeczy. (Możesz po prostu użyć zmodyfikowanego widoku tabeli). Widok stołowy to widok przewijania zawierający wiele subskrybowanych komórek, tytułów sekcji, nagłówków i stopek. Zarządza tym, zatrzymując dotknięcia z widoku stołu i określając, który widok komórki został dotknięty, a następnie podejmując odpowiednie działania.

Jeśli potrzebujesz wysoce dostosowanego zachowania dla każdego z podglądów, możesz użyć wzorca delegata i przypisać każdemu z podglądów inny obiekt pełnomocnika. Widok może pułapkę własnych dotknięć i zadzwonić do własnego delegata.

Wywiady mogą być trudne do zaimplementowania niestandardowego zachowania dotykowego, ponieważ pułapki na ekranie przewijają się na wyższym poziomie niż inne widoki, dzięki czemu mogą określić, czy należy przewijać, czy nie.