Home/ Questions/Q 205995
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T17:36:21+00:00

I’ve a iPhone App that relies heavily of TableViews and SQLite database. Where do

  • 0

I’ve a iPhone App that relies heavily of TableViews and SQLite database. Where do you store the data? In my case I pull data from the web in App Delegate and store it in AppDelegate and save it to DB at regular intervals.

The rootviewcontroller is a tableview that reads the appdelegate object and populates itself.

But, according to Evan Doll (stanford lectures) it seems that storing data in AppDelegate is seemingly a bad design. I don’t want to end up paying for it later. Could anyone suggest a better alternative to this solution?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    For my own use, I have created some kind of MVC construction. I have a DataManager (a singleton), which holds all the required data (mostly represented in Models; plain NSObjects) in array’s or dictionaries.

    Views (Nib files and ViewControllers) talk to the DataManager to get their data via get functions .. if the data is already present in the DataManager, it returns the data (via a Notification). If not; it forwards the call to a Controller which then gets it.

    In that Controller, I seperate the call in an offline/online modus (probably not important for you) where if online, the call is an XML request, and if offline the call is to a SQLite database.

    The Controller can then set the data on the DataManager, and dispatch a Notification to the View.

    Then the cycle starts again, where the View can access the data through the DataManager..
    All of this happens in asynchronous calls, hence the Notifications (if I’d let the DataManager or Controllers mess with the Views, it would not be thread safe).

    My AppDelegate only does the very first initialization of the main view, controllers and DataManager, and those then take over.

    It is good to have your models (data) in a central place, so you could easily access it throughout every class, without creating to much class dependencies.

    I split up most types of functionalities into separate classes also, like the DataManager for data, a DownloadManager for asynchronized URL requests, an XML Parser, a factory to build models from NSDictionaries, a DatabaseConnector, etc, etc.

    • 0