Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

BoxerRobban472

macrumors member
Original poster
Sep 12, 2013
66
1
Gothenburg, Sweden
Hello everyone!

I have been learning iOS programming for a while now, and even though I don't think I know near enough to make this kind of app, I would still like to draft the idea and see what I would have to look deeper into:

So the general idea for this app, is for it to be a searchable database made of text documents. Say for example that my database was made of three essays I've written for school. If I then searched for a word (or number etc.) a function would compare the search-word with every word in every document and present the most relevant result. (If I search for the word 'apple', for instance, and it occurs three times in one document and two times in the other, I would want these documents to be displayed in descending order). I hope you understand what I mean.

I'm certain I would have to look into databases and how they work on a phone, but I'm also a little concerned about what type of format the text documents would have to be in, so that the word-finding function could search through them.

I might be completely out of line here, but in any case I'm looking for someone who can point me in the right direction. I hope you understand what I mean.

Thanks in advance!:)
 
I assume the purpose of this is to learn how to do this.

Start with plain text documents. You'll need to import the documents into the app one by one. The importing step will read the document and store the info for each word in your database. Searching will look at the database, not the files. You'll display your results most likely in a UITableView. Tapping the row for a result will open the document and go to the line where the word was found.

I'm sure there are a lot of details to figure out about what info to store in the database. You probably don't want to store common words like 'a' 'the' and others (but maybe you do, I don't know).

Have fun. Tell us how it turns out.
 
  • Like
Reactions: BoxerRobban472
I assume the purpose of this is to learn how to do this.

Start with plain text documents. You'll need to import the documents into the app one by one. The importing step will read the document and store the info for each word in your database. Searching will look at the database, not the files. You'll display your results most likely in a UITableView. Tapping the row for a result will open the document and go to the line where the word was found.

I'm sure there are a lot of details to figure out about what info to store in the database. You probably don't want to store common words like 'a' 'the' and others (but maybe you do, I don't know).

Have fun. Tell us how it turns out.

Thank you for answering, and yes, my intention with this is to learn.

That is exactly what I had in mind, and I'm going to set that as a goal! I remembered something though, I learned basic Objective-C programming from The Big Nerd Ranch Guide (2nd edition) and in chapter 17 a file is read in by using the stringWithContentOfFile-method and a fixed keyword is then searched for in the file. Maybe I could start with something like that but with a search function...

I also did some more searching and found recommendations of this tutorial: (http://www.raywenderlich.com/934/core-data-tutorial-for-ios-getting-started ) regarding Core Data which, according to what I found, seems to be the way to go when it comes to databases on iPhone. Based on a quick skim through, it seems to be a little over my head, but at the same time this was what i imagined when I first thought about databases. I don't know how much experience you have had with this, but do you think this is something someone (whom greatest accomplishment so far is a calculator-app (with GUI)) could comprehend and, to a certain extent, master? Or should I maybe begin with what I described first...

Again, thank you for your time!
 
I wouldn't be very interested in a solution that actually opened the files and searched through them to find the results of the search. That's OK for something like searching in a file that you're editing, like in Xcode, but if your goal is to have an index of the words in an unbounded number of documents you need a database.

Core data or sqlite/SQL are the most likely ways to do this. Which one will give the best solution is debatable. Core data might be harder to learn than SQL. I learned sqlite/SQL for an iOS database project I worked on. However, at that time Core data wasn't available on iOS.

If you do choose to learn sqlite/SQL look up FMDB, which is an objective-C wrapper for sqlite.
 
  • Like
Reactions: BoxerRobban472
It might be worth doing some homework on CoreData vs SQLite. I started out with SQLite because I thought that being closer to other SQL products would be an advantage. I just finished a book that went into the advantages of CoreData and it's worth looking into. CoreData is an object storage system, not a database. It offers functionality over SQLite that are worth looking into.

It might also be worthwhile to think about what you want to do long term. It takes time to master all these different things. IMO, the main advantage of CoreData is the ability to store objects.
 
  • Like
Reactions: BoxerRobban472
Thank you very much PhoneyDeveloper and KarlJay for your thoughts! Since I don't have much (or any) experience in the area, I can't really say too much but I feel like SQLite is the way to go. I have searched a little regarding CoreData vs SQLite and it seems as CoreData is mostly used for smaller projects. I'm going to continue searching but I think it might be better to learn something that is easier to use on both large and small scale compared to something that's mostly used for smaller projects.

On the other hand as you mentioned KarlJay, CoreData seems to have some functionality so I am definitely going to look into that! Thank you for your answers.
 
If all you want to do is search documents, you don't need either SQLite or CoreData. You can just put the documents into one directory and run thru the directory. Grab each file and do the keyword search. Loading documents into a database just to search them isn't needed, unless you have another reason to put them into a database. Maybe look into NSFileManager examples.
http://nshipster.com/nsfilemanager/
 
  • Like
Reactions: BoxerRobban472
If all you want to do is search documents, you don't need either SQLite or CoreData. You can just put the documents into one directory and run thru the directory. Grab each file and do the keyword search. Loading documents into a database just to search them isn't needed, unless you have another reason to put them into a database. Maybe look into NSFileManager examples.
http://nshipster.com/nsfilemanager/

Wow, really? This is actually exactly the scenario I had in mind and it seems easier to learn as well! For my project, I'm definitely going to go with this method but you all have really sparked my interest with SQLite and CoreData so I will probably (hopefully) look into that in the future:D (maybe it will be easier after learning to "manage" files in a directory). As you wrote, the only function I wanted was to search, but let's just say that I did have a database, what other functions or commands would I be able to execute?
 
Wow, really? This is actually exactly the scenario I had in mind and it seems easier to learn as well! For my project, I'm definitely going to go with this method but you all have really sparked my interest with SQLite and CoreData so I will probably (hopefully) look into that in the future:D (maybe it will be easier after learning to "manage" files in a directory). As you wrote, the only function I wanted was to search, but let's just say that I did have a database, what other functions or commands would I be able to execute?

Actually, there isn't much you can't do with a "file manager" system.

Consider: A database is just a way of storing data.

A "file system" _IS_ a database. It stores files and keeps an index of them. You can list, sort, and search the index of files, just like most other databases. You can load the index of files into an array and process them as you want.

Most databases are used to update and query the data quickly and some control access to the data so that two users don't update the same data at the same time.

Other databases offer specialized functions, fast query, stored procedures, triggers, export to other formats, sharing locks, etc...

This is the reason you would look at what a given database offers and look at what you want to do with the data.

Just like all systems analysis, the goal shouldn't be to "find a tool" to do the job, but to find the best tool for the job. Most companies side step the systems analysis and just pick a tool that will get the job done.
 
  • Like
Reactions: BoxerRobban472
Actually, there isn't much you can't do with a "file manager" system.

Consider: A database is just a way of storing data.

A "file system" _IS_ a database. It stores files and keeps an index of them. You can list, sort, and search the index of files, just like most other databases. You can load the index of files into an array and process them as you want.

Most databases are used to update and query the data quickly and some control access to the data so that two users don't update the same data at the same time.

Other databases offer specialized functions, fast query, stored procedures, triggers, export to other formats, sharing locks, etc...

This is the reason you would look at what a given database offers and look at what you want to do with the data.

Just like all systems analysis, the goal shouldn't be to "find a tool" to do the job, but to find the best tool for the job. Most companies side step the systems analysis and just pick a tool that will get the job done.

Thank you very much for explaining that to me, I can see the difference and understand why they are used in different situations. I'm really excited to get going with directories!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.