Best practice per l'aggiornamento dei dati utente durante l'aggiornamento delle versioni del software

Question

Best practice per l'aggiornamento dei dati utente durante l'aggiornamento delle versioni del software

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

5

Nel mio codice controllo la versione corrente del software all'avvio e la confronta con la versione memorizzata nei file di dati dell'utente. Se la versione è più recente, chiamo metodi diversi per aggiornare i vecchi dati alla versione più recente dei dati, se necessario.

Di solito devo creare un nuovo metodo per convertire i dati con ogni aggiornamento che modifica in qualche modo i dati dell'utente, e non posso rimuovere quelli vecchi nel caso in cui qualcuno abbia perso un aggiornamento. Quindi l'app deve essere in grado di passare attraverso ogni chiamata di metodo e aggiornare i propri dati fino a quando non ottengono i loro dati attuali. Con set di dati più grandi, questo potrebbe essere un problema.

Inoltre, recentemente ho avuto una breve discussione con un altro utente di StackOverflow e ha indicato di aggiungere sempre un timbro data al nome file per gestire le versioni dei dati, sebbene il suo ragionamento sul motivo per cui questo era meglio di memorizzare i dati della versione nel il file stesso non era chiaro.

Poiché raramente ho visto la gestione delle versioni dei dati degli utenti nei libri che ho letto, sono curioso quali sono le migliori pratiche per la denominazione di file di dati utente e procedure per l'aggiornamento dei dati più vecchi a versioni più recenti.

Modifica: Il 'timbro data' è nato da una discussione qui:

link

Poiché la domanda è troppo aperta, dovrei dire che sto cercando le procedure consigliate per l'aggiornamento dei dati utente tra le versioni.

Se possibile, sarebbe bello vedere le pratiche iOS / objective-c, ma non è obbligatorio.

versioning ios objective-c software-updates

posta TigerCoding 27.11.2011 - 17:24

fonte

4 risposte

Leggi altre domande sui tag versioning ios objective-c software-updates

best practice per testare le app di backbone.js con jasmine? Come implementare un'architettura cluster leggera per un'applicazione distribuita

score 1 · Answer 1

Le date sono utili quando hai bisogno di informazioni aggiuntive su quando qualcosa stava accadendo. Non c'è nulla di male ad aggiungerli a un file che contiene già un numero di versione.

Tuttavia, non è possibile utilizzare un timestamp come unico indicatore di quale versione è in esecuzione, quindi decidere cosa deve essere aggiornato. Solo perché hai rilasciato 2 aggiornamenti nell'ultimo anno non significa che qualcuno con una data di installazione all'interno di tale intervallo stia utilizzando una di queste due versioni. Se l'utente ottiene una copia del programma di installazione, può mantenerlo per future installazioni pulite e si aspetta che il software si aggiorni autonomamente invece di ottenere la versione più recente.

score 1 · Answer 2

Come hai notato, non esiste un reale vantaggio di una data rispetto al numero di versione. E devi mantenere le vecchie conversioni per supportare le persone che saltano gli aggiornamenti (mia moglie è cattiva in quel modo).

Una cosa a cui potresti pensare è una sorta di inventario del numero di persone su ciascuna versione, in modo che tu sappia quando puoi rilasciare vecchi aggiornamenti. Apple dovrebbe essere in grado di fornirti quelle statistiche (ma non ne ho idea se lo fanno). Oppure potresti aggiungere una funzione ping che ti invierebbe il numero di versione e un id univoco ogni volta che l'app viene eseguita per la prima volta dopo un'installazione o un aggiornamento.

score 0 · Answer 3

Il vantaggio immediato di un timestamp che posso vedere è che hai una sequenza. Suggerirei di inserire il timestamp in un file di costanti, al momento della compilazione. Questo rende il timestamp indicativo della versione di build (non il tempo di installazione / aggiornamento).

Oltre a questo, direi che dipende da te. Puoi facilmente scrivere una classe per aiutarti con la sequenza delle versioni, a seconda del metodo di denominazione della versione (1.x, 1.2.x, ecc.).

score 0 · Answer 4

In termini di iOS / obiettivo-c, una delle migliori pratiche è utilizzare valore-chiave dati, insieme a NSCoder . Ciò ti consente di aggiornare i dati più vecchi in modo abbastanza diretto.

Un'altra opzione è semplificare le cose fino a un NSDictionary e salvare i dati in formato JSON (o simile). Questo ha il vantaggio di un uso comune significativamente più semplice, il riordino degli elementi di dati tra le versioni è più facile da gestire (in genere non devi fare nulla) ma gli svantaggi di porre limitazioni sui tipi di dati che possono essere utilizzati e dover controlla i valori mancanti come processo separato.

Se il formato del valore di una chiave cambia, in alcuni casi è possibile ottenere la conversione automatica durante il caricamento (ad esempio: [valoreValore intValue] - > [valoreValore stringaValore] se dataValue viene modificato da numero intero a stringa) . Se necessario, puoi controllare il tipo manualmente (isKindOfClass / isMemberOfClass) e nascosto quando necessario.

Riguardo all'opportunità di utilizzare un timbro data oltre a una versione nei dati, che dipende da ciò che si sta tentando di realizzare. Se vuoi semplicemente tenere traccia della compatibilità dei dati tra le versioni dell'applicazione, allora un timbro data non ha più significato di una versione # (e forse meno poiché è più difficile relazionarsi all'app).

Personalmente, io uso il metodo NSDictionary / JSON dove posso, e uso la configurazione di NSCoder solo quando ho dati complessi. Se disponi di strutture di grandi dimensioni che ritieni possano necessitare di aggiornamenti più volte nel corso della durata della tua applicazione, suggerirei di utilizzare l'installazione di NSCoder poiché fornisce il metodo più pulito per aggiornare i dati al volo con il minimo sovraccarico. / p>

Infine, per la scala C uso un setup per le strutture che fornisce un semplice controllo della versione e la verifica dei dati. Ogni struttura che I (può) deve essere in grado di aggiornare è strutturata come qualcosa:

version
element1
.
.
elementX
id_tag

La versione # è leggibile in un editor esadecimale (es: 0x00010000 == 1.0) e il tag è un ResType a 4 byte (es: 'pDat', 'TXT2', ecc.). Ho inserito il tag id alla fine dopo aver eseguito istanze di altri programmatori che aggiornavano le mie strutture e non aggiornavano la versione #. In questo modo, qualsiasi codice che tenta di utilizzare i nuovi dati fallirà perché è stato verificato che i dati basati sulla vecchia versione # non trovino il tag id nel punto corretto. Non è a prova completa (la modifica di un byte da 4 byte a un float da 4 byte passerebbe inosservata ad esempio) ma è decente, economica e utile quando si visualizza un file di dati con un gruppo di queste strutture in un editor esadecimale.

Spero che ti aiuti.