Jump to content

Anyone got the code for GetImage?


Recommended Posts

Posted (edited)

Image is the superclass for all Image classes.

BufferedImage extends Image and is what you want to use when drawing.

ImageIO.read();

returns a BufferedImage, therefore your getImage() method should also return a BufferedImage.

 

You should promote loose coupling where you can.

 

The majority of image drawing methods in Graphics2D (mostly inherited from Graphics) take Image, as they do not require any specific methods located in BufferedImage. For this reason, returning Image is the less restrictive option.

Saying that people should return BufferedImage just because that's the specific implementation of the Image is pretty much your own preference. Would you also use LinkedList or ArrayList as a return type rather than List? It's fine if you do, but at least when writing API for others to use, you should use the highest level class or interface you can.

 

Also to add to the 3 (identical) previous answers; some image hosts may have browser checks to prevent automated use. This can be bypassed by adding the User-Agent property.

	public static Image loadImageByURL(String surl) {
		Image img = null;
		try {
			URL url = new URL(surl);
			URLConnection urlc = url.openConnection();
			urlc.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11");
			img = ImageIO.read(urlc.getInputStream());
		} catch (IOException ex) {
			Logger.getLogger(ResourceLoader.class.getName()).log(Level.SEVERE, null, ex);
		}
		return img;
	}
Edited by FrostBug
Posted

 

You should promote loose coupling where you can.

 

The majority of image drawing methods in Graphics2D (mostly inherited from Graphics) take Image, as they do not require any specific methods located in BufferedImage. For this reason, returning Image is the less restrictive option.

Saying that people should return BufferedImage just because that's the specific implementation of the Image is pretty much your own preference. Would you also use LinkedList or ArrayList as a return type rather than List? It's fine if you do, but at least when writing API for others to use, you should use the highest level class or interface you can.

 

 

You are right, I wasn't thinking about the drawImage methods in Graphics. :facep:

Posted (edited)

 

You should promote loose coupling where you can.

 

The majority of image drawing methods in Graphics2D (mostly inherited from Graphics) take Image, as they do not require any specific methods located in BufferedImage. For this reason, returning Image is the less restrictive option.

Saying that people should return BufferedImage just because that's the specific implementation of the Image is pretty much your own preference. Would you also use LinkedList or ArrayList as a return type rather than List? It's fine if you do, but at least when writing API for others to use, you should use the highest level class or interface you can.

 

Also to add to the 3 (identical) previous answers; some image hosts may have browser checks to prevent automated use. This can be bypassed by adding the User-Agent property.

	public static Image loadImageByURL(String surl) {
		Image img = null;
		try {
			URL url = new URL(surl);
			URLConnection urlc = url.openConnection();
			urlc.setRequestProperty("User-Agent", "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11");
			img = ImageIO.read(urlc.getInputStream());
		} catch (IOException ex) {
			Logger.getLogger(ResourceLoader.class.getName()).log(Level.SEVERE, null, ex);
		}
		return img;
	}

 

 

@FrostBug are.....are you a wizard?

p.s. I thought @Explv was a wizard before, but he just got WIZARDED wtfffff

Edited by Paradox68

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...