problemas KVO e ligações usando minha própria (não o compartilhou) objeto NSUserDefaults

Question

Estou subclasse NSUserDefaults em meu aplicativo. Um efeito colateral disso é que não posso usar [NSUserDefaults sharedUserDefaults], eu tenho que ter um método de classe para fornecer meu próprio objeto padrões estáticos. Isto não é sido um problema no código, mas está provando complicado agora que eu estou ligando as preferências de interface do usuário com ligações.

O NSUserDefaultsController compartilhada usa os padrões compartilhados, de modo que está fora. Em vez disso eu posso criar meu próprio controlador de defaults no meu controlador janela, fornecê-lo com os meus padrões estáticos objeto, e ligar as minhas ligações para isso. Isto não totalmente trabalhar embora. Quando eu tentei usar KVO em meus padrões objeto não recebi nenhuma notificação de mudança. Eu tentei isso novamente com um objeto normal NSUserDefaults (não é uma subclasse) e novamente, não notificações KVO. Substituindo no objeto de padrões partilhados, KVO funciona exatamente como eu esperava.

Alguém tem alguma idéia de como posso obter ligações e KVO ao trabalho quando não estou usando os padrões compartilhados?

Answer 1

Uma vez que eu não tenha encontrado uma solução ainda, eu decidi tomar alguns conselhos dado a mim durante os últimos CocoaHeads Syracuse reunião e passar a usar as categorias em vez de subclassificação NSUserDefaults. Não uma solução perfeita, mas vai me deixar passar este problema e voltar ao trabalho.

Answer 2

Eu sempre envolver os NSUserDefaults coisas com minha própria classe personalizada para se certificar que tudo funciona como esperado.

O fluxo de trabalho essencialmente é a seguinte:

1. Quando o aplicativo é iniciado, lê todas as entradas NSUserDefaults necessários para a classe personalizada. Esta classe personalizado tem uma propriedade para cada uma das configurações, e todos os objetos NSDictionary e NSArray são mutáveis ??para que as alterações podem ser feitas.
2. Os elementos de interface de usuário que fazem alterações nas configurações são obrigados às propriedades da classe personalizada
3. As alterações nas configurações são salvas NSUserDefaults conforme necessário.

Eu acho que este encapsulamento das configurações do aplicativo ajuda a tirar todas as dores de cabeça. Em vez de lidar diretamente com o sistema NSUserDefaults mágica da Apple, você gasta o seu tempo interagindo com uma classe personalizada bem definida e facilmente testada.

Answer 3

A documentação fornece a resposta, eu acho. O método init inicializa uma nova instância, mas não colocar nada no caminho de pesquisa. Se você está inicializando seus próprios casos, você precisa configurar os domínios que você pretende usar com a mão. Meu palpite é de que a sua aplicação não está funcionando porque os valores que você está tentando obter / set não existem porque não há domínios para salvá-los em.

Em particular, olhar para o método addSuiteNamed: e as constantes NSUserDefaultsDomain. Você precisará configurá-los à mão para fazer sua subclasse, ou qualquer instância do NSUserDefaults diferente standardUserDefaults, o trabalho corretamente.

Answer 4

Eu tenho feito algo semelhante recentemente, e eu estou tendo muito boa sorte até agora. I criar uma subclasse NSObject padrão (MYUserDefaults para discussão). Tem propriedades com as coisas que eu quero (host, nome de usuário, etc.) Alguns vão para NSUserDefaults, alguns vão para chaveiro ou similares. Tem um método +sharedUserDefaults Singleton padrão. (*)

No proprietário janela (NSWindowController ou AppDelegate), eu fornecer uma -sharedUserDefaults. Eu, então, ligar através disso, as configurações que eu quero com um caminho chave simples (sharedUserDefaults.host). Eu normalmente evitar keypaths em ligações porque eles muitas vezes as coisas Ofuscação, mas aqui eu acho que mantém tudo claro, tendo o cuidado do caso especial que o NIB precisa ser impedido de criar uma versão extra não-singleton.

(*) Sem fantasia " forçados Singleton " coisas (que também pode resolver o problema). Eu sou o único que acha que a Apple deve ter grande piscando "não use este se você não sabe porque você precisa dele, e, em seguida, não usá-lo de qualquer maneira" sinal neste doc? Eu acho que o código perigoso deixar os desenvolvedores inexperientes ver. Metade dos objetos no último projeto em que trabalhei tinha +allocWithZone: sobrecarregado. Para mim é apenas má forma para +alloc chamada, e obter ponteiros para objetos existentes. Não minta para mim, a menos que seja absolutamente necessário.