Architettura per lo strumento di raccolta della diagnosi a livello di applicazione?

1

Il proprietario del mio prodotto desidera che vengano segnalate ulteriori informazioni sullo stato del prodotto quando un utente contatta il servizio clienti tramite un modulo in-app. Il modulo alla fine si traduce in un'e-mail inviata a un elenco e-mail di un servizio clienti e gestita altrove.

La parte che sto cercando è come aumentare il mio progetto iOS esistente per consentire a qualche controller di raccogliere informazioni diagnostiche da una varietà di classi disparate, e farlo in un modo che sia minimamente invasivo e non causi mal di testa se refactoring più tardi.

Blocchi

Ho sperimentato alcune idee, tra cui un'interfaccia che consente a una classe arbitraria di registrare un blocco da eseguire quando si tenta di raccogliere le informazioni diagnostiche:

[DiagnosticCollectionController addBlockForDiagnosis:^(DiagnosticCollectionController *controller){
    // Add some information here to the controller to send in the diagnostic report
}];

Notifiche

Un'altra idea che avevo in mente era che il controller diagnostico trasmettesse una notifica quando era pronta per iniziare a raccogliere informazioni, in modo che altri oggetti potessero collegare ciò di cui avevano bisogno. Il vantaggio (potenziale) qui è che posso evitare l'uso dei blocchi, evitando così di avere dei problemi di copia dei blocchi:

[[NSNotificationCenter defaultCenter] addObserver:self 
                                         selector:@selector(someSelectorToHandleDiagnosticPopulation:) 
                                             name:DiagnosticCollectionControllerWillSendDiagnostics 
                                           object:someDiagnosticController];
// Elsewhere
- (void) someSelectorToHandleDiagnosticPopulation:(NSNotification *)note {
    DiagnosticController *controller = [note object];
    [controller addDiagnosticData:someDataDictionary];
}
    
posta Hyperbole 29.07.2014 - 18:56
fonte

2 risposte

0

Infine, sono andato con un setup vicino a quello che Randall ha suggerito, dopo un po 'di riflessione e qualche distrazione.

Le interfacce che gestiscono il coordinamento del lavoro diagnostico hanno questo aspetto:

@interface DiagnosticController
+ (void) addDiagnosticProvider:(id<DiagnosticProvider>)provider;
+ (void) removeDiagnosticProvider:(id<DiagnosticProvider>)provider;
@end

@protocol DiagnosticProvider <NSObject>
- (NSDictionary *) diagnosticData;
@end

Il DiagnosticController mantiene una lista di puntatori __unsafe_unretained in modo che gli oggetti possano rimuovere se stessi dalla lista dei provider quando dealloc. Sono andato con __unsafe_unretained per renderlo compatibile con le versioni precedenti di iOS anziché, ad esempio, NSHashTable con l'opzione NSHashTableWeakMemory . Se ho un po 'di tempo in futuro, potrei raggruppare DiagnosticController per consentire più backing store a seconda del runtime.

    
risposta data 31.07.2014 - 15:36
fonte
1

Mi piace il tuo approccio di notifica meglio del tuo approccio a blocchi. Raccomando che ogni sottosistema o componente pertinente implementino un'interfaccia in grado di restituire le informazioni sullo stato quando richiesto. Si registrerebbero quindi con un servizio di raccolta dello stato centralizzato. Nei momenti chiave, il servizio di stato può recuperare lo stato da ciascun componente registrato, creare un rapporto e collegarlo all'e-mail del servizio clienti. Penso che il recupero sia effettuato manualmente o tramite il sistema di notifica iOS.

BTW, se gli oggetti che possono fornire lo stato sono transitori, potrebbe essere necessario fare attenzione che il servizio di raccolta dello stato non contenga riferimenti quando non sono più necessari. Un riferimento debole potrebbe aiutare qui.

    
risposta data 31.07.2014 - 00:37
fonte

Leggi altre domande sui tag