Home/ Questions/Q 8512325
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T04:14:54+00:00

I have an app with a simple table stored in a common sqlite database.

  • 0

I have an app with a simple table stored in a common sqlite database. The app has a mainview and several other views say, view1, view2, ....,viewN. From a mainview, the user go to view1 by this code section:

screen.modalTransitionStyle=UIModalTransitionStyleCoverVertical;
        [self presentModalViewController:screen animated:YES];

in view1, the user will access the database, doing something, then update the database, quite view1 back to the mainview: 

[self dismissModalViewControllerAnimated:YES];

The user will do the same thing for the other views, i.e., accessing the database, doing something, updating the database, then back to the mainview.

My question is how should I organize the database in my case, using a singleton to create a common object to open the database at the mainview, then all views will access the database, updating it or each view will open the database, accessing it, then update individually or is there any other efficient way. Thank you

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As you describe the structure of your app being one threaded only – using a singleton is perfectly OK. You need to open the DB only once when the app starts and make sure to close it when the app ends or even when the app goes to background (of course then you need to open the DB when return from background too)

    By the way, I also tried to open and close the DB for each view – which also works fine. In this approach I also sometimes use a “dirty” flag, that is set to indicate that the DB needs updateing before closing – but that turned out to make no difference in performance.

    Instead of using a singleton you may also use a class variable or declare it within your app delegate, which is often done for the cotext of core data ( where the “context” in core data is similar to the DB in your case)

    What is important in whatever approach you use is that your DB will be in a consistent state all the time since your app can get “interrupted” by phone call for example.

    By the way, I tend to use core data more often on iPhone if circumstances allow, since core data takes care of many of the DB issues – only saving at consistent states needs to be done explicitly. But it really depends if your data is more a big DB or just “some” persitent objects/attributes.

    • 0