Hello I'm new to this forum (signed up today... have always used it for reference in the past though) and new to iOS development (6 months), but not a new programmer. I'm creating an app in iOS 5 for iPad that will require the user to rapidly input and update data (mainly adding, subtracting , changing BOOL states, etc... with time between events less than 2 seconds at times) for numerous objects. It is currently designed to use a SQL database, but worry that with rapid entries and updating that the database will get corrupt if it is not opened and closed rapidly enough. Any suggestions or lessons learned from iOS/iPad/iPhone experience? Is SQLite a preferred method for rapid input or should I switch to something else? Thanks and taker easy!
Core data handles all of the database connections for you. Changing properties on your managed objects doesn't involve a connection to the database every time, it just updates the objects in memory. The database is updated when you save the context and probably periodically in the background - the point is, you don't have to worry about it.
Don't code around a problem that doesn't exist - write your app using core data, and if you get database corruption problems, investigate then. But I doubt you will have anything to worry about on that score.
Related
I have developed an application which works on iPhone-3GS, iPhone-4, iPhone-4S.
For start up process, it take 30 seconds on iPhone-4s , and take 50-55 seconds on iPhone-3gs. Tested on same network.(Its not an issue related to network or internet; In simulator it took only 5 second.)
In this start up process, App performs several actions like deletion of old data from Database, WebService calling and inserting response data into Database. Application calls almost 8 web service on main thread using performSelectorOnMainThread method(sequentially).
I am using SQLite and Compiled Query structure for insertion. I want to improve performance of application and want to reduce start up time taken by application.
Same back-end is used by Android team and they are also doing same thing. It takes 20 sec only on Galaxy note (Team android is using Object Relational Modal to communicate with Sqlite database ).
Is this the reason for faster performance ?
Is there anything that work same as ORM in Java for Objective-C to improve performance while dealing with Sqlite (processor specific , less time consuming)?
First thing is you should not be doing network operations (web service calls) on the main thread. That should be done on background threads. I don't know enough about using SQLite directly but with CoreData you can make "database" updates on background threads and just use the main thread for merging the two ManagedObjectContexts.
I imagine moving your WS calls to background threads (AFNetworking is a great framework btw), that you will see lots of improvement.
One example I have is a web-service based app that gets 7000 records from a SQL Server DB and creates an NSArray (data comes in as JSON) and that process takes 7-10 seconds. I further minimize the impact on the user by doing my auto-authentication process at the same time.
30 seconds is too long to have the user wait on something IMO.
14 best tips are available here Best Steps to increase performance of iOS App
In this tutorial, point 13 gives the info you required.
I have noticed that for a mobile application, saving on the main thread seems to take a bit when it compares to other applications on the device. Is it recommended to only save Core Data when the application enters the background or when an application closes instead of anytime items are added and sent / received from the api?
That's kind of a broad question, but I've found that saving core data after VewDidAppear statements is better than viewWill statements. Giving the user something to engage with and persisting makes it less noticeable than on a load. However, if a user is used to waiting for something like an activity loop, adding the save to that doesn't tax it too much (IMHO).
Not sure this help, just my experience.
I have read a few tutorials and did some search but I must be missing something.
I've had a bunch of different problems with sqlite on my iphone app the last few days.
The most common problem was crashing when I was doing inserts at the same time on different tables, not on the same table.
I can achieve several inserts using threads by the way, so I am sure there is concurrency.
So does the db lock the whole DB or just the table I am inserting information into?
I'm also looking into another possible problems who might be causing the crashes but this little piece of information would help a lot.
After further tests I can say with certainty that you can perform multiple inserts at the same time in the database as long as it is on different tables. Multiple inserts at the same time on the same table will throw an error.
The crashes I was having earlier seem to be related to the fact that I was init + alloc the db on each view I wanted to use it and then releasing it on each view.
After init+alloc only on the app delegate it solved the crashes.
Although you can have multiple instances of the same DB throughout your App it seems to be preferable to just having one in the App Delegate and accessing it as you need it.
This might not be entirely correct but was my conclusion after several hours searching and testing.
I hope this helps other people.
There are 5 types of locks, but all are related to the whole database file and not a table-lock, or not to mention row-lock.
Are you calling sqlite3_finalize at the proper times when you're done? I've noticed that failure to call sqlite3_finalize in sqlite will pretty much bring things to a halt.
Can you please give some suggestions on sqlite using on the iPhone?
Within my application, I use a sqlite DB to store all local data. Two methods can be used to retrieve those data during running time.
1, Load all the data into memory at initialization stage. (More memory used, less DB open/close operation needed)
2, Read corresponding records when necessary, free the occupied memory after using. (Good habit for memory using, but much DB open/close operations needs).
I prefer to use method 2, but not sure whether too many DB opening/closing operations could affect app's efficiency. Or do you think I can 'upgrade' method 2 by opening DB when app launches and closing DB when app quits?
Thanks for your suggestions very much!
First of all: use FMDB to access SQLite!
Then, create your own singleton "MyDB" class.
Every time you need the database, you do [MyDB instance] to get your FMDB instance.
That way you only have one DB open (in didFinishLaunching) an you close it when your app exits.
That's far and away the best way to use SQLite on the iPhone.
The other option is to use CoreData, something I find great for when you start with an empty database, but FMDB/SQLite works best for me if I have a set of data that's read-only.
Apple seems to suggest that you avoid preloading all the data during the startup in order to ensure faster and smoother startup. Supposedly you should only load data when/if the user needs it.
I am writing an iPhone app that uses SQLite. I am use to opening and closing my connections every time I use a database. However, I do not know if that is a good practice in the iPhone/SQLite environment. I want to know if I should open the database 1 time or if it is OK to open and close the database each time I use it. Please let me know.
I believe you should keep it open as long as you can, so data is cached in DRAM. Of course, you should also organize your transactions so you commit at logical points in time and maintain transactional integrity.
I would do as Matthew suggested: keep one connection opened for as long as your program is running.
Both answers seem right, but actually it depends from how often you're using it and how large is it. In case DB is large you should set larger page cache, but that leads to larger memory consumption and if access is rare - no reason for holding it up all the time (but if usage also small - large page cache won't help you also).
In case it's small - there is no reason to open/close it each time even with infrequent usage. But in average your resource consumption is higher with regular open/close. So all in all - don't reopen db each time you're using it.