I am running a site right now with a quite big MySQL database.
Now, I want to create an app. I will need to use obviously a database de to the fact my data are already there.
Thus,
1) Should I keep using the MySQL server and my iOS app will connect to this MySQL serve for getting data?
2) is there any problem if I use the MySQL server ? Security issues maybe?
3) if I have to change the MySQL server, what database infrastructure I need to build and work with?
I am totally newbie on iOS apps. And now I planning to face any issues my iOS app will have.
Since you are running a site with MySQL I think a lot of your questions have been answered. You already have seen how your MySQL database performs in a production environment. Unless you believe that your iOS user base is going to be much larger or perform very different functions you currently have valid performance benchmarks.
In terms of how it relates to the iOS app, you can build an API, or make calls to https pages on your website that will return the information required for your app. For information on how to do this, check out this AFNetworking tutorial.
In the end, there might be some reasons that your current database isn't the right choice for your app. But since the app won't be interacting directly with the database, you can change it out later and you will only have to integrate the database with the interface and not change the iOS app at all.
Related
I 've been thinking about a project for a Website and an iOS app. I have some domains (Webserver) with SQl. It should become sth. like a News-Blog about a special topic.
So I want to ask, if it would be possible to upload an article into SQl and load it to my app and website.
The problem is, that i've never worked with Sql before and have absolutely no knowledge about Sql. The app would be made in Swift and the Blog(Website) with Wordpress.
So, how should I proceed and where do I have to pay attention?
(Sry for my english, but i hope you understood what I want to do)
SQl = MySQL version 5.5.49
you can load data in ios app using REST API.
when you are done with you SQL integration with Wordpress you can use wordpress Web Services plugin for iOS app.
plugin http://v2.wp-api.org/
In iOS app you can use Alamofire Web API Framework to handle Web API request. https://github.com/Alamofire/Alamofire
I don't know if I clearly understood your question but I think that your main concern is to know whether it is possible or not to use a single database to store the data from BOTH your mobile app AND your website.
The answer is yes. The database will be the same, the data is simply displayed in two different views (website or mobile app).
Note that SQL will only be used to get or to add some data in the database.
Wordpress uses SQL to store data, and you can use SQL while you develop your mobile app to store or to get data from the database created by Wordpress.
SQL is the language and MySQL is the DBMS (DataBase Management System), these are two different things, as I think that you are confused about this.
I was recently building an internal business database web app using Ruby on Rails 4 and Postgres. The plan was to make the app available to all our employees using Devise for authentication and hosting on Heroku.
Toward the end of development, a request was made to include some highly sensitive information in the app including social security numbers, etc. Thus, instead of heavily worrying about online security we are planning to make this app only run locally on one Mac and not have it available online. The app will only be used about 5 times a month by one person. Instead of requiring that person to launch a postgres server and a webserver via terminal (such as "rails server"), is there a way to package the entire Rails web app and database in to an application so it could be run similar to other OSX apps?
If anyone knows a PC solution instead, that is also a (less preferred) option.
At this point, we realize we should have developed a xcode app, but now that the development is mostly complete with some tricky UI, we would rather not have to recreate the functionality in xcode.
Though I haven't used it myself, what your describing sounds pretty close to what Rubymotion offers
I feel like my question is partially answered through a number of other questions, but I just can't piece everything together for my case.
Basically, I'd like to build a fairly simple web app, but also be able to fairly easily build a mobile app for it down the line. From my research, the best practice would be to build a RESTful JSON API, and then use that API both for my web app and for my mobile app.
I've already gone ahead and developed authentication for my JSON API (using : http://lucatironi.net/tutorial/2015/08/23/rails_api_authentication_warden/) and I've got it up on Heroku. Now for my web app, I'm using HTTParty to consume that API, and I'm getting the JSON back all fine and dandy. However, I'm not quite so sure what to do with the database. My first thought was that maybe I need to access the API's database via it's own API calls, but that seems incredibly complex (just the thought of having to make functions for User.find_by_<every attribute> makes me scared). The other thought would be to have my web app use the API app's database. However, I can't find any info on how to do that if the app is on Heroku.
So basically, I'm wondering what the best way to go about this would be. Surely there is a standard out there that every big or small web app with an API uses. I'm really surprised that something so prevalent these days is hard to find good answers for. Or am I going about this all wrong? Any pointers would be greatly appreciated.
Databases are add-ons in Heroku parlance.
Use heroku addons to get a list of the add-ons for your apps.
$ heroku addons -a appname
Add-on Plan Price
──────────────────────────────────────── ───────── ─────
heroku-postgresql (relaxing-purely-8366) hobby-dev free
└─ as DATABASE
First you may want to remove the database attached to your front-end app:
heroku addons:destroy fat-samurai-1234
Then find the name of the database add-on attached to your API app and attach the add-on to your frontend app.
heroku addons:attach shining-sushi-1234 -a sushi.
https://devcenter.heroku.com/articles/managing-add-ons#creating-an-add-on
As to which approach is legitimate that's a matter of discussion. Many apps today use a single page architecture where the entire app is created on the front end - in javascript. So your app just consumes your REST api. Popular frameworks for this are Ember.js, Bootstrap and Angular.
The other approach would be to to create a classic server side app - while it's possible to create an app that would consume the REST api there is a significant overhead involved so it will be more performant to connect directly to the database.
I have been working on iOS application for sometime, and I am using Core Data to manage the SQLite database for the application. The users of the application can update the data associated with their account using the application, but I would like to create a simple web form where users could update certain information asosciated with their account. Basically I would like a user to be able to access a web adress from their personal smartphone or computer, login, then update information asociated with the account stored on the iOS device. What are the possible solutions I could use to accomplish this?
Breaking down your question:
Currently you have an iOS app which uses a local SQLite DB to store data
You want to let users update information in this DB remotely (i.e, via a web site)
Unfortunately to do this you're going to need to make some significant changes to how your app works. This is because it's impractical - if not nearly impossible - to do this kind of thing and keep the database local to your device.
The standard way of achieving this would be to store your database remotely on a web server, and then have both your app and your web form interact with this server to retrieve and update data.
There are lots of different ways to do this. Fundamentally, you'll need a server running a database, and a web service to access it. You could implement this yourself, using something like MySQL or PostgreSQL, along with a language of your choosing (Ruby, PHP, Node, etc). Another option is to use one of several 'backend as a service' providers. These are companies that provide 'out of the box' backend functionality for mobile apps. Two popular providers are Parse (owned by Facebook) and Stackmob.
Whether you choose to do it yourself or use a backend provider will depend on how confident you are. It's not an especially hard or tricky thing to put together on your own, but there are several common pitfalls you're likely to encounter.
I'm developing a tool that will comprise a central website and a desktop application. I've only really done entirely online developent, or entirely offline/client-side development before and not really had to link the two. I could use some help in how to approach passing data to/from the online site & desktop app.
The desktop app needs to communicate & do some control of iTunes, so initially I'm building this in Cocoa on OSX & making use of the ScriptingBridge framework.
On the website side I'm thinking of using Ruby on Rails, with data stored in a mySQL database, as I'm fairly familiar & seems like a good match for the online job it has to do. (But open to other suggestions if there's a better approach!)
I'm struggling to find the best approach to easily transfer data between the Cocoa app & the online rails database - is there a simple way of having the Cocoa app access the online database directly, or is it typical to dump some XML onto the webserver and have the app read that?
Opening a RESTful API on your RoR system is as simple as you can get. Have your desktop app communicate with that API using JSON or XML.
Advantages to using JSON rather than XML: (1) extremely simple to manipulate in Rails (2) extremely simple to work with in Javascript, should the need arise to build a web client in addition to the desktop one.
It's a very bad idea to have the desktop app communicate directly with your remote database. Two main reasons:
Security. Such a setup just begs to be hacked. Some databases are "built for the web" (CouchDB comes to mind) and would be alright here, but MySQL isn't.
Flexibility. With desktop application in the field, making changes and distributing them to all clients is hard. Should the need arise to change your schema, the web application layer frequently allows you to keep the interface with the desktop clients stable.