I want to create an iPad application that is pretty much just a catalog of products(say for example, cars) I will have around 500 products total, and each product is pretty much an image that will load up when the user requests it.
example:
Product_ID: 124
Name: 'myImage.png'
User types a product id, the image will show up on a UIImage.
I was wondering what would be the smartest approach to this problem? I was thinking about SQLite or NSArray. Where the id would be the product id, and the value would just be the location or name of the image to load. Creating a cache document folder? Any suggestions from people that have already experimented and created similar apps?
I'd add the meta information like ID and the name of the image to a sqlite DB and manage it via CoreData, which has some very powerful ways to access the information.
The images themselves should be stored outside the database as I assume that they are not just thumbnails.
Best way would probably be Core Data. It has built in caching, so you won't have to worry about that. Here's a get started documentation: Introduction to Core Data Programming Guide. There are also a lot of tutorials online, but Apple has really good start up samples.
Related
I am creating a Questions and answers app for iphone which allows user to answer the questions displayed.
Currently I am invoking a web service to store the users answers. But I am slightly worried what if the web service goes down. I need to store the users answers locally and then invoke the web service when it is up and running.
How can I store the users answers when the web service is down. Is Sqllite a good option for this?
Please suggest.
Thanks,
Is Sqllite a good option for this?
Yes, SQLite is decidedly a good option. The other choice would be Core Data.
Use CoreData or SQLite on iPhone?
It depends on the complexity of your data model. I've looked into something like this recently and here is what I learnt. The most popular data storage methods in the iPhone are:
plist
Good for small quantities (hundreds of Ks) of hierarchical data.
Bad if relationships or queries are complex (since you have to write the code).
Very easy to learn.
Supports array, dict, string, data, date, integer, real, boolean elements.
You can store it as XML, which is editable and portable, or as binary files, which is faster.
Core Data
It's a object graph manager with searching and persistent functionality.
You need a good few hours of learning.
Easy to use once you set it up.
Better than a plist because it lets you manage object graphs, grow your object model, write queries, undo/redo, migrations to modified data models, memory management, and handle concurrent access.
Better than SQLite because:
The performance is similar and the speed of development is faster.
Creating objects is faster.
When the objects are in memory, executing queries doesn't require a search in the backend (which usually is either memory or SQLite).
SQLite
A database.
Better than Core Data when the operation doesn't require you to bring objects to memory. Example: update, delete, and select 1 (see if something exists).
It has full text search if you compile the extension.
Hardest to learn. Easier if you use a wrapper: FMDB, egodatabase.
If you can get away with a plist do that. If you see the amount of code you will have to write is too much work, then switch to Core Data. Only if you are an expert and absolutely need the performance use SQLite (unless, of course, you already know SQLite and not Core Data).
It should be, yes. I'd set up a Core Data based app with entities for Questions and Answers and set up relationships between them. Then just use NSFetchedResultsController or whatever you would like to gather and display the data
You have several options:
Sqlite
Core Data
Client-Side storage
If you wish to go the web based route, I'd take a quick look at Safari Client-Side Storage and Offline Applications Programming Guide.
Basically, you store a local copy of the database in memory so incase the web service is down, users can still use the app.
So I have been doing lots of reading and found out NSCache is not persistent which is a slight problem for what I need to do. I have heard that I will need to use Core data instead... but I don't have any experience with core data so am wondering if its the only solution for persistent data.
The app will allow the user to search through a catalog, by typing in a search parameter in the code and select a distributor for their search parameter. What I want to do when the app loads is download the list of distributors and save them to a "cache" the will be persistent (till when the header I will make at some point changes and demands the app to update the cache), so that if the user turns the app of or the phone next time then open it the manufacture.
Now that I'm getting abit deeper into my app I'm getting abit lost in things for instance how would setting up a cache work with regards to NSURLConnection.
Any suggestions or code examples would be greatly appreciated..
This previous answer of mine might help you decide.
To sum it up:
If your data is small, static and low-complexity, use a collection class and write it to disk using the built-in class methods
If the data is static, low-complexity but large, SQL may be a good solution especially if you already know it.
If the data is dynamic and complex regardless of size, then Core Data is your best choice.
Viewed purely from the technical perspective, Core Data is always the best choice for iOS/MacOS API apps. Core Data is not just a persistence API, it is an API for creating the model layer of the Model-View-Controller design paradigm that the Apple API uses. It not only persist the data, but models it, validates its and provides an easy interface to the rest of the API.
If your going to be writing iOS apps, you need to eventually learn Core Data. However, it does have a learning curve and you should pick the method right now that will let you ship a usable app.
You can also check out sqlite. Here's another question that discusses getting started with sqlite on the phone: Where's the best SQLite 3 tutorial for iPhone-SDK?
The advantage to sqlite is that it is fairly easy to pick up. The downside is that you have to write queries for everything, and that can be a pain. It doesn't save objects, just data, numbers or text.
I've tried looking around but honestly not finding much help. I am mostly seeking for advice as to how I should approach to develop what I am thinking.
I want to accomplish something like this.
Imagine a website, with a backend database. This database contains information fed by users themselves. The website is fully functional, now I want users to be able to have the same functionality on their iPhones. I don't use a local database because I want all users to be able to have access to the same database, and this changes constantly.
What would be the best approach to:
Allow users to access all the information currently available on the website (database perspective).
Able to edit & add new entries to the database
I don't know if me creating an array to hold all this data would be wise to do. Specially with large amounts of data. I dont know how well it can scale.
Should I create a duplicate SQL lite database on the phone itself duplicating that of that website? What do you guys feel would be a good approach to this?
Comments, links, references would be greatly appreciated.
Thanks!
Sounds like the perfect time to create an API for your website. If the size of you application is not very big, you can use the same database, but would be good to run the API separated from the web server.
Essentially, such an API should allow you to make requests to certain URLs for retrieving, updating and deleting information from the database.
Depending on what server-side platform you are currently using, there are many options.
Client-side, your iPhone app can use http://restkit.org/ or http://allseeing-i.com/ASIHTTPRequest/ if you feel confident.
I would like to begin work on an iPhone app that does little more than display a books content for reading. The book content is available online, and is fully open source, but I would like to make the content available locally. With apps that I have worked on previously, namely with iPhone OS 2.X, creating (or finding) an .sql database and then just making queries for data from within the app worked really well. With the advent of Core Data (which I am not that familiar with) the older sql method may not be ideal. So my question is: What is the best way for me to go from online web content to locally stored iPhone readable content? Regardless of which approach I take, I am going to need a db (right?), so should I get the brunt of it out of the way and start with importing the web content into a db with all of the correct tables and columns? I guess with this question, I am just looking for a point in the right direction. If there were any suggestions about the best method for me to get rolling on this, it would be greatly appreciated. Thanks!
Core Data is good if you have "objects" that you want to make persistent. In the case of having just a lot of data to read/write, plain old SQLite may be simpler.
Sorry that I can't give any more specific advice, but it comes down to how complicated your app's data model and object models are. I'd recommend looking at Core Data, but don't use it just because everybody tells you how cool it is.
If you go with Core Data, you won't define your own SQL database schema, so don't start down that path until you've made the decision.
I actually would go with the Core Data route. Core Data is just an API provided by Apple to manage persistent data no matter the data backend (wether it is a flat plist file, an XML file, or a full sqlite database file).
In the case of a book, you can break down the entities as follows.
Book Entity
Title which is a String Attribute
Author which is a String Attribute
chapters which is a has many relationship of Chapter Entities
Chapter Entity
Title which is a String Attribute
pages which is a has many relationship of Page Entities
Page Entity
PageText which is a String Attribute
Then you can access all the values as if they are objects using Core Data without having to worry about the SQL backend code, and writing all the code to translate the SQLite datatypes to Cocoa objects that your view controllers can display.
So I am working on an app that uses core data to store attributes of objects that the user can set. I have primarily been focusing on the first part, which was setting everything up on the core data side, and now I am ready to move on to the next part which deals with the camera. I want to be able to add a city, or other geographical location (this is the object) and then be able to take pictures within my application that would accordingly store these pictures (or attributes) under the object. When I click on New York on my uitableview for example, I'd be able to view any number of pics that I took in NY. When I click on Florida, I'd be able to view any pics I took in Florida. So, my question is about whether or not that is a possibility? Sorry, that was a vague question. If I were to take pictures from within my app, would I be able to save them there as well? And make a list of them in my app? I guess I am envisioning a seperate core data-esque looking uitableview withing the place object letting you manage pictures so that they are directly viewable in like a slide show mode where I'd be able to see all the pictures I took at that location. Is that a possibility or would they save in the default picture location in the pictures app? Would there conceivably be any memory restrictions? Or would I be able to pull from the media memory (8gb, 16gb, etc)? I guess my questions aren't for specific code examples as much as they are for directional purposes. If anyone has any insights/ideas to help me out it would be greatly appreciated. Thanks!
The design you describe is definitely possible.
You can give users the opportunity to select a picture (and/or video) from their photo library and/or take a new one with the camera and then use/edit/store it in your application. Check out the UIImagePickerController and the UIImagePickerControllerDelegate protocol.
You can store images directly in Core Data as a transformable attribute by converting them to NSData using UIImagePNGRepresentation() or UIImageJPEGRepresentation(). If you do this, it is recommended that you create a separate entity with the image data attribute so that you can load your other attributes quickly (and only pull in the image data across the relationship as needed). Alternatively, you can store the images in files in your app's Documents directory and save the filename as an attribute in your entity.
Check out the TTThumbsViewController in the Three20 library for a nice way to show a grid of photo thumbnails.
I would really recommend storing the files to the application Documents directory, and storing paths to them in the database. You can do it the other way but storing them in files keeps the database smaller and gives you more flexibility to upload them somewhere without having to load the whole image in memory.