W jaki sposób zaimplementowana zostanie lista źródeł w stylu iTunes z powiązaniami + CoreData w Cocoa?

Question

Załóżmy, dla ilustracji, że napisałem aplikację klonu iTunes w Cocoa, która była wspierana przez CoreData. Dla uproszczenia powiedzmy, że istnieją dwie "sekcje", "Biblioteka" z takimi rzeczami, jak Muzyka, Filmy, Radio itd. A druga sekcja nazywa się "Playlisty", która zawiera listy tworzone przez użytkowników (tylko głupie listy, a nie inteligentne listy odtwarzania) .

Tak więc sama SourceList będzie zazwyczaj implementowana z NSOutlineView, co jest zazwyczaj proste.

Sekcja Biblioteka na liście źródłowej nie zawiera w rzeczywistości niczego wygenerowanego przez użytkownika, tylko "cechy" aplikacji (w zasadzie), w której sekcja Listy odtwarzania zawiera tylko własne listy utworzone przez użytkownika. W jaki sposób można to zrobić z Bindings i CoreData? Czy można powiązać sekcję Listy odtwarzania z danymi użytkownika i mieć niestandardowy sposób wyświetlania funkcji biblioteki?

Wciąż mam problemy z Wiązaniami i AppKit w ogóle, więc proszę o zachowanie mnie. Doceniam pomoc. Powinienem dodać, celuję w 10.6 i wyżej.

Answer 1

Nie miałem dużego doświadczenia z podstawowymi danymi, ale szeroko wykorzystałem wiązania Cocoa. Z mojego doświadczenia wynika, że ​​coś takiego działa najlepiej z pośrednim NSArray obiektów, które są "ręcznie" regulowane.

Jako przykład, wyobrażam sobie, że masz niestandardowe NSArray list odtwarzania, które są generowane przez użytkownika, a także masz oddzielne NSArray zawierające standardowe elementy biblioteki. Dzięki tej konfiguracji utworzyłbym właściwość w jednym ze kontrolerów o nazwie combinedArray, która byłaby własnością, która zostanie przypisana do twojego NSOutlineView. Chciałbym następnie związać twoją tablicę listy generowanych przez użytkownika z kontrolerem i mieć jakiś kod w kontrolerze automatycznie aktualizować połączoną tablicę za każdym razem, gdy modyfikowana jest tablica listy odtwarzania.

Oto szybki mock-up:

TheController.h

@interface TheController : NSObject 
{ 
    NSArray * combinedArray; 
    NSArray * userPlaylists; 
} 
@property (retain) NSArray * combinedArray; 
@property (copy) NSArray * userPlaylists; 
@end 

TheController.m

@implementation TheController 

@synthesize combinedArray; 
@synthesize userPlaylists; 
- (void)setUserPlaylists:(NSArray *)newLists 
{ 
    // standard property setting code: 
    if (newLists != userPlaylists) 
    { 
     [userPlaylists release]; 
     userPlaylists = [newLists copy]; 
    } 

    // modify the combined array: 
    NSMutableArray * allItems = [NSMutableArray arrayWithCapacity:0]; 
    [allItems addObjectsFromArray:standardLibrary]; 
    [allItems addObjectsFromArray:userPlaylists]; 
    [self setCombinedArray:allItems]; 
} 

@end 

Answer 2

Ponieważ lista źródłowa w tym przypadku jest tak naprawdę "zakresem", a nie płaską listą nic poza instancjami jakiegoś elementu "LibraryItem", myślę, że łatwiej jest zaimplementować to w sposób "staroświecki" (tj. protokół źródła danych).

Daje to precyzyjną kontrolę nad grupowaniem, jak i kiedy miksować elementy "statyczne" (np. "Biblioteka" i "Muzyka" oraz "Filmy", "Listy odtwarzania") z elementami ze sklepu (np. Z indywidualną listą odtwarzania) przedmioty w sekcji "Playlisty").

Jest także nieco łatwiej radzić sobie z przeciąganiem i upuszczaniem, co moim zdaniem jest kluczowe, gdy zapobiegamy upuszczeniu elementu z playlisty do grupy "Filmy".