boncey / flickr4java Goto Github PK

The discussion here indicates that a 512 byte buffer size may be a little small.
It may be more efficient to increase it to 8,192 bytes.

http://stackoverflow.com/questions/236861/how-do-you-determine-the-ideal-buffer-size-when-using-fileinputstream

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Groups methods that need to be implemented.

• flickr.groups.join
• flickr.groups.joinRequest
• flickr.groups.leave

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Cameras methods that need to be implemented.

• flickr.cameras.getBrandModels
• flickr.cameras.getBrands

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Urls methods that need to be implemented.

flickr.urls.lookupGallery

I'm still thinking it would be nice if Flickr4Java was published to Bintray (github's long lost sister).

Check it out: https://bintray.com/

Hi Allan, I've just made a bug fix (http://www.flickr.com/groups/api/discuss/72157631843876999/#comment72157631918404625).

How do I go about doing a release for the downloads page?
Or would you rather do it?
I'm guessing it will be a 2.1 version as it's a minor fix with no API changes.

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Topics methods that need to be implemented.

• flickr.groups.discuss.topics.add
• flickr.groups.discuss.topics.getInfo
• flickr.groups.discuss.topics.getList

Rough proposal to tidy up the unit tests.

• Change to use JUnit annotations (I think I can use Rescripter (https://github.com/activelylazy/Rescripter) to take the grunt work out of this).
• Merge common code into base classes - the code in the setup methods seems to have a lot of duplication.
• Tidy up the use of data in properties files, document better and fail early if data is missing.

I'm happy to take this on as a low priority task.

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the People methods that need to be implemented.

• flickr.people.getPhotos
• flickr.people.getPhotosOf
• flickr.photos.people.add
• flickr.photos.people.delete
• flickr.photos.people.deleteCoords
• flickr.photos.people.editCoords
• flickr.photos.people.getList

I think we should probably wrap up the various Exceptions thrown throughout the API into a common run time exception.

Something like:
public class Flickr4JavaException extends RuntimeException;

What do you think?

Hi,
I am new to flickr4java. Is there any method through which i can know that whether a particular photo is present in a set or not.
I am using the following code to get all photos in flickr.

  PhotosInterface Pface= flickr.getPhotosInterface();

PhotoList<Photo> PL = Pface.recentlyUpdated(thisDate, null, 0, 0);

for (int i = 0;i<PL.size();i++)
        {
    Photo p= PL.get(i);
    //Want to check if the photo p is present in a set or not.
    }       
}

I'm heading out of town, would like to do a build on Friday if possible. For completeness, this is the last missing piece (besides PushInterface).

Any issues if I do a build Friday? Is there anything you'd like to add before hand?

Just wondering what version of Java we should be supporting.

Should we stick with 1.5 as it is now?
Not sure what new features we might need from 1.6 anyway.

I think it's probably a good idea to set the compiler version correctly so we don't accidentally include some new feature.

I use src/java/test/UploaderTest.java to try to upload files. and I upload some photos successfully.
but, when I upload this photo
(http://image.baidu.com/detail/index?from=1&pn=0&picture_id=6583709650&album_id=329264546&app_id=578130&user_id=849638013&column=%E6%98%8E%E6%98%9F&tag=%E6%B1%A4%E5%94%AF&sort=0#pn0&-1&id6583709650) ,
I failed.... it says “”, when I change to upload other photos, it works! but when I upload this photo, it failed any way......

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Stats methods that need to be implemented.

• flickr.stats.getCollectionDomains
• flickr.stats.getCollectionReferrers
• flickr.stats.getCollectionStats
• flickr.stats.getCSVFiles
• flickr.stats.getPhotoDomains
• flickr.stats.getPhotoReferrers
• flickr.stats.getPhotosetDomains
• flickr.stats.getPhotosetReferrers
• flickr.stats.getPhotosetStats
• flickr.stats.getPhotoStats
• flickr.stats.getPhotostreamDomains
• flickr.stats.getPhotostreamReferrers
• flickr.stats.getPhotostreamStats
• flickr.stats.getPopularPhotos
• flickr.stats.getTotalViews

When uploading large files, a stream is passed to the API:

Flickr.getUploader().upload(InputStream, params)

However, REST.java buffers everything in to a ByteArrayOutputStream before passing it to the scribe OAuth library. Therefore, uploading large files can often cause out of memory errors (depends on the size of file and heap of course).

Scribe OAuth (as far as I know) doesn't support any streaming yet, so we could either create our own implementation, swap out for an implementation that does support this, or ask and wait for those guys to fix theirs.

I've opened an issue on Scribe related to this:

scribejava/scribejava#347

in looking at the build.gradle file, I noticed the following
version = '2.2-SNAPSHOT'
group = 'com.flicr4java.flickr'

It appears the group name has a spelling error (missing k in flicr4java.flickr), is it supposed to be this way or is it a typo ?

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Collections methods that need to be implemented.

• flickr.collections.getInfo
• flickr.collections.getTree

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Photosets methods that need to be implemented.

• flickr.photosets.removePhotos
• flickr.photosets.reorderPhotos
• flickr.photosets.setPrimaryPhoto

Most JUnit tests have the exact same code in setUp. I created a super class, Flickr4JavaTest, if the setUp is the same then it can be superclassed and the setUp method removed, so any defect fixes to the super will be made in one place.

Having just run the tests for the first time in a while I had a lot of trouble getting them to pass.

This is mainly because they rely on "live" data on Flickr.
Naturally a bunch of my stuff had changed so I needed to edit the tests (whilst also trying to not make them specific to my data).
There were also other issues:

• My token didn't have delete privileges so the test couldn't delete the photos it had uploaded.
• The user needs to be a Pro account for some API calls so using a free dummy account doesn't work very well.

Not sure what the solution is to this problem is but here are some ideas.

Split the tests up

Split the tests into dev tests that stub out the Flickr API and integration tests that hit the live API with the caveat that they will only pass if you have data in a certain state.
Stubbing out the Flickr API is obviously a lot of work though - though I wonder if there's a clever way to generate that stub from the Flickr reflection call.

Reduce what's tested

We could reduce the amount of stuff that's being tested and/or make it less strict - eg, rather than check a photo has ten favourites, just check it has at least one etc.

Any other ideas?

It appears a call to getGroups for both PeopleInterface and the PoolsInterface is nor problematic I get:
[Fatal Error] :1:1: Content is not allowed in prolog.

The code to do this is:

                REST rest = new REST();
        rest.setHost("www.flickr.com");

        Flickr flickr = new Flickr(apiKey, secret, rest);

        Auth auth = new Auth();
        auth.setPermission(Permission.READ);
        auth.setToken(myToken);
        auth.setTokenSecret(myTokenSecret);

        RequestContext requestContext = RequestContext.getRequestContext();
        requestContext.setAuth(auth);
        flickr.setAuth(auth);

        PeopleInterface iface = flickr.getPeopleInterface();
        Collection<Group> groups = iface.getGroups(userId);

Can I use Flickr4Java to upload movie files to Flickr?

It would be nice if flickr4java would know 2 more sizes: something like

LARGE2048 and LARGE1600

so that PhotosInterface.getSizes(String aPhotoId) would work properly.

1024 often is too small but the original size might be too big, so 1600 and 2048 are (imho) somehow handy sizes and actually i would require it.

I started to add that here, but it is not yet working ...
... and if there is somebody who already added other sizes ... he might implement that fast and without errors.

i'm looking forward for a feedback.
maybe i could help doing it.

(but at time i'm struggling with the fact that the project is not building with maven ... which is another problem ... and which i already noted to some of the developpers)

Was thinking we should do a project page at some point.
It can contain release notes, download links and links to sample code etc.

Could even use this new feature:
https://github.com/blog/1081-instantly-beautiful-project-pages

Just realised the Auth example is out of date.
Someone is trying to use it and of course it doesn't work. http://www.flickr.com/groups/api/discuss/72157629352276563/#comment72157629366263773

I'll try to put something up quickly but we should probably look at adding some other examples; upload, add to set etc.

The build seems to be borked. It looks like some sort of merge problem. For example:

[javac] Flickr4Java/src/com/flickr4java/flickr/cameras/CamerasInterface.java:288: error: class, interface, or enum expected
    [javac] import java.util.Map;
    [javac] ^
    [javac] 100 errors
    [javac] 1 warning

And the file does indeed look weird:

}
>>>>>>> 8080af10a7f34bdce972d0e96765084e14e113f0
=======
/**
 * @author acaplan
 */
package com.flickr4java.flickr.cameras;

import java.util.ArrayList;

Hope it wasn't my fault! :)

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Replies methods that need to be implemented.

• flickr.groups.discuss.replies.add
• flickr.groups.discuss.replies.delete
• flickr.groups.discuss.replies.edit
• flickr.groups.discuss.replies.getInfo
• flickr.groups.discuss.replies.getList

... add JSon Response

Hello. I think a compiled version of this library would make it easier for people to import it. Would that be possible?

There's a lot of classes like PhotoList which seem to be just a way to make a list typesafe. We can do this in 1.5 with Generics. It could mean anyone using these in their code would need to re-code but it would be a very small change. More specifically, probrably change to SearchResultList, which does have use as far as pagnation goes

Would you consider moving this project from Ant to Maven or Gradle?

The main advantages are of course:

• Dependency management (instead of lib folders)
• Convention over configuration

I only really care about the second advantage for my own projects as I don't really have to read/write the build.xml in this project. The first one is quite important for me because I'd like to consume Flickr4Java in Groovy scripts using Grapes. Groovy scripts are distributed as single files (normally), so being able to pull down Flickr4Java and its dependencies from Maven central (for example) would be very nice.

Of course, if Flickr4Java was published to Maven Central using some other mechanism, I guess I wouldn't care that much :)

Anyway, if this is something you'd consider, I'd be happy to give it a go and issue a pull request. It looks likes the Flick4Java build is pretty simple.

I'd prefer Gradle because it understands that humans don't speak XML and that build scripts need to contain code sometimes, but Maven is good too.

Hi,

I am trying to get the info of some image passing photo_id but The code dont run.

PhotosInterface photoInterface = new PhotosInterface(flickrConsumerKey, flickrConsumerSecret, new REST());
try {
com.flickr4java.flickr.photos.Photo photo = photoInterface.getPhoto(photoId);
} catch (FlickrException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

this method getPhoto, call getInfo which I need to passing secret (optional).
how can I call this method, I just want the Info about some image

Am I missing something? Thx!

Need to re-brand licensing, code etc from FlickrJ. This must maintain the references required by FlickrJ's license agreement

Hi,

I met a problem when using the tag interface like:

Photo e=flickr.getPhotosInterface().getPhoto("8629684094");
for(Tag g:e.getTags())
{ System.out.println(g.getValue());}

When the tag contains only one word, it works fine. But if it contains more than one word, it returns a string without space. For example, for the photo: http://www.flickr.com/photos/xaviersam/8629684094/, it contains a tag: "hitech filter", but the above code returns "hitechfilter".

I want the function to return a tag with space, can you give some advice?

Thanks very much

This isn't working currently, get SOAP working and make sure JUnit tests are running

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Galleries methods that need to be implemented.

• flickr.galleries.addPhoto
• flickr.galleries.create
• flickr.galleries.editMeta
• flickr.galleries.editPhoto
• flickr.galleries.editPhotos
• flickr.galleries.getInfo
• flickr.galleries.getList
• flickr.galleries.getListForPhoto
• flickr.galleries.getPhotos

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Favorites methods that need to be implemented.

• flickr.favorites.getContext

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the PhotosetsComments methods that need to be implemented.

• flickr.photosets.comments.addComment
• flickr.photosets.comments.deleteComment
• flickr.photosets.comments.editComment
• flickr.photosets.comments.getList

The github downloads page is now deprecated.
They no longer allow hosting of zip files etc.

They encourage us to use the 'zip' button on the project home page that downloads the latest version.
I've updated the README to use that link now.

However, if we want to do releases and publish to mvnrepository.com we'll need a place to host our versioned releases.

The Maven Guide to uploading artifacts to the Central Repository says to use the Sonatype OSS Repository which seems to be free.

I'll investigate getting a release hosted there first.

I'm quite a fan of letting my IDE format my code for me whenever I save changes.

Do you object to me making some code formatting rules for Eclipse then applying them to all the code?

It would be broadly in line with how the code is laid out now - same bracing styles and indentation etc.
I'm just too lazy to do all this by hand when I write code. :-)

I can then check in the formatting rules for everyone else to use locally too.

Need to create one

Hi,

thanks for the update of flickr.getTagsInterface().getListUserRaw.

But the following code still returns: "com.flickr4java.flickr.FlickrException: 1: User not found":
for (TagRaw c: flickr.getTagsInterface().getListUserRaw("UserId")){..........}

it may track back in TagsInterface.java, line 367:
throw new FlickrException(response.getErrorCode(), response.getErrorMessage());

so there is something wrong in
Response response = transportAPI.get(transportAPI.getPath(), parameters, sharedSecret);

I think the problem happens somewhere in defining METHOD_GET_LIST_USER_RAW. I happened to modify line 355: parameters.put("method", METHOD_GET_LIST_USER_RAW); to the following code:
parameters.put("method", METHOD_GET_LIST_USER);
the error disappear but c.getRaw() returns many "null"s.

I am not familiar with HashMap or Map class and have no idea how to debug further.

Any suggestions?

Need to add list of contributors since Flickr4Java was born.

Size Name URL extension
150x150 "Large Square" _q
320x "Small 320" _n

Updated documentation is here:

www.flickr.com/services/api/misc.urls.html
www.flickr.com/services/api/flickr.photos.getSizes.html

Hi,
I'm developing a flickr group tool for group admins and am using flickr4java

In PoolsInterface.java
public PhotoContext getContext(String photoId, String groupId)

the element "count" is not handled, instead I get a
"unsupported element name: count"

... which is pretty anoying, because i get thaousands of it ... ;)
It took me a while to find the origin of that
the error message isn*t really a useful hint from where its coming.

In fact, regarding flickrapi docs, no element "count" is delivered, as shown here:
https://secure.flickr.com/services/api/flickr.photos.getContext.html

Moreover, if I patch PoolsInterface#getContext, to
System.out.println("count: " + element.getAttribute("count"));

there is no value printed :(
I think its an issue in the flickrapi, but although I could patch the class, maybe you consider to implement a way for your users, to suppress this message? I'd highly appreciate ;)

anyway, thank you for the great work!
regards

• nik (flickr.com/photos/nixart)

There's a test (CompletenessTest) that interrogates the API and lists methods we've not implemented yet.
I'm gonna raise separate issues for each thing that needs implementing which will make it easier to split the work.

These are the Push methods that need to be implemented.

• flickr.push.getSubscriptions
• flickr.push.getTopics
• flickr.push.subscribe
• flickr.push.unsubscribe