Call Encore now on +44 (0) 1273 722 544 or contact us
Sunday 20th, May 2012

Flex and Flickr uploading

Posted by Lenka on December 30, 2010

Flickr provides developers with the ability to upload images into a user account similar to how Facebook does. However, the standard API effectively only allows posting from an image file. A problem arises when the image you want to post is a snapshot taken by Flex from inside your SWF. Flickr does not accept raw image data from the Flash Player so you have to use a PHP script or similar to deal with the raw data, create an image and send it to Flickr. This is how it can done:

1. Authenticate User with Flickr

- Download the latest ActionScript API for Flickr and put the ‘com’ folder into your project
- This page explains how you can get a user to authenticate with Flickr and obtain a token for your application. The fix posted by rrossen on Feb 25, 2008 is especially useful.
- Make sure to save the obtained token to a variable in Flex.

2. Create a snapshot inside the Flex movie and send it to a PHP script

As an example, the following code captures content of a canvas called ‘preview’

import mx.graphics.codec.JPEGEncoder;
import mx.graphics.ImageSnapshot;
...
var snapshot:ImageSnapshot = ImageSnapshot.captureImage(preview, 0, new JPEGEncoder());

Send encoded image data to a PHP script e.g. using Cairngorm.
In the FlickUploadPhoto command:

var request : Object = new Object();
var flickrUploadPhotoEvent:FlickrUploadPhotoEvent = event as FlickrUploadPhotoEvent;

//Convert to Base64
var encoder:Base64Encoder = new Base64Encoder();
encoder.encodeBytes(flickrUploadPhotoEvent.imageData.data);

request.imageData = encoder.toString();
//send the app key, app secret and token as well so that the PHP script can send an authenticated request to Flickr:
request.appKey = flickrUploadPhotoEvent.appKey;
request.appSecret = flickrUploadPhotoEvent.appSecret;
request.token= flickrUploadPhotoEvent.token;

// set request to service
service.request = request;

// dispatch call
var call : Object = service.send();
call.addResponder(this);

3. Create a REST controller that will handle the request

- Download PHP Flickr API (current latest version: PHP5) and add the PHP files into your project
- Inside of the function that handles the request in your REST controller: decode the image data, create a temporary image and send it to the Uploader class of the Flickr API for further handling:

$imageData = $this->input->post('imageData');
$appKey = $this->input->post('appKey');
$appSecret = $this->input->post('appSecret');
$token = $this->input->post('token');

$myImage = base64_decode($_POST['imageData']);
if ($myImage != false)
{
   //Write the image to a file
   $tmpfname = tempnam("", "FC");
   $handle = fopen($tmpfname, "w");
   fwrite($handle, $myImage);
   fclose($handle);

   //request FlickrUploader to handle the upload:
   $uploader = new Phlickr_Uploader();
   $uploader->setPerms(0,1,0); //friends only
   $uploader->setAuthenticationParams($appKey,$appSecret,$token);
   $id = $uploader->upload($tmpfname,"Puma KingOf","");
   if ($id >= 0)
   {
      //handle successfull upload
   }
   else
   {
      //handle error
   }
   //get rid of the file
   unlink($tmpfname);
}

4. Change Upload.php located in the PHP Flickr API

Make the following changes to Upload.php in the Phlickr folder so that the class is more standalone:

//add variables that will hold the security data
protected $_appKey = "";
protected $_appSecret = "";
protected $_appToken = "";

//add function that will save the security data:
public function setAuthenticationParams($appKey,$appSecret,$token) {
   $this->_appKey = $appKey;
   $this->_appSecret = $appSecret;
   $this->_token = $token;
}

Changes to make in the upload function:

...
$params =  array(
   'api_key' =>  $this->_appKey,
   'auth_token' =>  $this->_token,
   'title' => $title,
...
$params['api_sig'] = md5($this->_appSecret . $signing);
...
$result = Phlickr_Request::SubmitHttpPost(self::UPLOAD_URL, $params, self::TIMEOUT);
// use the reponse object to parse the results
try
{
   $resp = new Phlickr_Response($result, true);
}
   catch  (Exception $e)
{
   //return error code
   return -1;
}
// return a photo id
return  (string) $resp->getXml()->photoid;

The above code sets the name and description of the uploaded image to ‘test’. It would be possible to send these parameters from Flex or just hard-code them to anything else.

The PHP Flickr API also provides a function for batch upload images which might be useful e.g. for a gallery managed by Flex.

Weekly tech ramblings

Posted by Jethro Grassie on November 2, 2010

Well its been another busy week or two of heated tech ramblings in the office.

Hottest discussion was probably Apple “deprecating” Java in OS X.

Apple's Java coffee cup

There was no surprise here really. Apple have been slow to keep the Apple built JRE (Java Runtime Environment) up-to-date. Anyone remember how long it took them to update to Java 6?! But the big questions were ‘Why?’ and ‘Where does this leave Java desktop apps on OS X?’

I think the ‘Why?’ comes down to the typical Jobsian control factor. If you look at the App Store model and lock-down of development of iPhone and iPad applications, no surprise Apple would want to start locking down technologies on their desktop platform really.

The more important question is where it leaves Java apps in OS X. There is still after all the OpenJDK project which has superb support for many platforms – including OS X. The single biggest issue however is the GUI implementation. This is based on the X windowing system under OpenJDK and quite frankly, under OS X these windows look awful and integrate very poorly into the rest of the OS X windowing system – Aqua. The problem for OpenJDK, as Apple have always kept the Aqua windowing system closed source, is its never going to be an easy or desirable option to integrate directly with it. In fact it would be a huge effort. Yet without that level of core integration (things like window behaviour, key-bindings, localisation etc), Java apps running on OS X will look and feel very dated compared to more standard (eg Cocoa developed) apps. There have already been calls from the community to Apple asking [pleading] for them to release the Apple developed JRE. No replies as yet and I wouldn’t hold my breath either.

Another hot topic has been the notice from Adobe they will be closing the source for the latest and greatest version of the Flex SDK for an estimated 2 release versions.

Flex closed source

Consensus in the Encore dev team is that this is simply a means to hide the prototype [crappy] code the Adobe “developers” have rushed out in the Flex 4.5 “HERO” SDK (which includes lots of features targeting mobile devices among other things) in time for the Adobe MAX conference. Reasons cited were the release cycle of the player runtimes and burdensome patch submission process. The latter particularly odd given that Adobe need as much help as possible fixing their flaky code!

Lastly much discussion around some up-and-coming cross-device/platform frameworks for native mobile applications. My personal favourite is libnui. But thats for another post (when I can get it building on my PowerPC Gentoo box!).

libnui logo

iPhlash or just a flash in a pan

Posted by Jethro Grassie on October 12, 2009

With Adobe’s announcement last week at Adobe MAX that they have added export to iPhone in an alpha version of Flash CS 5, there has obviously been a lot of discussion about this.

There are various strands of discussion, however the strand that interests myself is that of whether Apple will actually allow this.

Some background…

Apple have from the start had a very closed environment for developing iPhone applications.
Amongst many things:

  • Developers must sign-up (and pay) for the privilege of being able to publish to the iPhone.
  • Developers must use only documented API’s from the Cocoa API.
  • Developers must not publish anything that can load in other code (eg a runtime such as the Flash Player, and this point has been the most problematic to Adobe).
  • The only way to get an application onto the iPhone is by submitting it to Apple who check it conforms to all their rules before it goes onto the app store (which is the only way to distribute iPhone applications).

One of the reasons for this closed environment is so that 3rd party applications all look and work in a similar fashion, are all stable and wont interfere with other aspects of the iPhone.

The obvious problem for Adobe is that this means they cannot get the Flash Player onto the iPhone and Apple have not bowed down to the sometimes very public pressure Adobe have been putting on them to put/allow the Flash Player on the iPhone.

So what Adobe have done is found a way to allow its users to output native iPhone applications from the Flash IDE – therefore not requiring the actual Flash Player.
However, and importantly, these output applications are not Objective-C Cocoa Touch applications.
There is also as yet no information whatsoever from Apple as to whether this technique of bypassing the runtime is to be endorsed.

This last point is very important. Apple has historically been very tough when it comes to getting applications through their approval process. They have created an environment whereby they retain a very tight control of the applications that get onto the devices. And while there would be no actual Flash runtime on the device, there would be an ecosystem of iPhone development that Apple had much less control of.

The two biggest concerns for Apple would be a) performance and b) lack of look and feel.
Regarding performance, obviously to a large degree this comes down to the developer. But if the byte-code Flash spits out is of poor quality, then its down to the tooling (Adobe).
Regarding look and feel, this again in largely down to the developer, however Adobe is working on a mobile version of the Flex framework (codenamed Slider) and it would be highly likely many iPhone apps would make use of this and therefore not look and feel like iPhone apps but look and feel like Flash apps. And from a user experience perspective, this is very bad for Apple. Apple have always been keen advocates of precise and consistent user experience, as always reflected in their Human Interface Guidelines.

So all said, do you really think Apple are going to quietly let this happen?

I really hope Adobe are doing this with the full support from Apple. If this is the case, we have some great things to look forward to from Adobe. If not, well, just a flash in the pan.

Cairngorm-FX

Posted by Jethro Grassie on June 18, 2009

Over the last couple of days I have been busy porting the popular Cairngorm framework into JavaFX and have just uploaded the source into a fresh Google Code project: Cairngorm-FX

http://code.google.com/p/cairngorm-fx/

At Encore we have been very busy with JavaFX and are very excited about the technology. We also happen to use Cairngorm extensively in our Flex based projects as it really helps keep code structured/organized and when working in a team, is a real time saver (aside from coding in a reusable and scaleable way of course).

So a port of Cairngorm to JavaFX was pretty obviously going to be very useful to us! And as it will probably be useful to loads of other developers, we thought we would open-source it (under the MIT License).

Flex skinning tool

Posted by Jethro Grassie on June 7, 2009

Anyone who has done a lot of skinning in Flex will know the simplest, quickest and most effective way is to use a PNG with a scale 9 grid (via the Embed directive).

As an example, applied in CSS:

Button
{
    downSkin: Embed(source="/assets/skin_button_pressed.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
    overSkin: Embed(source="/assets/skin_button_hover.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
    upSkin: Embed(source="/assets/skin_button_normal.png",
        scaleGridBottom="23", scaleGridLeft="3", scaleGridRight="11", scaleGridTop="3");
}

So we get passed a PSD from one of the designers, export the PNG’s, then using an on-screen ruler or the guides in Gimp, work out what the scale grid parameters need to be. And its this last step that is just a bore.

So while toying around with JavaFX 1.2, I knocked together a little application which allows us to simply load a PNG, drag four guides to mark the scale grid, then click a button to copy an Embed tag with correct scale grid values to the system clipboard ready to paste into the code.

I know all of us at Encore will be using this little gem of a time-saver, so for anyone else who fancies using it too, I have packaged it up as a Java Web Start application.

Install and launch here:

Like what you see? Then get in touch;
t. +44 (0) 1273 722 544   e. contact us