2017-02-22 127 views
1

我已經瀏覽了堆棧溢出的很多答案,但還沒有找到任何回答這個問題的答案。在iOS應用程序中存儲數據的最佳實踐?

我有一個應用程序,您可以在downloadVC下載數據(還有很多其他的VC)。我希望能夠在下載VC時訪問當前用戶和下載的數據,而無需重新下載數據。

我看到目前爲止的選項有:

  • 製作用數據一個單,我可以在應用的各個點訪問(感覺就像是最簡單的方法,但人們已經警告我單身AREN」好)。
  • 製作下載VC的類var。 (這是我至少理解的解決方案,類var的範圍是什麼?是否與製作單例相同?)
  • 傳遞它(這對我來說不起作用,因爲應用程序太大有它的每一個VC
  • 之間),通過將其保存到用戶的默認值,(如何快速在訪問一些用戶默認?)

請告訴我,如果這個問題不適合堆棧溢出規則?

+0

它取決於,你想下載什麼。您是否想要下載文件並將其存儲在可從任何應用程序視圖訪問的應用程序中? – Krunal

+0

是否有併發使用downloadVC的數據? –

+0

根據「數據」的實體,答案會改變。您所下載的數據在大小方面有多大?你是否需要在沒有下載它的情況下獲取此下載的數據?我們需要更多的上下文 –

回答

2

單身人士通常使用一個靜態變量來實現,所以你的第一個和第二個選項非常相似。

最近在開發社區有一個「單身是邪惡的」派別。

我個人認爲他們有自己的位置,有時可以清理你的設計。我最近在一個由「單身人士是邪惡的」邪教組織成員設計的項目中工作,後來荒謬地將一個數據管理器對象傳遞給項目中的所有其他對象,導致大量開銷和更多比物體掉落時的一些錯誤要多。

沒有人回答。您需要權衡應用程序不同方法的優缺點。

雖然我會提醒不要使用UserDefaults。這是爲了保存像用戶偏好設置這樣的小數據,而不是大數據對象。

0

這取決於文件複雜度&的大小。如果你不需要解析內容,或者它們很容易解析,但是它的大小很大,那麼我建議使用Documents文件夾並從那裏檢索它,如果它很小或涉及複雜的處理,然後singleton代理作爲經理人,我認爲是合適的。

1

簡單的回答是,是的,你使用單身

這是完全正確的。

注意,無論您使用

  • 的SQLite。迅速,

  • 核心數據,

  • realm.io,

  • 寫入到文本文件中,

  • 一個巴斯如火力地堡或Back4app(又名解析),

  • 或者從字面上看,只是「保持陣列」(「在內存中」),

是的,你的問題的答案是你將有單身人士,這是你「保持 - 訪問」的東西。完全正確。

這似乎是你在這裏問的。

鑑於...

...如果你還接着問:「什麼是最簡單的/最佳/最現代的方式(」我的數據單「)本地存儲在我的應用程序數據」時,在2017年真實世界的答案是

realm.io

您之前使用蘋果公司的核心數據。 (a)壯觀(b)極其困難。不過重要的是:realm.io和SQLite在上都是一樣的,都可以在的Android和iOS上使用;在很多情況下,在今天的真實世界項目中,這消除了核心數據的考慮。

但是,所有這些都沒有實際意義。不要忘了...

我們現在生活在一個「巴斯世界」

你不能如。 「獲得編程iOS或Android的工作」。您因爲您在Firebase,Parse,PubNub,Cloudbase等方面的優秀/專業知識領域而獲得工作。無論是更好還是更糟糕的是,能夠在Xcode,Studio中移動按鈕和表格,實際上已經不是什麼了。 (像GPU編程,動態網格等類似的超特殊技術是微不足道的,這是例外。)同樣,假設你是一個開發自己的應用程序或啓動的業餘愛好者:在這種情況下,再次完全和完全關於你的後端工作。 (這同樣適用於遊戲或商業/社交應用程序。)根本沒有「本地,靜態」應用程序。 (同樣,也同樣適用於遊戲或商業/社交應用。)

(注確實是realm.io,這是保持數據「的」簡單的,明顯的方式應用程式,這些天 - 事實上,這些傢伙有/是我們可能都會在一年內使用Realm.io而不是Firebase。)

因此,在某種意義上,您的問題的答案是某種意義上的問題如Firebase或back4app。但是:然後在你的應用程序中,你把它集中到一個單例中,的確是(你的問題的第一部分)。

不過需要注意的....................

這是極不可能,在入門級的水平,任何的,這將是相關:只需將數據保存在一個數組中!這裏的所有都是它的。好吧,一旦用戶碰巧重新啓動設備或應用程序,十億年後,應用程序將重新加載數據。所以呢?

注意你的「在這裏得到的數據」一個共同的名字 - 辛格爾頓是

本地

所以,

import Foundation 
often .. import SQLite, Realm, Firebase or whatever 

public let local = Local.shared 

open class Local { 
    static let shared = Local() 

    fileprivate init() { 
     print("'Local' singleton running AOK") 
    } 

    // could be this simple.. 
    var clients:[String:[Blah]] = [:] 
    var stock:[String:String] = [:] 
    func loadStockInfoFromWWW() { ... } 
    func calculateQuantityInfoOrWhatever() { ... } 

    // or it could be more like this.. 
    func reloadClientsFromParse() { ... } 
    func sendNewDataToFirebaseParse() { ... } 

    .... etc 

你然後就從任何地方訪問它在你的應用程序一樣

local.updateFromWeb() 
height = local.stock["ladders"][idNumber].size.h 

等等。

就是這樣。

(在單code style一個字。)

+0

雖然使用單例很簡單,但很少是正確的解決方案。它會導致各種潛在的問題。 – rmaddy

+0

我不像某些人那樣反單身,但我也不相信單身永遠是答案。同樣,您對Core Data的拒絕也是誇大其詞。核心數據是一個功能強大的框架,具有許多優點。確實,它不在Apple的生態系統之外提供,但這並不總是決定使用什麼框架的決定性因素。 –

+0

嘿DC。你實際上必須有一個單例作爲在應用程序中觸摸數據的「點」。正如所說的「屏幕或指南針」是設備中的單身人士。 – Fattie

1

基本上,添加視圖控制器內的任何聯網的邏輯是第一個大的錯誤,你可以做。所以將它移到另一個只負責發送網絡請求和處理響應的類。然後,當你下載了數據時,你可能需要一些東西來管理緩存 - 不管它是一組大文件還是一對小字符串,邏輯將是相同的 - 要有所有這個緩存由​​一個對象控制。這個緩存管理器可以將對象保存到本地文件,使用CoreData或者只是將這些對象保存在內存中 - 這是由您決定的,具體取決於您創建的應用程序類型。

現在,緩存管理器基本上可以是視圖控制器的端點,因爲它可以在請求成功後下載數據並將其返回給視圖控制器,或者立即返回。視圖控制器根本不需要知道任何網絡。

但是,視圖控制器將如何找出有關緩存管理器

你可以傳遞給它的引用,但你已經說過這是你的應用程序不可能的。所以基本上另一種解決方案是使用討厭的singleton模式。我個人認爲這是一種糟糕的模式,但是如果沒有它,你就不能創建任何應用程序,因爲你總是必須至少有一個單例,這就是AppDelegate

總之,一個好主意,可能是創建一個單獨的類(或者甚至使用的AppDelegate爲目的),這將是負責處理負責類之間的依賴關係網絡,則高速緩存管理器 ,以及您可能需要在應用程序後面執行某些邏輯的任何其他類。這實際上是一種稱爲依賴注入容器的模式。它可以讓你通過這個容器輕鬆訪問你的模型類,而沒有大量的單例會最終讓你感到困惑,也不會創建一些傳遞模型對象的荒謬邏輯。

+0

@JoeBlow也許,雖然我提到了AppDelegate,但我沒有說清楚,我知道事實上,單身在iOS開發中很重要(我不會寫關於Android的,因爲我在該領域有0經驗)。但是,當涉及到設計一個好的和可持續的代碼時,他們真的不應該被過度使用。另外,我認爲簡單的使用方式是令他們討厭的主要原因 - 僅僅因爲懶惰或缺乏經驗的開發人員經常將其視爲每個架構挑戰的魔法解決方案。 – user3581248

相關問題