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 5 years ago.
Improve this question
Me and one fellow developer are working on a iOS framework and we are in a debatable situation. I will try to explain it in more details below
Questions: Is it a good practice to bundle the database in the framework, instead of allowing developer using our developed framework to implement the local database of his own.
My argument: We should never bundle the database within the framework and we should allow user to implement the local database of his own so that perform different operations in the app as per his/her convenience. We should never force the developer to be dependent on the database and database structure we created for various tasks such as caching or offline storage. As a framework provider what we should provide is a base using which he can access functionality provided by our platform.
His argument: The database should be bundled in the framework itself so that developer can directly implement the front end of the app instead of managing database and its architecture. It doesn't matter if he want to use our database or not. If he doesn't want to use anything he will simply ignore it.
I would like to know which is a correct approach for designing a SDK/framework
There can be multiple databases, the fact that a framework has a database doesn't mean that the app that using the framework can't have a database and that shouldn't be a consideration for the framework.
If your framework can offer database or caching capabilities as an option then great , and if someone thinks that he can manage database better then your framework can and wants to do it by himself then also great.
I would think how can the framework suggest local database as an optional feature of the framework.
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
I'm thinking of developing an app where you can look at each other's profiles (basically a Job-Finding Application) and I would like to know if you needed any knowledge of PHP, MYSQL for the databases and would you need any knowledge of Javascript to develop the application.
I'm currently looking at Google Firebase and also didn't know if that required any PHP knowledge?
All of the Firebase SDKs that you would use in your client app do not require any programming language knowledge other than what's required for your client platform. If you want to write entirely in swift, that's fine.
The only exception is Cloud Functions, which requires that you learn JavaScript to run on the backend.
iOS apps are built in Swift or C#, typically not javascript and never php.
You can build a PWA (progressive web app) that acts like an ios app using javascript Libraries such as react.
However, MySQL is a database that can be used with any number of applications and programming languages, so you should probably learn that.
My guess is that if you are asking this question, you probably should consult the Apple developer documentation before asking on this form.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I am trying to develop an iOS app (Swift) that requires the use of database. The app will have three different users login and courses. I have 5 database tables that i will have in my app but I am not sure which database platform to use. (I have done research and some people recommend Core data and others say Realm)Thank you for your suggestions.
Depend upon your requirement you need to choose Realm, Sqlite and CoreData database.
For Reference check this link
https://rollout.io/blog/ios-databases-sqllite-core-data-realm/
Since you are just getting started, I would suggest you to try out CoreData and see if it works for your use case. It is object oriented, works well across all Apple platforms and is well integrated with Xcode. Although, please note that this only works for local data. However, if you need (or wish) to store the data on remote server then Firebase would be the way to go. Also this might be preferable if you later wish to do analytics based on the data stored.
Both of these work pretty well and aren't exactly comparable to each other coz they have different purpose. You just need to figure out what's your long term use case and plan it out. For more details check this: https://www.quora.com/How-does-Firebase-compare-to-Core-Data
You can use Firebase if you do not want to setup your own database. You can then assign 'roles' to the users logging in. Check out Firebase authentication documentation.
If you're doing it locally, Core Data is fine.
But if you're doing it remotely (over the Internet, in the cloud), then Firebase is OK.
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 6 years ago.
Improve this question
In most ASP.NET Mvc tutorials, you see people creating simple models and then scaffolding controllers with views, using Entity Framework.
In most tutorials you will also see that they create a new DbContext class which will have the DbSets. I understand that this is a good thing to do for educational purpose, to help the person understand how it works.
But the account system that comes with a default Mvc project always links to "DefaultConnection".
Some tutorials will also make use of the account system to advance further, but that means that at this point you would have 2 databases running to support your web app.
one for the account info
one for the details of your model(s)
Is this the correct way to work? or do most developers/companies just use 1 database for both of these?
My reason for asking is because i found this tutorial which uses both of these aspects and works on 1 database and it is the first time i see this being done.
There's no right or wrong way. You need to evaluate the requirements and time lines for your projects and decide which options suits you best.From personal experience, in all the projects I worked on, the account info and the models reside on the same database.
Remember that if you have two databases you will need to create two data contexts to access them.If the database needs to be moved to another server, you would need to move two databases and change the connection string in two places, also the maintainance and upkeep on the DB would need to be performed in two different places.It's really a maintainance headache and should be avoided in my opinion unless your requirements have some compelling reason that you should place account info into a separate DB.
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 7 years ago.
Improve this question
I am pretty new to iOS and I am planning to start one iOS native application with Parse/AWS or any other cloud based DB handling. Is this a good practice or I should include mid-tier like Java and let my app talking to it instead of directly dealing with Cloud? My question is around security and scalability of my application. If I include a mid-tier then I think I can use that as an API with in Android version of my same app as well and which will make things easier for me to handle.Share your thoughts please.
First, great question. I am a long-time user of Amazon web services, where I call for the database without a middle tier. I find that the cloud balances the load well, spins up new resources well, and generally responds well.
As for the security element, you are really sending authenticated requests directly into the cloud, not to a given server. Hence, making a round trip to a specific server (linux + java) is no longer necessary. The cloud can accept datagrams with authentication information loaded.
I am not a parse person, so I may not get this answer voted, but AWS uses a security service called IAM (Identity and Access Management) which forces you to define a pool of permitted resources in your cloud. I imagine that Parse provides comparable services (if not, perhaps consider the AWS cloud), since this is how you are able to call for the database without a middle server tier.
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 8 years ago.
Improve this question
The question is very simple.
Should I use Core Data only to persist data, to store it locally on a device or should I use it ALWAYS just to manage my application's model even if I do not persist significant amount of data?
What do you think?
Core Data provides an infrastructure for change management and for saving objects to and retrieving them from storage. It is not, though, in and of itself a database. You can use an in-memory store in your application.
Use it Always ? : NO. Use it when you think that your require the features that the Core Data framework offers to you, like any other framework.
Short answer is no. As others said if you do not need persistent store just create runtime objects and manage them.
Even when you need persistent database, Core Data is not always the best solution. For example if you have multi-platform app, or if you plan to port your application in future I'll definitely consider use base sqlite3 with requests. This way I can use same database structure in my Android, iOS and BB application, and even my sql statements will be written only once(with their interface) and then I'll just need some platform specific implementation above them.