I have an existing database on SQLite3.
How I can import this database into XCode and work with data?
Is it possible to work with SQLite3 without using Core Data?
I have never encountered this problem and in other forums I I didn't understand.
Thank you.
SQLite is available for iOS and OSX. The C API library is provided by Apple. You don't need core data. Just use the C API to work with the sqlite database or use an Objective-C wrapper such as FMDB.
Just add your existing database to the project like any other resource file.
Under iOS, if you need to write to the database you will need to copy the database file at runtime from the app's bundle to a writable folder. Do this the 1st time the app runs.
I know this may not answer your question, but I think you can find this really helpful..
this is a framework I found on the internet to work with sqlite databases..
https://github.com/enormego/egodatabase
GL HF
Related
I'm currently working on a IOS project and using Core Data. My question is:
Is there any tool or software I can use to see what data is in the Core Data when I'm running the project, and how to use them. Thank you so much!
Once your app has run in the simulator it creates a persistent store file, you can find the file in your app's document's directory:
~/Library/Application Support/iPhone Simulator/User/Applications
You can also check out CoreDataEditor or CoreDataPro.
There are some tools can make you efficient.
Parrot can help you enter the app sandbox easily，and you can download the app on the Mac Store.
You can use DB Browser exhibit your data .
My question is fairly simple though I couslnt find anything specifically answering it till yet.
I have an obj-c app that I'm updating fairly often. I would like to create a new swift app with the same bundle id to replace the older one as an update. I have like 8 core data model versions within my old app that I would love to migrate to the new swift-from-scratch-app, so my users wont lose their data. Is it even possible??
Thank u
If you're using the exact same bundle ID (this is key), then from the perspective of iOS, it is considered exactly the same app. Consider your users having version 1.x of your app installed on their devices and you release 2.x using your new Swift project. Your user, nor iOS, will be able to tell this is a brand new app written in Swift.
The gotcha here is that unless you use the exact same model names, CoreData won't be able to be initialized with existing data and you'll be forced to write a custom migration for this.
My suggestion to you is to copy the xcdatamodel file from your old project and change the language of the code it generates once copied into the new project.
Then regenerate your entities in Swift and continue working like nothing ever happened.
I will start developing a new project for iOS. I am unsure for now if I should use core data in this project, or not. I will find out along the way, while developing (most likely with some coaching help).
Now my noob question is: Should I, while creating my new project, already check the option 'use core data'? Or shouldnt I?
Basically my question is: What is more difficult, removing core data when I checked the option and I will not been using it after all? Or adding core data when I did not check the option and I will be using it after all?
I have found it is not super difficult to add after:Implement CoreData into an existing project using Swift
But still, it seems like alot of hassle, so I now ask u!
Thanks for the answer in advance
It doesn't matter. Starting with Core Data just prepares the core data code in the app delegate and makes an empty model file, both of which are
1) easy to create yourself, or
2) copy from a new empty project started with core data later when you need it.
And if you already have it in your project, but you don't use it, it is also no problem. I found that almost all projects need core data after a while, so I usually just let it create it from the start.
Xcode just allows you to check using coredata to prepare already a coredata for you project.
BUt it is very simple to add or remove it later.JUst simple as File>create or File delete.
In a words don't worry about creating in the begining or later.
My question, how can I properly remove a realm file? Currently I'm doing so using the file manager, which is fine for me since the Realm file is mostly here for offline caching.
My app logs in to a web-platform, and creates a realm for this platform so you can log in to multiple. When you remove it with the filemanager however, there can still be lock files and such so I guess this dirty way of removing is the wrong way!
in Android you have the deleteRealmFile call on the RealmClass, which works fine when all references are closed. It seems there is not much security on iOS as I can just remove it like this.
So what is the proper way of handling this?
I'm not sure if realm is intended to be used like this but it's ideal for us and makes the developers happy.
I'm working in swift and have an iOS7+ requirement.
That is the proper way of deleting it. You can check the Migration example in the RealmExample project that come with the SDK and see that that's exactly how they do it, so I assume the recommended way.
let defaultPath = Realm.defaultPath
NSFileManager.defaultManager().removeItemAtPath(defaultPath, error: nil)
Currently I'm working on a project where I need to use coredata (I know that coredata internally uses sqlite). In the future I need to merge this project with my existing project where I used sqlite. So, would it be a problem while I merge this project which uses core data and the previous project which I was using sqlite3 into one single application. Any help is appreciated.
Maybe not "just" merge, but you can manually query your CoreData sqlite and map the results into your "native" sqlite accordingly.
If your existent sqlite should go into CoreData, then do it the other way around.
Try to avoid to reverse-engineer the CoreData sqlite shuffling your entries manually into it. Pass your sqlite query results through the managedObjectContext and be done for good.