2009-03-03 27 views
5

Ho qualche codice nella mia applicazione che sembra qualcosa di simile:Perché Cocoa restituisce occasionalmente una stringa vuota?

char *hash = (char*) sqlite3_column_text(get_bookmark, 0); 
NSString* postHash = [NSString stringWithUTF8String:hash]; 

Questo funziona per me ogni volta; Non l'ho mai visto non lavoro. La maggior parte dei miei utenti non ha problemi (per quanto ne so). Tuttavia, trovo che postHash sia una stringa vuota (@"") per alcuni utenti un po 'di tempo.

Qualcuno può spiegare perché?

Alcuni più contesto/speculazione:

Questo sembra accadere solo su telefoni jailbroken. C'è qualcosa di diverso in loro? Capisco che di solito c'è meno memoria disponibile. Qualcos'altro che potrebbe contribuire qui?

postHash viene utilizzato in una cella di tabella e talvolta viene visto per essere popolato correttamente, quindi sono ragionevolmente fiducioso che la chiamata di database dovrebbe lavoro. In effetti, se il database ha anche una stringa vuota è a causa di un pezzo di codice molto simile, quindi la domanda rimane.

hash restituisce sicuramente con un valore non NULL. Se imposto un NULL qui, l'app si arresta in modo anomalo. Allo stesso modo, postHash non è nil in quanto ciò causerebbe anche il crash dell'applicazione (per lo stesso motivo).

Sto pensando che questo è probabilmente legato alla memoria. Se il metodo tenta di allocare troppa memoria prima che -didReceiveMemoryWarning possa essere chiamato cosa succede? So che, ad un certo punto, Springboard espelle l'app. Ma è possibile che Cocoa restituisca qui una stringa nulla piuttosto che il valore atteso? Ho sentito di alcune relazioni che, per quanto posso dire, possono essere state causate solo da una stringa vuota presente dove doveva essere presente qualcosa di più lungo.

Qualsiasi altra speculazione, teorie o idee sono benvenute.

+0

"Ma è possibile che Cocoa restituisca qui una stringa nulla anziché il valore previsto?" Una "stringa nulla" sarebbe NULL (la stringa C) o nulla (l'NSString).Una stringa vuota è del tutto diversa: è una stringa senza caratteri, mentre NULL/nil non è affatto una stringa. –

+0

Questa non è la mia comprensione di cosa sia una "stringa nulla". Quando dico "stringa nulla" sopra intendo "stringa vuota", cioè, "" in Objective-C o "" in C. Un valore nil/NULL causa l'arresto anomalo dell'app. –

+0

"Null" significa 0. Il carattere null è '\ 0'; cioè 0. Il puntatore nullo è 0. Non esiste una "stringa nulla" in C, perché se è nullo, non è una stringa; è solo 0. –

risposta

6

Tuttavia, trovo che per alcuni utenti lo postHash sia una stringa vuota per alcuni utenti.

Qualcuno può spiegare perché?

Perché hash è una stringa vuota (hash[0] == '\0').

+0

Sono d'accordo che questo sarebbe lo scenario più probabile ma, come notato nella domanda, sono abbastanza sicuro che non può essere una stringa vuota. –

+2

Non è "lo scenario più probabile"; è lo * solo * scenario. NULL ti fa un'eccezione. Qualsiasi stringa non vuota ti porta una stringa non vuota. Solo una stringa vuota ti dà una stringa vuota. Prova semplice: NSLog la lunghezza in (strlen (hash)) e la lunghezza fuori ([lunghezza PostHash]). –

4

Ho finalmente trovato la soluzione a questo. Ho intenzione di dare a Peter la risposta accettata perché ha ragione, ma il motivo per cui stavo ottenendo una stringa vuota è ... interessante.

Il database è popolato correttamente. Anche la query è corretta. La differenza tra il mio telefono e i miei utenti è che hanno telefoni con la prigione. E a quanto pare gli iPhone jail broken usano a volte una versione diversa di SQLite che si trova nelle versioni di spedizione di iPhone OS.

Il cambiamento nella versione ha esposto un errore nel mio codice che ha causato l'impostazione errata di uno dei parametri e sqlite3_column_text per restituire una stringa vuota.

+3

Deve esserci un modo per rilevare un telefono jailbroken e quindi rifiutare il supporto degli utenti. Quanto tempo hai sprecato per questo? Non è acceso – mxcl

+0

Difficile, ma penso che mi ci siano volute circa venti ore - e ho trovato la soluzione solo per sbaglio! Il rovescio della medaglia, stavano pagando i clienti. Tuttavia, ho detto che mi riservo il diritto di non supportare i telefoni con la prigione. Ho scritto di più sul blog delle app: http://www.yummyapp.com/2009/05/pirates-and-jail-break.html –

Problemi correlati