I am digging in this forum but could not realize which way to start. I need to build an app in Swift that searches in its internal database for a ZIP CODE and retrieves the street name, just two columns ZIP and Street but it is a list of more than 20K ZIP codes lines.The user will be able only to search not edit, add nor delete. I learned and please correct me if I am wrong: CoreData is good for small databases, and can not import from a list of ZIP codes I already have, neither allows to open the coredata database to edit/copy or add outside of the app, so How Apple wants us to use CoreData if the users must populate the database in the iphone.SQLite in Swift is fast but there is not many good tutorials in the internet, most of them show only how to work with CoreData. I just found one or two tutorial in Swift SQLite. No one shows how to import data from other database, To work with SQLite in Swift I will need a wraper like FMDB or SwiftData, the documentation is too technical for my knowledge so I have no idea which one should I go.Hope somebody can help me and show me the direction and maybe some help in this journey as well.
Jade.
Core Data is a Framework that will help you build the Model (in a Model/View/Controller app) of your App. Core Data is not database technology.
It helps you persisting your data. For that, you can save data in memory (fast & good for testing), in binary, XML form (not in iOS, yes in Mac) or using a SQLite DB as storage.
The normal use scenario is to store Core Data's objects inside a SQLite database. So it's not a "should I select between SQLite / Core Data". It's more a "I'll learn Core Data and it will use SQLite under the hood"
Using Core Data you can do full CRUD in memory (inside a CD Context) that gets saved in DB. So you can import your ZIP codes inside a DB and then access them just in read only mode (just querying Core Data). Querying in Core Data == fetching
You can then bundle that Pre-populated DB with your app and use it. Why? Because Core Data plays nicely with UIKit, so UITableViewController, for example, fits perfectly with NSFetchResultsController
It's a steep learning curve, but it'll pay off if you keep using data you want to persist in your apps.
Related
I build an iOS app which works with base. User can work with it everywhere, that is cool. When application starts for the first time, obviously, base will be empty. For now, user's base stores data locally with Core Data. But there is a case, when user may have his own base with a lot of data and he do not want to start work from scratch. For this reason I want to create simple Cocoa App for macOS, which will allow user to import some data from, for example - CSV file.
Both Core Data models (iOS app and macOS app) will be the same. I just want to make sync between two platforms.
I think it's possible with cloudKit, but which way is the best? Core Data Sync or smth like supporting MySQL database on server, etc...
Thanks in advance!
Asking which method is "best" is a matter of opinion, but in mine, Apple has made working with iCloud fairly simple. If all you want to do is sync between platforms, I would use cloudKit. There seems to be no reason to spin up your own MYSQL database instance and introduce another level of complexity, when the functionality you're looking for is free and easily accessible.
See this WWDC16 video for some cloudKit tips: https://developer.apple.com/videos/play/wwdc2016/226/
I am developing a simple iOS 9 app (using Swift and Xcode 7.01) that uses a Timehop style interface to show data corresponding to the current day, going back X number of years.
I want to seed my CoreData model on first runtime, populating it with specific data based on user chosen options at this first runtime (or changed later in user preferences). However, I would like my entire data source imported so that different data is available if the user preferences are changed
My current data source to be migrated to CoreData is currently in CSV format. My question is, what is the easiest file format to work with for importing/seeding into CoreData, are there any best practices to follow when performing such a task, and is there a right direction I can go in to work out the implementation?
Ideally you want to do any preloading during the building of your application rather than at runtime. You can easily pre-create your Core Data sqlite file and ship it with the application bundle. Then you can either access all of the data or create multiple sqlite files to fit the specific needs of your application.
With the data shipped with the application bundle you can then simply copy the correct sqlite file from the app bundle once you know which one to use and completely avoid having to parse the data at runtime.
Parsing large amounts of data at runtime is a waste of the user's time and should be avoided.
Do it during the build.
Your users will thank you.
I am new in core data please help me in some confusions...
If core data use sqlite in back end then why we use core data not sqlite??
How it is faster then sqlite.
I read a difference that In core data when we want to edit anything it loads all data in memory..but if it loads then why app. not getting slow or crash.
How to show data of a (.sqlite) file that store in Document Directory.
core data is use for persistence storage but it's not a data base(Explain me)???.
Please define all things to me...
Thanks in advance.
If core data use sqlite in back end then why we use core data not sqlite??
Core data doesn't always use SQLite , SQLite is one type of store option( most widely used ), there are two other types available as well
Check this coredata store types
How it is faster then sqlite.
Core data is not an replacement to SQLite , it is like an ORM for SQLite , it handle all heavy work and provide easier interface to work with SQLite , it handles store connection , querying storing , managing and tracking in memory changes etc
I read a difference that In core data when we want to edit anything it loads all data in memory..but if it loads then why app. not getting slow or crash.
This is wrong , core data does not load everything in memory unless you query it yay ways , in general when you fetch an entity it
returns NSManagedObject instance to work with that entity
How to show data of a (.sqlite) file that store in Document Directory.
What do you mean by show data in SQLite file , u will query what data you want using NSPredicate and get an array of objects as response
The .sqlite database will be stored within app sandbox folder
Check this sqlite storage
core data is use for persistence storage but it's not a data base(Explain me)???.
Coredata is not an persistence storage it's persistence store manager, as I said above it handles all heavy lifting work like creating connection , executing query , converting result to NSManagedObject , tracking object changes , persisting it to SQLite and managing entire object graph you loaded into memory
It's hard to compare core-data with sqlite because these are two different technologies.
However here are few things you won't get from sqlite out of the box.
Built-in change tracking and undo support. Core Data provides built-in management of undo and redo beyond basic text editing.
Easy iCloud storage integration (with NSManagedDocument)
Optional integration with the application’s controller layer to support user interface synchronization.
Eg:- Core Data provides the NSFetchedResultsController object on iOS
Full, automatic, support for key-value coding and key-value observing.
Instead of writing SQL, you can create complex queries by associating an NSPredicate object with a fetch request. NSPredicate provides support for basic functions, correlated subqueries, and other advanced SQL. With Core Data, it also supports proper Unicode, locale-aware searching, sorting, and regular expressions.
Merge policies.
Core Data provides built in version tracking and optimistic locking to support automatic multi-writer conflict resolution.
Core Data can reduce the memory overhead of your program by lazily loading objects. It also supports partially materialized futures, and copy-on-write data sharing.
Core Data is the best option to use but if somehow you want to port the application to android or windows and want to keep the code similar then you can go for SQLITE as SQLite is supported by all major platforms. Whereas core data is only part of iOS. Regarding various doubts you can refer this link
Use Core Data or not?
I am looking for a how to create a mysql database with the photos which are uploaded by my iOS app.
I have already programming the picker and the upload part, but I have no idea how to create this database considering that will have 3 different voices "localization , type , date ".
Do you mean a database on the iPhone? If on your iPhone, the typical solution is sqlite. I personally use an Objective C wrapper, FMDB for that, that gets you out of the weeds of sqlite programming. Or check out Core Data if you want to be a little more Cocoa about it.
If, as I suspect, you're talking about your server database, then this is probably not the right forum for that question about how to create a server database. You need to be more specific, and include code samples of what you've tried.
I have a basic question regarding populating Core Data with data. I am building an application, which will show ATMs on a map. I would like to ship the application with a preloaded database, but to give users the option to receive updates when they launch the app. I am thinking about using a property list for the update. Basically send a plist of all the ATMs, parse that plist and populate the sqlite. I will have around 7000 entries in the property list file, each entry containing 5-6 keys with short string values. But according to the Apple iOS Developer Library:
You can create a property list—or some other file-based
representation—of the data, and store it as an application resource.
When you want to use it, you must open the file and parse the
representation to create managed objects. You should not use this
technique on iOS, and only if absolutely necessary on Mac OS X.
Parsing a file to create a store incurs unnecessary overhead. It is
much better to create a Core Data store yourself offline and use it
directly in your application.
Should I still be sending a property list or rather think for an alternative solution to update the application's database?
P.S. I am thinking about using a Rails app for providing updates - basically sending a plist file.
I had nearly the same question a few months back, did quite a bit of searching to find a nice easy answer, failed to find it and eventually settled on a roll-your-own solution that took a bit more time than I would have hoped, but was at least very helpful in learning to understand Core Data.
Basically the solution was to write a little utility that parsed my source data (which for me is a comma-separated text file, parsed using the quite handy 'cCSVParse' library - http://michael.stapelberg.de/cCSVParse ) and inserted it into Core Data Managed Objects and then saved that off as a sqlite persistent store. Then the sqlite store(s) can be shipped with the app, and uploaded by the user when they buy more data.
You could write a conversion from plist (or whatever) into the core data representation within the app itself, but if the data is just going live out the rest of its days in some core data form, why not let your beefy dev box do the heavy lifting before you send the data to the user, instead of shipping the data to the phone and making it do the work?