I've implemented the real time functionality on the Instagram API by subscribing to 5 geographies.
These geographies pretty much cover the area of Bucharest, so I'm thinking I should get a lot of action from Instagram's servers.
Here's the way I implemented everything in PHP (CodeIgniter):
I created a callback page for all 5 geographies which analyses the raw post from the Instagram API, gets the geography ID and then requests the recent photos uploaded from that area to the geography endpoint based on the respective geography ID
I parse this response and I cache the photos' data so I can retrieve it later
I show the last 30 results on http://hipstagram.ro/
The problem is that I've made a few tests by taking photos with my phone from one of these areas and sometimes my photo shows up, and sometimes it doesn't. The implementation isn't throwing any errors, but it works strangely. Thus... I have a couple of unanswered questions:
Q: Could I be missing requests? It says in the Instagram API docs that I should acknowledge the request in less than 2 seconds. Here's how my code looks like in the callback method (PHP CodeIgniter):
if ($_SERVER ['REQUEST_METHOD'] == 'POST') {
header("Content-Length: 0");
header("Connection: close");
flush();
// do stuff with file_get_contents('php://input')
// also, get new photos...
$data = json_decode (file_get_contents('php://input'));
if (is_array ($data))
foreach ($data as $geo) {
$this->db->query ("LOGGING SOMETHING HERE...");
// make some a cURL request to the geography endpoint
// get the photos, save them in the database
$this->live->updateGeo ($geo->object_id);
}
}
Q: If I'm missing requests:
is it because the callback takes too long due to the added time of $this->live->updateGeo (which waits for the cURL call to end)?
is it because my server is in Romania and all the requests from Instagram come from USA IPs?
I've analysed the raw access logs and from time to time I get a spike of requests, then a long span of silence. I'm thinking it's either because the Instagram API is not posting anything to me or because I'm not responding in less than 2 seconds. Otherwise... why are those requests taking place all at once (5-10 requests in a couple of seconds)? It's not like 5-10 people just happen to take photos all at the same time and then everybody just puts their phone back in the pocket :)
Related
I have an app and its going to have these features in it :
SCREENS :
Home { Show recent posts from all categories (API provides 30 posts per page)}
Categories {Show all Categories List }
By-Category {Show recent posts by category (API provides 30 posts per page)}
Post {Show Post Details with Comments }
User-Profile {Show User Profile with their recent posts (API provides 30 posts per page)}
Profile-Setting {Show updatable Fields and Update Button}
Now, Where i am confused :
Should I fill the whole store with API in the starting or should I
make API calls for each screen when they are opened ?
And for updating, like If user likes post then should I show a
spinner or something till API completes OR should I update the local
store value instantly and then call the API ?
There could be many approaches to solve this. mine is:
1) I would create a model/manager to handle the API requests that also have access to the same store. so for example when the screen did mount use Home.Manager.getNextPage(); and it will know already to handle the api request and also know how to handle the paging.
So all the calcs will be in the manager. and when it get the data it will update the store with it.
2) When I built an app that contained likes I have used local data as well. My approach was to set time out of 10 seconds from last like so in case the user liked more than one post I could send a bulk. so the server won't need to handle multiple tcp connection but one with multiple likes data.
The point was first store it locally(for incase the user kill the app before we update the server) and then wait for 10 s' if got new like add it to the data array and wait for another 10 s' if not just send the data to the server. do not clean this local data until server return that it saved on your db
This way you can display animation first without letting the user to wait for a feedback from the server..
The best practice is to make small API calls for each component.
You should load each screen with a loading, then call the API in
componentDidMount after receiving the response shows the data.
enter code here
For this kind of action, first, make the API call, make the like button disable, update the store after successful API call.
Disable the button because of some user double-tap. This kink of APIs is usually fast, so loading does not have a good UX. The loading will be removed before full animation. Always update store data on the response, not the request because you need to revert the store changes if the API calls failed.
I want to monitor some live scores on soccer matches. I have 2 ways to do this:
official api from the website(free)
parse websites source code myself and get data from it( need to do it every second)
What is the difference? Is calling API faster?
This can depend on quite a lot external to this specific scenario, but given the context, yes the API's would much faster. The difference is in what data is being sent/received/parsed.
In either scenario you'd need some timer to tick and parse the results (website or API) so there's no performance difference in the "wait code", but the big difference will be in the data itself that is parsed. When you call the API, chances are more likely that you will send a specific parameter or call a specific function that indicates what you're looking for, pseudo-code example:
SoccerSiteApi.GetValue(SCORE, team1, team2);
Or
SoccerSiteApi.GetCurrentScores(team1, team2);
By calling the API, you are only sending and receiving a few hundred bytes (or more depending on data) and getting back exactly what you want, that is, you don't need to parse the scores out of the values sent back since they are the scores, so no processing time is spent doing anything additional with the data itself.
If, however, you were to parse the entire web site, you would need to make an HTTP GET request (and all that entails) to get the entire page (which could be a couple hundred KB or MB depending on content) and then spend processing time extracting the exact data you were looking for, and then doing this every second.
So the biggest difference is amount of data and time spent processing it.
Hope that can help
Right, this is really working on my nerves, but Instagram has to do something about their bloody documentation.
I am already trying for a week to live update my website with new instagram posts without refreshing the page. Twitter was fairly easy, but instagram is just one big mess. Basically I use the realtime Instagram API, the callback and all that stuff is working fine, but thanks to Instagram it does not return me an ID from the post that is new, the callback only returns some basic stuff:
[{"changed_aspect": "media", "object": "tag", "object_id": "nofilter", "time": 1391091743, "subscription_id": xxxxx, "data": {}}]
with this data you are nothing, except for the Tag, but I knew the tag before this callback too so doesn't matter. It actually only tells me that there is a new post. I have tried doing the same request as when the page loads, when this callback occurs, and get the posts that are newer than those already on the page. Unfortunately I have not succeeded in this yet. I have picked the ID from the last posted instagram post, and checked if it is in the callback request, and it's not.
What am I doing wrong?
I'd appreciate some help, thanks!
Edit:
I'd like to note that this is not only a problem with the realtime api, but also with the normal API. I just don't know how to compare data so I don't get duplicates in my database(normal api), or on my website (realtime). I can't find any tutorial or documentation (Yes, I might be blind), that explains to me how to compare data. I can only find the min_id and max_id, but no explanation what these id's contains. I checked these id's with id's from results, and they do not match. It's not an ID from a media item.
I also checked the next_url, and in my logic thinking, this should be a URL to the next page (like Twitter).
Am I looking at this all wrong?
Ok strike my old answer, I changed the way I do this. Here's how I'll do it now.
I still wait for 10 hits on my Real-time subscription, when I reach 10 I send off a new thread (if one is not already running).
The sync thread queries my DB for a value, I need the last min_tag_id I used. Then I query:
https://api.instagram.com/v1/tags/*/media/recent?access_token=*&min_tag_id=*
Try it out here: https://api.instagram.com/v1/tags/montreal/media/recent?access_token=*
You'll get 20 results, and a min_tag_id value. Append that to your url, you'll see you get no results. Wait a couple of seconds and refresh. Eventually you'll get some media, and a new min_tag_id.
(You can ignore the "next_url" value they give you, you won't be using that).
Basically you only need to store that min_tag_id and query until you have no more results, that means you're done then.
When you get a subscription push, you need to query that endpoint (tag / recent).
I normally start an synchronous thread to perform this so I can answer in under 2 seconds to Instagram.
Then you parse that endpoint and look for a "next url" value.
Keep querying that end point, parsing the media and going to the next url until you find your stop condition.
For me I try to match 10 consecutive records in my DB. Basically from the tag, I store media when then meet my business rules.
The Instagram documentation is accurate and actually well written.
The realtime API is working correctly. As stated in the documentation:
The changed data is not included in the payload, so it is up to you
how you'd like to fetch the new data. For example, you may decide only
to fetch new data for specific users, or after a certain number of
photos have been posted.
http://instagram.com/developer/realtime/
You only receive a notification that an update has happened to your subscribed object. It is up to you to call the API to find out what that data is.
You can call the /tags/[tag-name]/media/recent with an access token that you have previously stored on your own server or DB. Then, you should be able to compare the data returned from that endpoint with any data you have retrieved prior, and just pull the objects that you do not yet have.
I want to get all tracks with 0 to 1 plays and am looking at the playback_count stats from http://api.soundcloud.com/tracks/90891876.json?client_id=XXX URL, where playback_count is included in the json response. We have almost 1500 sound snippets, is it possible to make a script that fetches this data ~1500 times or will I get throttled for spamming the connection to the API? We will only use this stats a couple of times to measure how our campaign is going trying to increase plays. Or is it possible to get this data in just one request?
I saw this question just earned the "Tumbleweed" badge and I felt bad.
If the tracks are all owned by the same user, you can use this endpoint:
http://api.soundcloud.com/users/{id}/tracks
If you just have a list of tracks, you can use this endpoint:
http://api.soundcloud.com/tracks?ids=123,234,765,456,etc
See the "filters" section of the docs here: http://developers.soundcloud.com/docs/api/reference#tracks
But keep in mind that although the HTTP spec does not impose a limit on the length of the querystring, the default apache settings will return an error somewhere around 4000 characters. That's probably around 400 tracks for this endpoint. Play around with it. Maybe soundcloud has a limit on the number of tracks per query.
You could put your players embedded on a website (server) and track them with Analytics. I made a script for that: http://vitorventurin.com/tracking-soundcloud-with-google-analytics/
I'm tring to search locations with the Instagram API in my application but also when testing with Apigee, I get 500 Internal server error, and Oops, an error occurred.
Apigee: https://apigee.com/console/instagram
Authenticate yourself and add this URL: https://api.instagram.com/v1/locations/search?lat=40.758896&lng=-73.985131
It should return Time Square locations. It worked a few times in the past, but currently it doesn't.
It would be an overkill to use the Foursquare api to search for locations, then pass the location id to Instagram. Is that the only way to get around this? Because once you know the location's ID it works ok.
My possible solution would be to let the user find the desired location here: http://worldc.am/id/47383924f964a520444c1fe3
And use the v2 foursquare API location ID for Instagram.
The Instagram API is pretty bad in that regards - it often just says "Oops an error occured!", without giving you any more info.
I believe their servers have a really low time out limit. Add the parameter distance=500, or even less, and you won't get this error any more. Basically, in a high density area (like a big city), you need to specify a small distance number, otherwise Instagram's server just times out while serving your request.