Qual é a diferença entre commit () e apply () em SharedPreferences

Estou usando SharedPreferencesno meu aplicativo Android. Estou usando ambos commit()e apply()método de preferência compartilhada. Quando uso o AVD 2.3, ele não mostra erro, mas quando executo o código no AVD 2.1, o apply()método mostra erro.

Então, qual é a diferença entre esses dois? E usando apenas commit()posso armazenar o valor da preferência sem nenhum problema?

apply()foi adicionado na versão 2.3, ele confirma sem retornar um valor booleano indicando sucesso ou falha.

commit()retorna verdadeiro se o salvamento funcionar, falso caso contrário.

apply() foi adicionado quando a equipe de desenvolvedores do Android percebeu que quase ninguém notava o valor de retorno, portanto, aplicar é mais rápido e assíncrono.

http://developer.android.com/reference/android/content/SharedPreferences.Editor.html#apply ()

tl; dr:

• commit()grava os dados de forma síncrona (bloqueando o thread do qual é chamado) Em seguida, ele informa sobre o sucesso da operação.
• apply()agenda os dados para serem gravados de forma assíncrona . Ele não informa sobre o sucesso da operação.
• Se você salvar com apply()e ler imediatamente através de qualquer método getX, o novo valor será retornado!
• Se você telefonou apply()em algum momento e ele ainda estiver em execução, todas as chamadas para commit()serão bloqueadas até que todas as chamadas de aplicação anteriores e a chamada de confirmação atual sejam concluídas.

Informações mais detalhadas da documentação SharedPreferences.Editor :

Diferentemente do commit (), que grava suas preferências no armazenamento persistente de forma síncrona , o apply () confirma imediatamente suas alterações nas SharedPreferences na memória, mas inicia um commit assíncrono no disco e você não será notificado sobre falhas . Se outro editor neste SharedPreferences fizer uma confirmação regular () enquanto uma aplicação () ainda estiver pendente, a confirmação () será bloqueada até que todas as confirmações assíncronas sejam concluídas, assim como a própria confirmação.

Como as instâncias SharedPreferences são singletons em um processo, é seguro substituir qualquer instância de commit () por apply () se você já estava ignorando o valor de retorno.

Não se espera que a interface SharedPreferences.Editor seja implementada diretamente. No entanto, se você o implementou anteriormente e agora está recebendo erros sobre a falta de apply (), basta chamar commit () em apply ().

Estou com alguns problemas ao usar apply () em vez de commit (). Conforme declarado anteriormente em outras respostas, o apply () é assíncrono. Estou com o problema de que as alterações formadas em uma preferência de "conjunto de cadeias" nunca são gravadas na memória persistente.

Isso acontece se você "forçar a detenção" do programa ou, na ROM que eu instalei no meu dispositivo com Android 4.1, quando o processo é encerrado pelo sistema devido a necessidades de memória.

Eu recomendo usar "commit ()" em vez de "apply ()" se você deseja que suas preferências estejam ativas.

Use apply ().

Ele grava as alterações na RAM imediatamente e aguarda e as grava no armazenamento interno (o arquivo de preferências real) depois. A confirmação grava as alterações de forma síncrona e direta no arquivo.

• commit()é síncrona, apply()é assíncrona

• apply() é a função nula.

• commit() retorna true se os novos valores foram gravados com êxito no armazenamento persistente.

• apply() garantias completas antes de mudar de estado, você não precisa se preocupar com os ciclos de vida dos componentes do Android

Se você não usar o valor retornado commit()e estiver usando o commit()thread principal, use em apply()vez de commit()

Os documentos dão uma boa explicação da diferença entre apply()e commit():

Ao contrário commit(), que grava suas preferências para armazenamento persistente de forma síncrona, apply()confirma suas alterações na memória SharedPreferencesimediatamente, mas inicia uma confirmação assíncrona no disco e você não será notificado de nenhuma falha. Se outro editor SharedPreferencesfizer isso regularmente commit()enquanto a apply()ainda estiver pendente, o commit()bloco será bloqueado até que todas as confirmações assíncronas sejam concluídas, assim como a própria confirmação. Como SharedPreferencesinstâncias são singletons em um processo, é seguro substituir qualquer instância commit()por apply()se você já estiver ignorando o valor de retorno.

Partida javadoc:

Diferentemente do commit (), que grava suas preferências no armazenamento persistente de forma síncrona, o apply () confirma imediatamente suas alterações nas SharedPreferences na memória, mas inicia um commit assíncrono no disco e você não será notificado sobre falhas. Se outro editor neste SharedPreferences fizer um commit regular () enquanto um> apply () ainda estiver pendente, o commit () bloqueará até que todos os commit assíncronos sejam concluídos, assim como o próprio commit

A diferença entre commit () e apply ()

Podemos ficar confusos com esses dois termos, quando estamos usando SharedPreference. Basicamente, eles provavelmente são os mesmos, então vamos esclarecer as diferenças de commit () e apply ().

1. valor de retorno:

apply()confirma sem retornar um booleano indicando sucesso ou falha. commit() retorna verdadeiro se o salvamento funcionar, caso contrário, falso.

2. Rapidez:

apply()é mais rápido. commit()é mais lento.

3. Assíncrono x Síncrono:

apply(): Assíncrono commit(): Síncrono

4. Atômica:

apply(): atômico commit(): atômico

5. Notificação de erro:

apply(): Não commit(): Sim