As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Hi I am newbie to iOS programming,
I am building an iOS app to display a catalogue(Product name, Item No, Discription, and Image) of the products. After the user installs the app on the iOS device there may be updates happening to the product list. The user will not be able to modify any data in the database.
Can some one give me an idea of what kind Database i would require to use (SQL lite, Json or Coredata) and how i can let the update happen. Should I update just the new / modified records or update the complete database each time.
From some examples of apps i have seen from the appstore the app downloads the entire (latest version) of the database the first time the app is loaded.
Thanks in advance to all the friends out there in the community. your suggestions, codes, examples and any reference materials and links will be of great help.
Cheers!!
A couple of thoughts:
Apple's recommended framework is Core Data. Especially if you have a lot of data, it's probably worth familiarizing yourself with it.
Direct SQLite programming can have its advantages, but unless you have a compelling reason to pursue it (and I don't see anything suggesting this in your question), stick with Core Data. If you do decide to use SQLite, consider using the FMDB Objective-C wrapper for SQLite.
If you're dealing with a trivial amount of data (e.g. a dozen records), Core Data is probably overkill and you could just use a property list (plist). For example, if you have downloaded your JSON into a NSArray or NSDictionary, you can then just do writeToFile to save it, and dictionaryWithContentsOFFile or arrayWithContentsOfFile to read it back at a future date.
JSON is generally considered more of a mechanism for exchanging data with a server. I wouldn't be inclined to store data locally in JSON format (though you could). I'd use a plist instead.
By the way, it's generally not advised to store the images themselves in your CoreData/SQLite database. If you have larger files, for performance reasons, we often store them in the iOS File System (and save some reference to the file name in the database).
You mention that you have seen apps that download the entire (latest version) of a database. A more sophisticated implementation (critical with larger databases) would entail downloading updates (edits, deletions, insertions) rather than the full database. For a small database, if you can get away with the solution you propose (and it certainly makes it easier), but as your app becomes more sophisticated, you will want to consider more elegant server integration.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I understand that for smaller projects keeping methods in the main view controller (namely viewDidLoad) is the way forward, but for bigger projects im thinking this cant be the way apps are organised - the m file would be chuffing huge! also there would be thousands of declarations at the top! Im nowhere near building an app that big but i'm intrigued, would you put them in a separate file and call them when they're needed? or is it just a case of scroll past the declarations and use pragma marks to find what your looking for?
Basically this is not a specific question for developing iOS applications, it's more of a software architecture problem and requires more knowledge that can't be put in a single answer.
But to get hold of how things usually work, the project has to be planned by pen and paper first, since those are the developer's best tool, then when you've got the main parts of your project planned in a good manner, you start by plotting some ERD of your main components, and decide what will each part be responsible of, then start coding from there a prototype version.
when you have a simple project up and running, you start cleaning up the code, planning even further, and start testing your code, I can't describe how important testing is !
You'll also need software to manage your project (not the source code, but the project itself), something like asana maybe to keep track of tasks and who does what.
In order to keep your code safe against overwriting by other people who are working with you, and to keep things managed across versions, you'll need to setup a revision control repository of some king, Git is supported out of the box by XCode !
Now for the part of code writing, you need to learn some kind of pattern and follow it, iOS projects and most others now follow the MVC structure, which answers your question of how big the classes will get and how things will communicate together without turning into a mess !
Yes, you'll need pragmas and code trickery here and there, but you should always follow the patterns and conventions in order to keep things maintainable when projects grow !
again as I said, this is not anywhere near a good start, you need lots of experience and knowledge before you can actually work on huge projects, but it's something !
Keep up the good work, and always remember that you always have to ask questions, never be intimidated :)
Edit 1
Forgot to add a tip on reading about Agile software development that's probably my last tip :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been programming with php and mySql for a while now and recently decided that I wanted to give nosql a try. I would really appreciate if some of you with experience could tell me:
When is it a good time to switch, how do I know nosql is for me?
Which nosql software would you recommend?
Thanks
When is it a good time to switch?
It really depends on the particular project. But in general I see that I can use nosql for 95% of web applications. I will still use old good sql for the systems which should guarantee ACID (for example, systems that work with 'real' money).
How do I know nosql is for me?
It's for you, for you, believe me. ;)
You just need to try something from the nosql world, read some existing articles and you will see all of the benefits and problems.
Which nosql software would you recommend?
I would personally recommend you to start from mongodb, because it really simple. To become an expert in sql takes years, to become an expert in mongodb needs a month or so.
I suggest that you spend an hour for reading "The little mongodb book" and try to write your first test application starting from tomorrow.
No one here will say that you need to use this, or this database. What database to use depends on project and requirements.
It depenends on your application needs.. There are a lot of options.
You can use a document-oriented like mongodb, a "extended" key-value like Redis or maybe a graph-oriented like neo4j
This article is very useful http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html
This recent blog post in High Scalability pretty much answers your question in regards to when to use NoSQL.
I myself always go MySQL until it fails me and then choose the right tool for the job, some of the non-relational databases I worked with are:
Riak: a dynamo clone which is useful when you need to access records quickly but you have too many records to keep on one machine. For instance a recommender system for users in a web application, you want to access the data in a few milliseconds but you have 200M users.
MongoDB: a document-based database, for when I needed speed but had a write-intensive application (read/write ratio close to 1:1) the data was highly transient so I didn't care about the durability issues
The best time to switch is when you:
Start working on a new project and you make your first architectural decisions. Porting an existing application to a different database can cause a lot of headaches.
Hit a brick wall... or better before you see one coming :) The main reason is usually lack of performance or scalability.
Need a missing feature (eg: complex hierachical structures, graph-like traversals, etc..).
I would recommend a lot of them, but each of them has their own sweet-spots where they shine and other parts where they lack features. The only way to pick the right tool(s) is to get familiar with a couple of them.
Web developers usually learn key-value stores (memcached, redis) first as they can fix a lot of performance problems (but also add some complexity to your app...).
There are document (schema-less) databases like MongoDB or CouchDB which can significantly enhance your productivity if your data model often changes.
For graph traversals there is NeoJ.
For "big data" there is Hadoop and its related projects.
And a list goes on and on...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
In a small team where everyone is coding away on a project for a little while I want to encourage some different thinking to keep people increasing their iOS knowledge as well as to get a bit more variety in their daily activities. I'm not looking for interview questions involving manhole covers, nor very specific questions about whether drawRect: is part of UIView or UIViewController. I'm looking for questions more along the lines of https://stackoverflow.com/questions/1282830/uiimagepickercontroller-uiimage-memory-and-more - which has a lot of questions and a lot of great information. I voted it up.
I'm thinking of sending out one of these topics about every week and then having a discussion about it towards the end of the week with some examples. Maybe assign a short presentation on a rotating basis so someone gets the job of delivering a 10-minute presentation about the topic, prizes awarded etc. - then when some task comes up involving that topic we may not have an expert but we at least have someone who knows where to start looking for answers. And maybe is keen to find out more based on that exercise.
stackoverflow, while it has "great questions", has a lot that are not so great and these scroll by in huge numbers daily. In iPhone-tagged questions sorted by votes I'm seeing very few of the kind of questions I want. I'm going to look further at some of the top-ranked questions here of course but these are the questions people had to ask, not necessarily the questions that others might get the most benefit from.
There are lots of exercises for "programmers" around but those are not what is needed. I want this to be iPhone specific. We come from a range of backgrounds and are all decent programmers already.
So - what are some things about iPhone development that YOU think are worth knowing? Can those things be phrased in the form of a question that leads an enterprising programmer to a satisfying answer? What made you stop and think, saved you days, pushed you in another direction that was fun and/or profitable, increased your knowledge or just made you feel good for having discovered the answer?
Things every iOS developer should know about:
Categories (how to extend existing classes with new
functionality)
Delegation pattern (how to implement your own delegates using either
a formal or informal protocol)
Blocks (often an improvement on delegation in case of
asynchronous calls, also useful in many other ways)
Passing NSErrors through indirection pointers.
NSInvocationOperation / NSOperationQueue for easy / clean threading code.
With the arrival of iOS 5 soon, one might want to learn about:
Storyboarding with Xcode 4.2 / iOS SDK 5.0
ARC
As a iPhone developer I will set these topics as a 10 minutes presentation.
Beginner level, may be useless if you are already developed in Obj-C but quite useful to integrate a C++ dev in your team
C++ vs Objective-C, Objective-C 2.0, Objective-C++
Memory management in Obj-C (retain, release, autorelease)
MVC design pattern
IB outlets
Design patterns in Obj-C
Use Stack Overflow before Google (not specifically iOS)
Medium/Advanced level
** Instruments ** (how to use it) (very important)
Comment code (even if selectors are expressive? a line or two is always better)
Automated tests (Who test their app anyway ? :))
Image manipulation + memory warnings
Code review of past apps (what is good, what is bad)
Code abstraction (see what module you have copied/pasted many times on yours apps and way to make it like a framework)
OpenGL ES (basics, only useful if you makes games)
Maps integration (with custom callouts, pins ...)
App Store submission (things to check before sending the app)
In-app Purchases
Push notifications
Core Data
SQLlite
Web service integration
Game Kit
Reducing loading times in the app by preloading
XMLParser (DOM and SAX)
Bonjour
Networking (checking that the iPhone can connect to the server)
Social network integration (FB, twitter, 4square ...)
Using GoogleMaps webservices
JSON
Core Animation (very long presentation)
Using UIAcceloremeter
Custom Views
Creating IB outlets
Creating Frameworks
Using Core Audio
Geolocalisation
Using C++ frameworks with iOS Projects
Things I don't know :
Calendar
Using iTunes library
CoreTelephony
Messing with Address Book
iAd
Video
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are the best practices for NoSQL Databases, OODBs or whatever other acronyms may exist for them?
For example, I've often seen a field "type" being used for deciding how the DB document (in couchDB/mongoDB terms) should be interpreted by the client, the application.
Where applicable, use PHP as a reference language. Read: I'm also interested in how such data can be best handled on the client side, not only strictly the DB structure. This means practically that I'm also looking for patterns like "ORM"s for SQL DBs (active record, data mapper, etc).
Don't hesitate making statements about how such a DB and the new features of PHP 5.3 could best work together.
I think that currently, the whole idea of NoSQL data stores and the concept of document databases is so new and different from the established ideas which drive relational storage that there are currently very few (if any) best practices.
We know at this point that the rules for storing your data within say CouchDB (or any other document database) are rather different to those for a relational one. For example, it is pretty much a fact that normalisation and aiming for 3NF is not something one should strive for. One of the common examples would be that of a simple blog.
In a relational store, you'd have a table each for "Posts", "Comments" and "Authors". Each Author would have many Posts, and each Post would have many Comments. This is a model which works well enough, and maps fine over any relational DB. However, storing the same data within a docDB would most likely be rather different. You'd probably have something like a collection of Post documents, each of which would have its own Author and collection of Comments embedded right in. Of course that's probably not the only way you could do it, and it is somewhat a compromise (now querying for a single post is fast - you only do one operation and get everything back), but you have no way of maintaining the relationship between authors and posts (since it all becomes part of the post document).
I too have seen examples making use of a "type" attribute (in a CouchDB example). Sure, that sounds like a viable approach. Is it the best one? I haven't got a clue. Certainly in MongoDB you'd use seperate collections within a database, making the type attribute total nonsense. In CouchDB though... perhaps that is best. The other alternatives? Separate databases for each type of document? This seems a bit loopy, so I'd lean towards the "type" solution myself. But that's just me. Perhaps there's something better.
I realise I've rambled on quite a bit here and said very little, most likely nothing you didn't already know. My point is this though - I think its up to us to experiment with the tools we've got and the data we're working with and over time the good ideas will be spread and become the best-practices. I just think you're asking a little too early in the game.
"NoSQL" should be more about building the datastore to follow your application requirements, not about building the app to follow a certain structure -- that's more like a traditional SQL approach.
Don't abandon a relational database "just because"; only do it if your app really needs to.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What are some best practices to keep in mind when working extensively with SQLite on the iPhone? Tips/tricks/convenience factors all appreciated.
I can recommend using FMDB as a nice Cocoa SQLite wrapper.
Measure your app's memory footprint and look for leaks in Instruments. Then try it after invoking sqlite3_exec with:
pragma cache_size=1
and/or
pragma synchronous=0
YMMV. There are reports of performance boosts, large reductions in RAM usage, and fewer leaks. However, be careful about making adjustments without understanding the impact (for example, synchronous turns off flushing which speeds things up by a lot, but can cause DB corruption if the phone is power-cycled at the wrong time).
More here: http://www.sqlite.org/pragma.html
Off the top of my head:
Use Transactions.
Make sure your SQL leverages tables in the correct order.
Don't add indexes you're not entirely sure you need.
Perhaps not only specific to iPhone but to embedded devices there are some great tips here.
This link pertains to an older version of SQLite but still proves useful.
Lastly this Stack Question also has some good info.
We use SQLite with a .Net Compact Framework Application currently and it's performance is fantastic and we've spent a bit of time optimizing but not nearly as much as we could.
Best of luck.
I've found that it's often faster to just get the ID's I'm looking for in a complex query and then get the rest of the information on demand.
So for example:
SELECT person_id
FROM persons
WHERE (complex where clause)
and then as each person is being displayed I'll run
SELECT first_name, last_name, birth_date, ...
FROM persons
WHERE person_id = #person_id
I typically find this makes the complex query run in 1/2 the time and the lookups for a given person are typically on the order of 2ms (this is on tables with 17k rows).
Your experience may vary and you should time things yourself.
Also, I have to give credit to Wil Shipley for suggesting this technique in his talk here:
http://www.vimeo.com/4421498.
I actually use the hydration/dehydration pattern extensively from the sqlitebooks which is a superset of this technique.
I am lazy and like to stick in the core code as much as possible, hence I like the ORM tool SQLitePersistentObjects:
http://code.google.com/p/sqlitepersistentobjects/
You make your domain model objects inherit from SQLitePersistentObject (ok a little intrusive) and then you can persist/retrieve your objects as needed.
To persist:
[person save];
Loading it back in is almost as easy. Any persistable object gets dynamic class methods added to it to allow you to search. So, we could retrieve all the Person objects that had a last name of "Smith" like so:
NSArray *people = [PersistablePerson findByLastName:#"Smith"];
One other option I have not tried yet is Core Data (need to be an Apple iphone dev), although its a 3.0 feature and so it depends on your app whether thats an option..
PLDatabase is an FMDB alternative: http://code.google.com/p/pldatabase/
I've used it in one of my projects without issue.