I am a beginner iOS developer and looking for a easy to use database wrapper library to use SQLite in iOS (Iphone, Ipad) applications. So far, I have found FMDB.
What do you guys use to make enterprise wide Iphone database application? What is an easy to use and reliable DB wrapper library that I should look into.
Yes, if you need/want direct SQLite interaction, FMDB is an excellent choice. It offers a simple and robust interface to the SQLite C API.
You might also want to consider Core Data, the iOS framework for "object life-cycle and object graph management, including persistence," which generally uses SQLite behind the scenes.
As the Core Data documentation says "Core Data is not a relational database or a relational database management system (RDBMS)." The Core Data Technology Overview clearly delineates precisely what Core Data is and what it is not.
Having said that, for many applications, it offers a number of advantages over interfacing directly with SQLite, itself, and its worthwhile considering Core Data before you simply dive into SQLite programming yourself.
Related
I am working on a project that will include a Laravel web application, Android application, and iOS application. I am new to iOS. Since a user's data will need to be synchronized across all platforms, I assume the optimal way to do this is with a Relational Database (i.e. MySQL) and a PHP Web Service that interacts with the mobile apps.
Everything I see online says to basically use Firebase for mobile apps. There is a lot of work to create the PHP Web Services necessary. I am surprised the dominant recommendation is to use Firebase. About every iPhone app I have has both web and mobile platforms where data must be synchronized. I assume they cannot use Firebase and must use PHP Web Services.
Am I missing something?
You are absolutely correct that it is not a foregone conclusion that one would use Firebase. It’s a great solution that fills a particular niche, but developing separate web services is extremely common. (I suspect that that your online research may be biased by the fact that most of these articles are likely geared for mobile developers who might not have the wherewithal to develop, maintain, and support their own web server infrastructure.)
That having been said, I would not have jumped to the conclusion that the “optimal” way would be to write your own backend going against some RDBMS. These NoSQL solutions, like Firebase, are perfectly up to the job in most cases. There are pros and cons on both sides of the NoSQL vs RDBMS discussion (which is probably beyond the scope of this question).
So, do not be unduly biased by these Firebase articles you found online, but consider adding it to your tech stack if:
there are some compelling Firebase features that you don’t want to reinvent yourself (e.g. the integrated authentication options are nice; the realtime observers for database changes is a killer feature, if you need that; etc.);
the NoSQL paradigm of Firebase’s “Real-time Database” fits your app’s requirements; and
you need backend server capabilities, but don’t want to deal with the overhead of developing and maintaining your own backend.
In your case, because you’re already developing a Laravel app, that largely undermines that last rationale, because you’ve obviously already signed up for that.
So, it is just a question of what Firebase features you need and whether these features are compelling enough to justify adding Firebase to your tech stack. But don’t use Firebase because you found a bunch of articles advocating for it. Nor should you dismiss Firebase because you fear it won’t be “optimal”. It depends.
All of that having been said, the excellent, seamless, object-to-database mapping that Laravel provides really begs for the SQL database approach. If you tried to use Firebase for the backend, you’d likely lose a lot of the benefits of Laravel.
I have been working on an app that uses Parse as its backend and while this works well, I don't want the app to become too dependent on Parse to work. Having the apps own Core Data implementation is probably the best way to go but the implementation must be flexible so that it can support syncing etc. I have been looking into frameworks like Ensembles, MagicalRecord, iOSDataManager and a number of others. I even looked at FTASync but this has not been updated for years and does not have a good reputation. I felt to ask the community what others may recommend as a good design of a backend system to sync with Parse or other web service. Particularly considering how important the backend is...
Thank you
I have used Ensembles, and I recommend it highly. The open source version is probably fine for your use, with the version 2 version available if you find you need any of the benefits for the paid upgrade.
If you want to see how to build a backend agnostic interface, then I also highly recommend studying the ensembles framework, especially how the interface for the cloud file system interface.
I have implemented my own backend for a specific project, and the interface is quite clear, and extremely useful for teaching one how to design and build such an interface.
I am just starting to study and develop Mac OSX applications, and I'd like to design an app that uses a database.
I'm not opposed to something like MySQL, but I'm looking for something that can be single user and can be stored directly on the device so internet access is not required. I'd prefer not to resort to writing/reading from a file either.
The closest I've come to find is SQLite, which I am familiar with in Android development, but my question is: is that what most OSX developers use?
I am trying to pose this question in a way that is not opinion-driven, as I know there are countless DBMS out there. Is there one that leads the pack as far as being used with OSX?
Higher Abstractions:
Core Data is available on iOS and OSX.
Realm is a popular alternative to Core Data. Some of the features include:
Fast
Memory efficient
Its safe and easy to use across multiple threads (core data can be tricky here).
Like Core Data it uses the Active Record pattern, where persistence methods are defined on the model objects themselves (unlike the DAO pattern, which uses a separate interface).
Lower Abstractions:
FMDB is a nice Objective-C API that sits over the pure C API to sqlite.
Looking at BaaS providers to sync client data between devices. I like the StackMob implementation but I don't understand if and how to implement StackMob into an existing application using Core Data and Sqlite. Maintaining the existing DB is essential for backward compatibility.
Can someone explain how to do this or point me to documentation that describes the process?
What are the best local iPad databases?
CouchDB or SQLLite? Which is better?
What does Evernote use? What does Foursquare use?
I do not know what databases Evernore or Foursquare use on the iPad.
SQLite is currently the "best" database for mobile because it is already included and it is so small and light-weight. SQLite is one back-end in the Core Data API (which is most likely what Foursquare and Evernote use).
However, CouchDB is also very light-weight but it is not yet easy to use on iOS. If/when it does become easier, it will be ideal for mobile because it supports local, offline operation and has built-in synchronization with the central database.
Choosing from these two requires more thoughts:
For couchdb, the db is document oriented.
It also is using webservices(so you will have to handle these properly) and the basic CRUD is done via REST.
Pro:
If your app wants to replicate data to or from the outside world, couchdb handles this very easily and you have the ability to write couchapps, basically webapps running directly on the couchdbserver. These could be delivered as natve IOS apps, I assume, as it is now possible for Android: link
I am not familiar with basic patterns about handling data in IOS, but using a "driver" to use couchdb should be evaluated as well: http://www.couchone.com/page/couchdb-drivers