I wanna store a list of people while each person has some pieces of info associated with him. for example location and phone number and e-mail address.
i wanna store in this list around 10,000 persons.
After that i want to search this list dynamically (after typing each letter , the database is searched for new matches to the string written in the search box)
[if there is a scientific name for this search process , let me know it please :) ]
My Question is What do you think i should use in my implementation for best performance?
SQLite,
XML, plist
???
and is there any tutorial about this kind of search ?
Thanks in advance
You should definitely be using SQLite for this, and using the CoreData abstraction layer would probably be a good ideas as well unless you are already a pro at SQLite calls. The documentation for Core Data would be a good place to start on how to do this. Apple provides several examples that are similar to what you are doing.
You should use a database for this. Searching in a database is a lot quicker than searching in a file. Not quite sure how much memory it would take but it might even be possible to load it all in memory if it is just a list of names. That is how it would be done on a desktop application for sure, but might not work on an iPhone which has a lot less memory.
SQLite for the win!
Related
I am asking what code to use to save user data in the app so that it is perpetual, even after the app is closed and reopened. I watched a few videos but my code isn't working.
I'm not interested in fixing code, I want to understand the process so I can reapply. Can anyone help me to understand how to do this and explain it in a way that makes sense for long term app development.
It will differ by application, depending on how much data and how it's organized.
If it's simple stuff, look at NSUserDefaults. If it's complicated and represented as objects, look at Core Data. If there's a lot of it and you see it as table rows rather than objects, you can use the sqlite3 database directly. If it has to be shared with other users or by other apps, start thinking about an external server or "the cloud".
There's no single right answer but those options should get you thinking about requirements.
As an exercise, I'm trying to rebuild the Notes App and was wondering what the best file system for a notes app would be?
I guess these are the requirements:
1) Not all notes should be loaded at the same time (lazy loading); i.e. I don't want to have all notes in one huge NSMutableDictionary or NSMutableArray -- so ideally, I guess that a separate file for each note would be a good idea
2) Notes should be searchable. Again, I have no idea what is best suited, but my feeling is that searching through a huge string containing all notes may not be the best solution.
3) Export. I guess this is not really that important when thinking about the data structure, but if I wanted to do a dropBox or iCloud sync, is there any file system which is more suitable than another? Especially if I wanted the user to be able to edit separate txt files for each note they've done?
Any ideas and suggestions where to start would be very much welcome! Thanks in advance.
Core Data with spotlight export will be your best option.
The real trick is make the model support detailed searches with things like keyword entities and linked-list type structures. These are a lot of work but they can make searching almost instantaneous.
I know little about Core Data. Read: I've read a few tutorials, kinda understood how it works, but never tried to use it in any of my apps. That said, I'd like to know if it's worth the effort to use it in the app I'm developing. Note that I'm not asking if I should learn Core Data, but if it's worthwhile to invest time learning it for this specific app I'm making, or if I should use archiving instead, ship the app, and only then learn Core Data in my spare time.
Basically my app reads a list of items from a web service, and needs to save the last N items. The user should also be able to bookmark items, so that's another thing I should store somewhere. So, right now I'm just archiving a subarray with range 0-N of the latest items. Does it work? Yes. Is it efficient, and the best way to achieve this? That's my question for you actually.
My doubt comes from the fact that whenever I see someone asking 'Is Core Data overkill for my project?' everyone suggests to use it anyway.
If the amount of data you need to persist can easily fit into memory without degrading the apps performance then you should just archive the array and ship the app.
Core Data gives a lot of advantages when handling large and complex data sets. It gives a lot of advantages in maintaining and upgrading a shipped app. However, those advantages should not get in the way of shipping an otherwise completed app. Later, you can always write code to migrate a shipped version to a Core Data version. It's more work, but hey, at least you've got a shipped app to work on.
I've seen a lot of small startups/developers come and go and the major factor that separates the successful from non-succesful is that the successful actually ship/release product. You can spend forever polishing an app but the key thing is knowing when to say, "It's good enough" and get the thing into the user's hands.
If it's a small list and you have the data in NSDictionary or NSArray collections, use writeToFile:atomically: instead for flat file XML Plist storage.
I still think you should learn Core Data eventually, but.
I'm looking for suggestions on the best way to implement a full-text search on some static data on the iPhone.
Basically I have an app that contains the offline version of a web site, about 50MB of text, and I'd like for users to be able to search for terms. I figure that I should somehow build an table of ("word", reference_to_file_containing_word) or something, put that into either Core Data or just sqlite, index the "word" column, then have the search facility search the table for search terms and take the intersection of the sets of results for the terms or something.
That wouldn't allow people to search for phrases but it would be pretty easy and probably not too slow.
I'd like to just use existing SDK features for this. Should I use Core Data or sqlite?
Does anyone have any other ideas on how this could be done?
You want to place every word in the document in its own row in a database? That's going to take up even more space than the document itself.
I would recommend just searching through the text; regex is actually pretty fast. Otherwise, you could implement Boyer-Moore fairly easily.
[Edit] If you insist on creating an index of words, you can't beat a trie. It would be faster than using a database, and most likely take up less space than the documents themselves (unlike the database)
The answer is FTS3 for SQLite. Google it, there are many tutorials on how to get it working on iPhone.
And the easy way to use SQLite on iPhone is using FMDB.
Is there any "Best Practice" approach to storing persistent static data for iPhone apps?
I have an app that reads a dictionary of approximately 1000 items many of which are arrays. I started out using a single plist for this and it has become somewhat unwieldy especially since much of the values are HTML strings.
Is there a better way for me to approach this? I plan on scaling this app significantly and I obviously don't want to change my approach midstream.
I've googled for iphone data storage and variants but have come up short for anything even touching on a best practice.
It sounds like you intend to distribute some data with your application. A property list is probably the easiest to maintain, but it will be loaded into memory all at once. This could eat up a lot of the device's memory.
An sqlite database, on the other hand, will load only the data you request. I'm not sure how your data is structured, but you could quite easily create key-value pairs with a single database table. (A single table with a key column and a value column) Then, if it were me, I'd write an Objective-C class to wrap the database queries so I can write easy statements like:
NSString *welcomeText = [[MyData sharedData] dataWithKey:#"WelcomeText"];
Getting the data into the database in the first place doesn't have to be difficult. You can use the command line sqlite3 utility to bulk load your data. There's a command called .import that will import your data from a text file.
Hope this gets you moving in the right direction!
I'd go with a sqlite solution. The apps I am working on now, which are just apps to help me learn iPhone development, mostly all use sqlite. I use the sqlite plugin for firefox to help with maintaining the database, which works surprisingly well. https://addons.mozilla.org/en-US/firefox/addon/5817
As Alex suggested using a wrapper class would also be the best way to go.
Don't forget with 3.0 you can use a CoreData layer around SQLlite which may make it more appealing to you.
If you don't need to store any relational information about your data, why not just use files? There will be some wasted filesystem space, but plain files might be the most memory and CPU efficient solution, depending on the size and number of your items.
I've never developed an iPhone app but I have played around in the filesystem. I have seen sqlite databases floating around various places of the phone. I'm pretty sure it uses a sqlite database to store your calendar entries.
I would use sqlite. It is already there, easy to use, and will provide the most flexible path for expansion in the future.
I use sqlite for static data in my iPhone apps all the time.
All I did was save state when the app is shut down. I used a file for that.
sqlite sounds perfect for your app. sqlite is pretty easy. I've used it in Adobe AIR apps.