While using your Instagram library, I've encountered two problems which I've tried to fix with this commit:
Fixing two bugs:
- the id for a media should be on a String format instead of long
- the created_time is in seconds, but java.util.Date needs the value in milliseconds
The pagination ids can also contain underscores, so they've been chan…
…ged to String objects as well
Are you sure when it returns and underscore it is still a valid id?
I am thinking maybe that when it has an underscore it is the media id + the user id. e.g. 123457890_123456
I don't know if this is random behavior or only happens when it is returned in paginated response, but if this is not a valid id then probably the best approach would be to only use the part of the string that represents the media id when constructing the media object.
From my experience using my fork on a live platform, the ids with underscore are still valid ids. While testing the spring-social-instagram library, I didn't encounter this issue personally so I agree that it might seem rather random. That being said, this type of ids where present for both media and pagination ids when I encountered them.
Personally I wouldn't spend too much time speculating if and/or why this might be the case, especially since the documentation of the Instagram API isn't especially clear on this point.
I've just encountered the same problem with the ID and was about to submit a pull request. I won't bother until this one is sorted out :-)
@sigbjod I've not personally experienced this and would like to see some sort of API response from Instagram before merging this. Is there a set of steps to take to see these ID's you speak of?
I fired off a search for the tag #liverpool on https://api.instagram.com/v1/tags/liverpool/media/recent?client_id=CLIENT_ID
and now that I take a closer look it would seem that @codeconsole's reply here above seems correct. In the case where the ID is on the form xxxx_yyyy the yyyy-part seems to be the user id.
See https://gist.github.com/3020606 (where I seem to have broken the formatting.. sorry) and you'll see some of these IDs from the #liverpool-search.
I seem to be able to use either form of the ID to retrieve the data. The following URLs produce the same result on my box:
Actually it seems as if only the first part of the ID is used for the lookup. This works:
But not this...
My code passes the ID-part straight to Spring Social Instagram.
@j0hnk are you saying that this pull request isn't necessary?
It is definitely necessary, but whether or not it addresses the issue properly is the question.
@sigbjod Does your pull request take into account the findings of @j0hnk?
Sorry for taking so long to reply, but I've finally had the time to check this out in detail. A quick session with the Instagram API lets me believe that @j0hnk is onto something regarding the construction of the id. That is, if a composite id is present, it seems to be of the type photoId_userId.
Now, let me answer your question; no, my pull request do not take into accounts @j0hnk's findings since I do not believe it is a good idea to start parsing the ids returned by the Instagram API (as mentioned in an earlier comment).
I agree that parsing the IDs might lead us down a path to confusion. From what I can tell it seems like followgram.me, one of the better instagram web frontends, seems to be (blindly..) passing around IDs on the form photoId_userId.
http://followgram.me/i/213664859543642465 is the same as http://followgram.me/i/213664859543642465_12411351
So changing "long" to "String" does indeed seem to be the easiest way out but it might not be the cleanest solution and it would be nice to see some info from Instagram regarding this.
Alright...I'm going to continue to keep an ear on this thread and, unfortunately, have to rely on your guys work and research on this issue as I've been a bit consumed with other projects. If a consensus is reached on what is going on here and how best to handle this ID oddity I will be sure to merge any pull requests as soon as I can and release the update.