到目前爲止,我一直在讀,我不應該使用SharedPreferences的,因爲這對喜好
最後,歡迎您使用SharedPreferences
爲任何你想要的。他們爲優化爲用戶偏好。
還是我應該使用savedInstanceState包,因爲這是不安全的
這只是select scenarios。例如,如果用戶被分散注意力,則用於保持用戶的部分填寫表單值。這不是一個長期的存儲解決方案。
建議的方法是將OnPause中的數據保存到數據庫或文件(這對我來說足夠了)並將其恢復到OnResume中。
根據數據的性質和用戶交互,保存數據的方案和解決方案很多。在聊天應用程序中,用戶輸入和從聊天服務器獲得的聊天消息的功能與您在文字處理器中所做的功能會有很大的不同,這與您在遊戲中所做的有很大不同,比你在一個流媒體播放器做什麼很大的不同,等
該應用程序只能通過在MainActivity
這是不正確的,除非你採取非常具體的步驟執行此輸入。如果用戶在您的應用程序中,然後移動到另一個應用程序(例如,按HOME),您的應用程序的進程可能會被終止,而您的應用程序在後臺。如果用戶返回到您的應用相當快,但是(例如,在半小時內),比如通過概覽屏幕/最近任務列表,Android會嘗試將用戶返回到他們最後的狀態。這可能是你的任何活動。
所以我想我恢復在其OnResume方法的狀態。
每個活動都負責自己的狀態。某些狀態可能會被共享(例如,單身POJO緩存管理器)。但是一個活動不應該假設之前已經爲它設置了狀態。
這是否意味着我應該將應用程序的狀態存儲在應用程序中所有活動的OnPause方法中?
同樣,這很大程度上取決於您在應用中的操作。答案可能是「存儲用戶按下按鈕時的狀態」或「存儲用戶滑動時的狀態」或「存儲從服務器傳入的MQTT消息中獲取的狀態」等。
我想只有當用戶離開我的應用程序存儲狀態,他返回
恕我直言,恢復它的人,你想存儲狀態的狀態變化,一般的時候。在適當的緩存中,「恢復」速度非常快,當應用程序處於活動狀態時,只有在您擁有大量大數據(並且緩存開始彈出值)或您的進程已終止並重新啓動時,纔會進行緩慢操作。
我想你應該忽略它並用SharedPreferences來做。它的簡單和快速。 –
爲什麼你不能使用共享首選項?對於這種事情它工作得很好。 –