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 7 years ago.
Improve this question
I'd like to get the data of a website. I'd like to display the table in an app. Do you have an idea how I could do it? Thanks for your answers!
Usually, you'd want the maintainer of the data you need to supply some API for machine-to-machine communication (a REST JSON web service, for example).
Since you are asking how to display the table in an app:
the easiest way would be to just point an UIWebView that way and go from there.
a more native look might be acomplished by parsing the data. As you included several 'parsing' tags, I guess this is what you'd prefer.
The problem with HTML scraping web pages (what you probably hope to do) is that the data you are looking for and foremost it's structure is prune to changes. If some unexpected changes can easily break your parser.
Thus, if you go for doing that (which might be prohibited by your school or other publisher, especially in germany), try to parse the data on your server and offer an web service for your app yourself. This way, you can react to changes of the structure faster and do not break the app for your users.
Seriously consider asking the school for an API.
Related
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 last year.
Improve this question
As the title suggests, I'm building a simple chat app in Node/Express + React, and I'm using socket.io to get real time updates.
However, other than the chatting itself, rest of my app is very basic (registering, signing in, creating rooms etc), and while it's definitely doable to make all those requests just socket emits, it feels like bit of an overkill.
So I was thinking of creating a regular REST API for that stuff and outsourcing it into a separate file, then creating another file just for the chatting function itself, where I'd use socket.io, but I'm afraid that it may seem a bit unprofessional, or leave an impression that I don't know how to use sockets well enough.
Key point: When finished, this app will be posted to my portfolio, so I'm not very concerned about what just "can work", but rather what's the best and cleanest way to do it? Should I switch everything to sockets and use them even for basic fetching of lists and stuff? Or is it better practice to mix the two, and use REST for, well, the rest?
In my experience, To mix the two is the best way to do that.
I did that in many projects and it worked well.
I surely think that modularity is the best way to make code clean and qualified.
So, to use both of regular REST API and websocket is more professional.
Thank you.
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 4 years ago.
Improve this question
I was wanting to start creating an app for users to store files into their drive acc.
I was looking at Google's API here GoogleAPIClientForREST.podspec
I have created a pod file etc. However can someone tell me if I need the whole API file or just certain parts?
Also I see that this is GSuite related (as in I found it through here:
G Suite APIs for iOS), though this was the only way to access the API.
Do I have to pay for the API access?
Like paying for GSuite?
Its best to not pick apart the file until you actually know what its doing. A lot of these libraries are interwoven. That being said. The APIs themselves are normally standalone. So if you are not going to be using all of the apis you should be able to remove them.
These for example
s.subspec 'Books' do |sp|
sp.dependency 'GoogleAPIClientForREST/Core'
sp.source_files = 'Source/GeneratedServices/Books/*.{h,m}'
end
s.subspec 'Calendar' do |sp|
sp.dependency 'GoogleAPIClientForREST/Core'
sp.source_files = 'Source/GeneratedServices/Calendar/*.{h,m}'
end
I have personally never tried to remove them. I suggest you start with one or two and work your way down.
No you don't need to pay to access google drive api. The code for Gsuite should be the same unless you are looking at something that has domain wide delegation set up.
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 7 years ago.
Improve this question
I would like to have a URI like this /car/toyota, however I don't want the car resource to map to a database table for example. Instead I would like car to just be resource that is used for information retrieval only (ie. no POST, PUT, or DELETE on it), and /car/toyota/ would retrieve that data somewhere else, say through another REST API on another web server that provides this information.
Is this good design?
This probably belongs on something more like https://softwareengineering.stackexchange.com/
That said, this question depends entirely on the infrastructure of the environment you're making your REST requests on. If you have the ability to control the REST API on the web server providing the information, there's really no reason to wrap that API in another API. All of the call forwarding and potential necessity to translate from one request format to another really just adds un-necessary overhead.
That said, if you're accessing an API that you have no ability to re-format, or if you're accessing an API that you don't want client servers talking to directly, then there's a potential design perk for wrapping a different REST API in your own read only API.
Unfortunately, without having a clear picture of the entire architecture and the problem you're trying to solve, it's pretty difficult to decide if a wrapped API is a good design or not. My only advice is the preferred approach would be to edit the existing API if you can, but that isn't always practical.
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 5 years ago.
Improve this question
I want to make an app like Instagram but the problem is where to store all text and images data, I have used Instagram when there is no connectivity available then app will show the last feeds even when app is freshly openend (not from background). It uses core data or sqlite.
I came across a scaling presentation from instagram a little while back where they talk how they started, using what and then how they approached the challenges.
See the link: http://www.scribd.com/doc/89025069/Mike-Krieger-Instagram-at-the-Airbnb-tech-talk-on-Scaling-Instagram
Hope this helps.
It's not known what Instagram uses. Use whatever you feel most comfortable with. Anything is possible with any storage technology, although some might fit better than others. Also, regarding your question on "core data or sqlite", you can use Core Data with an SQLite database as a backend (way easier than accessing raw SQL). You can also use other backends with Core Data: binary and XML.
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 9 years ago.
Improve this question
I need to create an app that does some communication with a server.
My app must post some requests to server, to aspx webservices. Then get back some JSON/XML response.
The question is do I need Core Data?
IMHO it would be enough to have a UIViewController with text field items and to perform submit to provided server webservice URL. The result could be processed with some Json/XML parser library and showed in UITableViewController.
So, I not sure do I have to use Core Data? And why? :)
No you don't have to use core data in order to communicate with a web service/JSON service - you can do exactly as you describe. The only need for core data is if you want information you download from the web service (or created by the user during the session) to remain available between hard shutdowns of the app. (or be available when you have no internet connection)
I'm not sure you understand what core data is.
Core data is a way of communicating to localised sqlite databases without using sql code (as it were). It effectively creates objects that you can use to manipulate and use databases.
To download and post data to and from the internet you don't need to use it at all, unless you want to store the data when you would use it to download the data and store it in a localised database for use later.
A better way to do this though would be to just download the XML/json file directly to the working directory of the app and use it from there (if you want offline/cached use from it).