Basically I want to create an app with Swift that has a list of places with ratings, and information about them. For obvious reasons, I don't want to have to hard-code all of the places, ratings, and descriptions. Is there a way I can do this? Would I use databases? Do I have to pay for hosting? Thanks!
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS App that accesses a database
- Thread starter KameZ
- Start date
- Sort by reaction score
It sounds like what you are describing is dynamic data. In other words this is shared data that will continually grow and be added to. As a result this isn't data you want to include with the app as it will be out of date quickly. Also it is unclear whether users themselves will be adding data or if it all comes from you.
Assuming we are talking dynamic data I think you will want to use a web service. This web service would talk to a database in the cloud and the data will be sent back and forth to the app (via JSON or similar). You can look into something like Google's App Engine. This will cost you nothing until you get enough volume to go beyond their free thresholds and you can set a daily budget beyond that. There are other services that do something similar of course. You will need to write or have someone write the web service for you to call. This could be in Python, Java, PHP, etc.
Good luck.
I will be the only one adding to the data. You mentioned a Google engine, but I'm not sure if I can use that for iOS apps. Would I need to pay for hosting for the database and web service? How do I acquire a database and is the web service just a website or something different?
You're pretty unsure of these concepts so I'll warn you that you have a lot of learning ahead of you. But, be patient, and take the time to research, educate yourself and become comfortable with all this and you will be much better off.
Now, to attempt to answer your specific questions:
- Using Google App Engine does not preclude using iOS. As long as your web services are generating JSON or XML, you should be fine.
- Hosting is free with a number of these services (others include Amazon's AWS and Microsoft's Azure) as long as the consumed resources is low.
- Databases can be set up in a variety of ways, from something as simple (but not very flexible) flat files to Oracle or SQL Server installations.
- A web service is a communication layer between two devices over a network. Think along the lines of sending a URL to a remote server and getting a response, say in the form of JSON, in return.
Now, to attempt to answer your specific questions:
- Using Google App Engine does not preclude using iOS. As long as your web services are generating JSON or XML, you should be fine.
- Hosting is free with a number of these services (others include Amazon's AWS and Microsoft's Azure) as long as the consumed resources is low.
- Databases can be set up in a variety of ways, from something as simple (but not very flexible) flat files to Oracle or SQL Server installations.
- A web service is a communication layer between two devices over a network. Think along the lines of sending a URL to a remote server and getting a response, say in the form of JSON, in return.
First, if you are the only one adding data it is important to understand how often you need to add it. If you store it with the app you will have to release a new version of the app each time you want to update the data. Perhaps that is fine, but you haven't specified whether that will cause an issue. If it will, my earlier suggestion is probably the way to go.
You certainly can use any back-end web service with iOS. Apple doesn't care nor do they even know what services you are using outside of the app. You can open up Safari on your phone and go to Google.com just fine. Your backend service is totally transparent. I personally have used Google's App Engine with my iOS app which is entirely network data driven. It's not an issue. Again there is no charge at Google to set this up and use it. Should your app be a great success and you actually start using enough data or DB reads to go beyond their free allowance (which is already generous) you can setup a budget. Again you will need to either write the web service or have someone write it for you. Yes, it will make use of a back-end database. GAE uses NDB. You can find tutorials and demos of it around the web.
OP, I'm gonna suggest this Ray Wenderlich tutorial to at least start getting familiar with some of the concepts:
Working with JSON in Swift Tutorial
Working with JSON in Swift Tutorial
core data is an iOS tool (part of the framework) providing an easy connection between your code and a database. Often parse is used as backend eliminating the need to go json etc. Parse also is android friendly. As parse is owned by Facebook it is supposed to last. Parse is paying though at a certain amount of requests.
If Core Data uses SQLite under the hood, wouldn't SQLite work just as well with Parse?
Also, isn't SQLite something that works with Android?
So that means it will work with Parse?
If SQLite works with Parse, then it should be a better choice because Core Data doesn't work with Android. So picking SQLite would be a better cross-platform choice?
Core Data actually uses SQLite behind-the-scenes. But, when you talk about a "better cross-platform choice" are you talking about having code / resources that will run on both Android and iOS devices? Or, are you talking about how your server component is implemented? If the former, you'll find much more than just the database-engine to worry about to make things cross-platform. If the latter, as long as you use standard web-service interactions (JSON or XML, for example), it shouldn't matter how the database is implemented.
I was thinking along the lines of the learning curve. I haven't used Parse (yet) so I don't know about that aspect of things.
I'm assuming there are several things to learn, but if you learn how to work with SQLite files on iOS, then working with those files should be the same with Android. In other words, (AFAIK) SQLite has an API to access functions in their database engine, this should be the same no mater what language you are using, creating tables, index operations, getting info from a database about table structures, extracting data from the tables (joins, unions, etc...)
If this is the same, you've reduced the number of things you have to learn.
As far as moving it to Parse, I don't know the Parse API, but I would assume it to be similar to the SQLite API in that it would have a set of functions to access it with one of the differences being for differences in the languages or executables.