I already have the iOS apprentice and I’m a subscriber also. I’m currently in the process of building an authenticated API where a user can pull their data down and edit etc. Much like Facebook or any other app that pulls from a website.
What be best the resources to use for building such an app. The biggest thing I’m unsure currently it how is data handled between iOS and your API.
You presumably pull it down in JSON as required, but then how is the data held on device? Is it in memory that’s wiped when the app closes? Core Data objects that persist and can be updated and sent back to the server or what?
Hi @jonny, thank you for reaching out! From what I understand you want to have a better understanding of how to handle and store data between your iOS app and API correct? There are many ways to do that. For example, you can use Core Data to create, fetch, and display records in your app. If you are new to Core Data, this tutorial would be helpful: https://www.raywenderlich.com/173972/getting-started-with-core-data-tutorial-2 . If you’d like to learn more with a book, there is also one dedicated to Core Data here .
If you are interested in creating web APIs and applications, Vapor is also great. If you are a video subscriber, there is a new series on Vapor that gives a great introduction to creating a web API. In addition to that, here is an article that focuses more on the creating of an API with JSON and Vapor. More resources for Vapor: Video - Create a web app with Vapor Vapor University Book - Server Side Swift with Vapor
I hope these resources can give you a better idea of how data can be created and handled. Happy coding! Best,
I’m not new to creating APIs and I have used CoreData before, but it was for an app that doesn’t connect to the net. I’ve not done much iOS work, so it’s more of a question of what are the preferred iOS ways to deal with essentially crud data when there’s an external API at the source and if there was anything on RayWenderlich that covered that specific use case
I guess in short, should I be taking my API JSON data are putting it into CoreData?
If it helps (for anyone to clarify concepts), API is a term generally that means 'Application Programming Interface", it is an interface into your codebase without providing direct access to the code. So public functions that can be called from a static or dynamic library.
However in the new era of development where we now deal with the internet as a component, an API means a way to access data from a server. And you are correct in identifying that the way to access the data is CRUD (create-Retrieve-Update-and Delete). For which mostly developers use RESTful API’s.
From the code side, you use HTTP Requests for CRUD utilising either of GET, POST, PUT, DELETE.
In the 2000’s the push was more towards XML and SOAP and now it is JSON, which is the format in which the data is passed between the server and the calling application.
Now to your question,
To create a Server side API → If you already have that in place, that’s one task easier. You do need a server to recieve and respond to the requests, you can use python, PHP, RubyOnRails, Node.js and/or even Swift.
To create the client → You can use the most basic URLRequest DataTask to get the data from an API end point. The data is received as bytes of data which you have to convert into JSON (if it is valid and possible) and use the data.(De-Serialization/Decoding)
To send data to the server, you have to convert the JSON to an array of bytes and send. (Serialization/Encoding)
It is entirely upto you as to how you want to manage the data, generally developers instantiate objects from the JSON data that are stored in memory (and can be persisted into a storage for offline use).
Thanks for your answer, I’m not new to programming, so I know what a REST API is and all that. Just inexperienced with large scale iOS apps. But I think you answered my question along with some googling. In that it seems that the JSON returned is often stored as CoreData objects and cached (potentially) when dealing with large data sets.
Mate that is an assumption and a wrong one at that.
If you are storing JSON in CoreData that is how you intend to manage it, that is not a standard behavior. However there are a couple of strategies when dealing with large data sets, if this works for you, good.
1000’s of objects, when you take players, games, teams etc in. I find that when I’m opening the app and changing my weekly team, that the data is somehow persisted when I check back in a few hours later.
So that is the the crux of my initial question. How should the data be held on the device and persisted when it’s coming from an API, rather than downloading the whole set every time the app opens. What are the best approaches?
Hi @jonny,
if you are looking at a large scale iOS apps, then the focus would be on the server side that will help retrieve data faster. It also depends on what are the requirements of the application which will differ from client to client. I can tell you about the enterprise apps that I have worked on, all of them were different with high number of users.
To give you a more generic answer to your specific question, you need to persist data on the device and the only reason for that is so that when you start the app, you can present the user with the data instantaneously giving the impression of a very fast service while you download the data in the background.
Your question I believe was more specific on how to save this data? You can use a on device cache (the most simple and common methodology) so that you have to do nothing extra and it follows your workflow when you retrieve data from a URL. The second method would be to persist it as JSON/text files on the device. Lastly you can make it complicated with using Core Data or a on device database.
At the start of the smartphone revolution (2008) most data was stored on the device, now with the connected and distributed cloud revolution, all data is stored online and retrieved everytime the user connects and stored back with the edits, etc. The offline data is generally to minimise the time of retrieval.
I know this is generic advice as I also mentioned, a solution would differ from project to project. A solution can be simple and easy to manage and maintain or really difficult and very complex. It all depends on the person designing it. So, that is a choice you have to make.
Thanks for taking the time to reply to me and for your answer. I think, what I’m taking from your answer is that a cache of some kind might work best. So as a follow up, as I’m dealing with JSON I would cache that. I had wrongly assumed having ready around on stackoverflow that I’d be having to transform the JSON into CoreData and persist it that way.
This method seems easier, is there any particular screencasts/videos or frameworks that would help or you recommend in achieving this?
Hi @jonny, I do not have any links that talk about this specific solution. The reason being simple, majority of the developers think inside the box, so the most common solutions that you could find would involve some really complex stuff, for two main reasons,
To enhance their CV’s for the next position they apply for
Because that’s what they could find on the Internet
Some of the most common ‘thinking limited by the box’ that I found is developers trying to create dynamic variables like player1, player2, player2… playerN because they miss to think of the concept of arrays. There are other such examples that I have come across and responded to on my blogs, books, code, meetings etc.
Point that I am trying to make, without going totally off the topic here, is … that you will find solutions on the internet with what is most commonly used or found - Ranking Engines.
