2011-07-31 15 views
7

Mamy aplikację typu shoebox, którą chcemy uczynić pierwszorzędnym obywatelem w Lion. Oznacza to między innymi integrację wersji Auto-Save &. Obecnie nie mamy modelu zorientowanego na dokument i używamy zwykłego stosu danych podstawowych.Aplikacje Shoebox/Library z Auto-Save i wersjami w OS X Lion

UIPersistentDocument zapewnia bardzo łatwy sposób zintegrować zarówno Auto-Save & Wersje i widzę dwie opcje mogliśmy wybrać, aby zintegrować z nowymi API:

  1. „Abuse” NSPersistentDocument dla naszej aplikacji Shoebox stylu . Z technicznego punktu widzenia byłaby to aplikacja oparta na dokumentach, ale interfejs użytkownika nadal byłby tą samą biblioteką podobną do iPhoto. To nie ma sensu, ale dostaniemy wiele darmowych funkcji.
  2. Zachowaj bieżący zwykły stos danych podstawowych i wdrażaj automatycznie zapisywanie wersji &.

Usłyszałem sprzeczne opinie przedstawicieli Apple o podejściu, które powinniśmy podjąć, i dobrze byłoby wyjaśnić pewne kwestie, zanim zaczniemy wdrażanie. Chociaż uważam, że 1. nie powinno się używać, to jest również bardzo kuszące, ponieważ dostajemy dużo za darmo. Nie mogłem nawet znaleźć wystarczającej dokumentacji na temat ręcznego wdrażania wersji Auto-Save & w aplikacji Core Data.

Chciałbym naprawdę mają tendencję do używania 1. ale widzę pewne problemy:

  • Martwię się o konfliktach plików na poziomie systemu przy użyciu wersji i tylko jeden plik bazy danych. Nie mogłem znaleźć żadnej dokumentacji dotyczącej tego tematu.
  • Martwię się o problemy z wydajnością w wersjach podczas przeglądania "przestrzeni".
  • Nie możemy egzekwować tylko jednej instancji otwartej bazy danych, ponieważ wersje muszą otwierać kilka instancji. Martwię się o skutki uboczne i problemy z współbieżnością. Konceptualnie wygląda jak włamanie i nie lubię hacków.

Gdybyśmy chcieli tylko zintegrować synchronizację iCloud, zdecydowanie nie pomyślałbym o używaniu modelu zorientowanego na dokument dla naszej aplikacji, ponieważ Core Data obsługuje go bezpośrednio. Martwię się głównie o koszty ogólne, jakie moglibyśmy uzyskać, gdybyśmy trzymali się naszego obecnego nie opartego na dokumentach paradygmatu.

Czy masz jakieś porady lub pomysły, w jaki sposób aplikacje pudełek na buty powinny zostać zintegrowane z nowym światem Lwa?

+1

Co to jest "aplikacja typu shoebox"? – TechZen

+1

Aplikacja pudełka po butach lub biblioteki to aplikacja, która przechowuje wszystkie dane w jednym oknie zamiast używać wielu dokumentów. Dobrymi przykładami aplikacji typu shoebox są iPhoto, iTunes; Dobrymi przykładami aplikacji opartych na dokumentach są strony lub opis. Chociaż iTunes i iPhoto są aplikacjami typu shoebox, nadal działają z "biblioteką", która sama jest dokumentem i można przełączać się między różnymi bibliotekami. –

Odpowiedz

3

Obawiam się, że jesteś zmuszony do skorzystania z pierwszej opcji. Wersje są zaimplementowane wewnątrz NSDocumentController * sic *, więc będziesz musiał użyć jakiegoś rodzaju NSDocument, aby uzyskać coś poza wersjami. I think musisz również dodać okno aplikacji do tego dokumentu, aby uzyskać ładne małe menu na górze. Problem polega na tym, że wersje są mniej lub bardziej całkowicie nieprzejrzystymi cechami ...

Ale jest pytanie, na które należy odpowiedzieć: jakie części aplikacji chcesz umieścić w wersji? Czy naprawdę ma sens, aby wszystko w jednym pliku, jeśli chodzi o przywracanie danych? Przywracanie wersji (inne niż wklej &) dzieje się na poziomie systemu plików. Czy zatem naprawdę ma sens zawsze mieć wszystko odrestaurowane na raz? Jeśli twoja odpowiedź brzmi "nie", prawdopodobnie będziesz musiał przeciąć model na wiele mniejszych plików ...

Nie oczekuj poprawy aż do następnego wydania głównego. Tak właśnie zgadywałem z komentarzy inżynierów ...

+1

+1 Wersjonowanie ma sens tylko w kontekście dokumentów, w których ta sama treść ewoluuje w godzinach nadliczbowych. Nie ma sensu posiadanie różnych "wersji" uniwersalnego magazynu bazy danych, ponieważ zwykle chcemy przechwytywać tylko bieżący stan danych. W bazie danych nowa "wersja" jest prawie zawsze traktowana jako nowe dane. Jeśli potrzebujesz czegoś takiego jak wersja w bazie danych, projektujesz ją w samym modelu danych, ponieważ rzadko jest to tak proste, jak tylko wprowadzanie danych w różnych momentach, tak jak ma to miejsce w przypadku wersjonowania dokumentów. – TechZen

+0

@Max: Możesz także użyć NSFileVersion i utworzyć własny interfejs dla wersji, ale nie dostaniesz fantazyjnego interfejsu użytkownika Time Machine, do którego wszyscy ludzie są przyzwyczajeni. Nie sądzę, by była to korzyść dla użytkowników z perspektywy UX, gdyby każda aplikacja miała swój własny niestandardowy interfejs użytkownika. Istnieje również problem polegający na tym, że NSPersistentDocument * obsługuje * zapisywanie oparte na zapisach dla modeli opartych na bazach danych SQLite. Wydaje mi się, że implementacja nie została ukończona, ponieważ naturalną ewolucją byłoby to, że wersje obsługują także modyfikacje oparte na rekordach (zamiast na plikach). Dzielenie modelu nie działa (Shoebox). –

+0

@TechZen: Tak, w zasadzie masz rację. Ale co to jest dokument? Możesz mieć dokumenty bazujące na danych podstawowych wewnątrz NSFileWrapper, które wciąż przechowują kompletny model z plikami pomocniczymi. Jeśli weźmiemy przykład książki, gdzie narysujesz linię? Czy każdy dokument jest książką z rozdziałami w środku, czy dokumentem jest biblioteką zawierającą różne książki i posiadasz różne biblioteki, takie jak badania, zabawa, komiksy? Dane podstawowe nie są bazą danych, a interfejsy API nie pozwalają na interakcję z modelami, tak jak w przypadku klasycznych baz danych. Ponadto NSPersistentDocument i iCloud mają już wsparcie oparte na rekordach dla CD. –