Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I want to use a localhost database in SQL for my IOS's app, how can I use .POST in a specific table ?
PD: I use Alamofire in Swift.
Alamofire is a networking library and not related to the persistence layer.
iOS has the Core Data framework for database access, it can use an SQLite DB, XML, binary or in-memory persistent stores. You do not run SQL queries directly, you use predicates. I would suggest reading up on what options are available to you before you start.
Realm is a good library to use, from their website:
Realm is a replacement for SQLite & Core Data
Apple Core Data Programming Guide
Realm Website
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
So I am creating an app for IOS with xcode and swift and I am using SQLite as a database(not my choice) and I dont understand if I need a server or not.
Thank you in advance
Basically it depends on your requirement. If you want to store your data outside of the mobile itself for any reason such as fetching and updating them from multiple devices you can use a server to host your database and perform read, write operations. If not, if you only want to use your data inside your app itself, you can make use of the SQLite databases and perform read and write operations locally.
No, iOS actually uses SQLite in the Core Data on the device. Here you can see a tutorial on using SQLite in Swift on a device https://www.raywenderlich.com/6620276-sqlite-with-swift-tutorial-getting-started
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I'm new to Swift and I'm building on a simple app that relies on login/sign up functions for each user. When I wanted to learn about databases in Swift, I came across Core Data and from what I understood it's like cookies/cache that stores data in the user's phone. If that's so, what's the best way to connect the app to a regular database like SQL?
Core Data is an ORM (object-relational mapping) system. Overly simplyfied you build your data model entities and and relationships between them and Core Data cares about the rest. Under the hood it uses an SQLite database by default, but it also can handle other types of storage (e.g. binary or XML).
To answer your question, for Login/Signup purposes you should look into storing user data such as auth tokens etc. in the Keychain.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Is there any way to implement reactivity with other database such as PostgreSQL in meteor? We need to have live updates with databases other than MongoDB.
Currently (0.7.0.1), Meteor's only supported database is Mongodb which is very coupled with what is called Minimongo, a client side implementation that mimics the mongodb api and is what basically one of the core components that allow the magic behind Meteor's reactivity.
That being said, other (sql) databases are actually on Meteor's roadmap which you can follow on the Trello board at https://trello.com/c/6ugalZMG/54-additional-database-support and https://trello.com/c/Gf6YxFp2/42-sql-support
But currently, there are some third party initiatives such as the meteor-sql smart package on atmosphere which opens up the first opportunities to develop against SQL.
The full reactivity is what you need to handle, though. Since it is implemented using publish/subscribe/observe api's of meteor and actually don't care much about the underlying data structure. Mongodb is just there for general convenience, but you can implement just about anything as your reactive data source.
In fact this video tutorial from eventedmind takes you through the steps of creating a custom reactive data source.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I need to create an app that does some communication with a server.
My app must post some requests to server, to aspx webservices. Then get back some JSON/XML response.
The question is do I need Core Data?
IMHO it would be enough to have a UIViewController with text field items and to perform submit to provided server webservice URL. The result could be processed with some Json/XML parser library and showed in UITableViewController.
So, I not sure do I have to use Core Data? And why? :)
No you don't have to use core data in order to communicate with a web service/JSON service - you can do exactly as you describe. The only need for core data is if you want information you download from the web service (or created by the user during the session) to remain available between hard shutdowns of the app. (or be available when you have no internet connection)
I'm not sure you understand what core data is.
Core data is a way of communicating to localised sqlite databases without using sql code (as it were). It effectively creates objects that you can use to manipulate and use databases.
To download and post data to and from the internet you don't need to use it at all, unless you want to store the data when you would use it to download the data and store it in a localised database for use later.
A better way to do this though would be to just download the XML/json file directly to the working directory of the app and use it from there (if you want offline/cached use from it).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Since CoreData has become available for the iPhone in OS 3.0, is it meant to be the answer to data persistence and replace all need for direct SQLite?
What reasons exist to still use SQLite? What are advantages/disadvantages of SQLite vs. CoreData?
This is a common question here:
"Core Data vs. SQLite for SQL experienced developers"
"Core Data vs Sqlite and performance…"
"Core Data vs sqlite3"
"is it worth using core data for a simple sqlite app on the iphone with one table and no relationships or complicated subtable/views?"
In summary, Core Data can greatly simplify your code, particularly for complex object models. You get undo / redo support almost for free with it. It also provides some very significant performance benefits, particularly on the iPhone. Even though it seems counterintuitive, given how much overhead you'd think the framework has, in most cases you can beat the performance of hand-tuned SQLite using Core Data. On the iPhone, it does a great job of batching fetches to minimize memory usage.
The one downside, as pointed out, is that this limits you by requiring iPhone OS 3.0 for your end users. However, this has not been a problem at all for my users, and will only become less of one going forward.
This might be a lesser benefit, but SQLite is a lot more portable between platforms, since Core Data is part of Cocoa, and SQLite is pure C. This means that if you wanted to port your application to PC, for instance, you would have less code to rewrite in the event that you use pure SQLite.
Then if you wanted to develop anything else cross-platform using a local DB (not necessarily related to any iPhone apps), you would have already have some experience with SQLite.
If you want your application to run on iPhones not running OS 3.0, you will have to use SQLite.
However, using CoreData (which uses SQLite as a backend, I believe) means you don't have to write your own database-interaction code which is quite a hassle to do, especially when you are doing relations etc.
I use CoreData myself...