聊天應用程序vs REST應用程序 - 在活動中使用線程還是在服務中使用線程？

Question

在Virgil Dobjanschi的演講中，「開發Android REST客戶端應用程序」（鏈接here），他說了幾件令我吃驚的事情。包括：

• 不要在您的活動產生的線程中運行http查詢。相反，與服務進行通信來完成它們，並將信息存儲在ContentProvider中。使用ContentObserver來通知更改。

• 總是在服務中執行長時間運行的任務，從不在您的活動中。

• 當你完成它時停止你的服務。

據我所知，他在談論一個REST API，但我試圖讓它適應我對應用程序有的其他想法。我一直使用的API之一是使用長輪詢的聊天界面。有一個循環http查詢，其中大部分會超時。

這意味着，只要應用程序沒有被操作系統殺死，或者用戶還沒有專門關閉聊天功能，我就永遠不會使用該服務，並且它將保持打開狀態永遠。這看起來不太理想。

長期問題短期：

對於使用長輪詢來模擬推動和立即響應聊天應用程序，它仍然是最好的做法是使用服務來執行HTTP查詢和存儲信息的ContentProvider的？

Answer 1

請勿在您的活動產生的線程 中運行http查詢。相反， 與服務進行通信以執行它們， 並將該信息存儲在ContentProvider中 。使用ContentObserver 通知更改。

我還沒有查看演示文稿，儘管我已經查看了幻燈片。我對建議架構的ContentProvider部分有嚴重的保留。

始終在 服務中執行長時間運行的任務，從不在您的活動中。

每個人都有自己寵愛的「永遠」和「永不」的言論，包括我自己在內。我會毫不猶豫地把它放在「永遠」的範疇。使用Service作爲長時間運行任務的主基礎是一種很好的策略，但它也有其問題（例如，在屏幕旋轉中，如果沒有其他綁定連接，unbindService()將在下一個bindService()開始前破壞Service ，如果你有一個複雜的應用程序，留下你與連接簿記的gobs和gobs）。

對於使用長輪詢 模擬推動和立即響應 聊天應用程序，它仍然要 最佳實踐使用服務來執行HTTP 查詢，並存儲在 ContentProvider的信息？

這是一種做法。恕我直言，陪審團仍然非常清楚這是否是最佳做法。