We are developing an iPhone application which among other things aggregates content from different social networks to create a pulse view.
Given the bad tools for memory management on the iPhone, cached photos are quickly swapped out so this solution is our temporary one but still requires a fix. What happened to the API for photos documented on the unofficial documentation? Ever existed or removed for performance issues? http://static.twitter.com/system/user/profile_image/1050881/normal/rickm.png?1173740203 Thanks a lot! On Oct 9, 10:17 am, "Alex Payne" <[EMAIL PROTECTED]> wrote: > The changing URLs have been an asset for quick cache expiry for us, > but I understand that more predicable URLs would be easier for > developers. We'll consider changing this behavior in the next major > release of the API, but it's not going to change in the current > version. > > I would suggest caching on the client side where possible, as Joel suggests. > > > > On Thu, Oct 9, 2008 at 8:26 AM, jstrellner <[EMAIL PROTECTED]> wrote: > > > I don't think they should do anything, but ask you guys to cache the > > profile pictures yourself. By linking directly to the file, you are > > increasing their Amazon costs. It doesn't take much to cache it > > yourself, and then every time someone does an update, you just check > > to see if the old URL that you have matches the new one, and if it > > doesn't, go get another copy of it to replace your cached file. > > > I am not sure if they have encouraged, or discouraged hot-linking to > > their files, but it probably is the best solution to cache it, and one > > that Twitturly uses. > > > -Joel > > > On Oct 8, 4:25 pm, Nicolas Grasset <[EMAIL PROTECTED]> wrote: > >> Is there a way to get a static profile picture URL when using the API, > >> since picture updates will break old links? > > >> My > >> photo:http://s3.amazonaws.com/twitter_production/profile_images/38643882/av... > > >> ... will have a different URL if I change it on Twitter, which means > >> we cannot trust our local cache of events, which means we would need > >> to call the APIs for all events all the time. > > >> And in our case that is not really an option. > > >> Thanks!! > > -- > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
