| Comments

Before Windows Live Writer was even publically released, I was glad to have been an early beta user/tester of the product.  The team thought early about an extensible model and it has been my content authoring tool ever since.  It has allowed me to use *my* preferred content workflow with my cloud providers/formatters/tracking and other such plug-ins due to this extensibility.

Flickr4Writer screenshotOne of the first plugins available was one of mine I called Flickr4Writer.  It was pretty popular (as most ‘firsts’ are) and I got a lot of good feedback that changed the functionality and user interface.  Is it the best design/code?  Probably not, but it seems to have served the needs of many folks and I’m happy about that.  I put the code into the Open Source world around the same time and it never received much uptake there and only one contribution of literal code (plenty of feedback). 

I depended on an early library that was created called FlickrNet.  I contributed a few small fixes during my development of Flickr4Writer to the cause.  This has been a very popular library and I think even used in some close-to-official Flickr apps for the Windows platform.  It served my purpose fine for a LONG time…until 2 days ago.

Because Flickr4Writer was pretty much complete and ‘bug-free’ for the mainstream cases, it hadn’t been touched in years and there was never any need.  I felt no need to fiddle with code at all that didn’t need to be messed with.  Another factor also was that Live Writer plugins are pretty locked on .NET 2.0 for loading, so there was no real incentive for me to move to anything else.  Two days ago I started getting emails that Flickr4Writer was not working anymore.  One writer sent me a very kind note detailing what he felt the problem was due to the recent API changes required by Flickr.  One 27-June-2014 the Flickr API went SSL-only and pretty much all my code broke.  Well, to be true, the version of FlickrNet I was using no longer worked.  It was time for me to update.

I spent a few hours today switching to the latest FlickrNet library (and using NuGet now since it is published that way now) and take the time to switch over all the now-obsolete API usage my app was using.  I hit a few speed bumps along the way but got it done.  I sent the bits to a few of the folks that emailed me and they indicated it was working so I’m feeling good about publishing it.  So here is the update to Flickr4Writer, version 1.5 and the steps:

  1. Close Windows Live Writer completely
  2. Uninstall any previous version of Flick4Writer from Control Panel on your machine
  3. Run the new installer for Flickr4Writer by downloading it here.
  4. Launch Windows Live Writer again
  5. Go to the Plugin Options screen and select ‘Flickr Image Reference’ and click Options
  6. Step #5 should launch the authentication flow again to get new tokens. 
  7. Pay attention to the permission screen on Flickr web site as you will need the code provided when you authorize
  8. Enter the code and click OK
  9. Resume using Flickr4Writer

This worked for a set of folks and a few tests I did on my machines.  Performing the re-authentication is key to get the updated tokens for the API usage for this plugin.  I apologize about making folks uninstall/re-install but the installer code was one thing that was really old and I just didn’t want to spend too much time getting that working so I just created a new one.

I’m really glad people find Flickr4Writer useful still and I apologize for not having an update sooner (I actually didn’t get the notice that Flickr indicates was sent out…probably in my spam somewhere) but I appreciate those users who alerted me to the problem quickly!

Hope this helps!

| Comments

This is a public service announcement for my Flickr4Writer project.  It was recently brought to my attention that Flickr has some privacy settings that users can opt-in for in their account to protect their images.  Some users felt that my plug-in for Writer was not honoring these settings.  Truly, I didn’t know about them.  You can read the thread on the discussion lists here if you are so inclined.  For me it came down to a couple of items:

    • Flickr enables users to set a flag to prevent “blogging” of their images
    • Flickr enables users to be hidden from 3rd Party/API searches

First, a note on the “blogging” flag.  This is a setting under your Flickr account privacy tab labeled Who can blog your photos or videos?.  To me, this setting is a little misleading because the description of it actually reads:

This means that anyone who does not match at least the contact level you select will not be able to see the "Blog This" button. (Source: http://www.flickr.com/account/prefs/blogging/?from=privacy 07 NOV 2008)

This setting is clearly for the “Blog This” functionality that shows up if you are logged into Flickr as a non-anonymous user and browse photos.  There is some functionality for them to integrate directly with your blog engine to do some one-click blogging of photos and videos.  Because of the way the setting is named however, some users interpret “blogging” in the broader sense.  flickr4writer was challenged as one violating the principal of this setting.  Since the setting ONLY enables authenticated users to even blog (the setting options go from any Flickr user (non-anonymous) to your specific friends/family settings.  flickr4writer does not use any authentication, so browsing any photos has the appearance to violate this term if the plugin enables an anonymous user to browse and select photos in a tool that is build for “blogging.”  While I draw the correlation that flickr4writer is basically a shell to the web site and does not do anything different than an anonymous user being able to browse and grab an image URL, it is the essence of the rule that I was alleged to violate.  One challenge here is also that the API is poorly designed in this regard because the “canblog” setting is returned only at the photo level even though it is an uber setting for the user’s account.  I think it should be a filter param of the photos.search API call.

The second setting about 3rd Party/API blocking from searches gets even more interesting.  First, this totally makes sense.  Again, it was a setting I wasn’t aware of.  You can change your setting under a section titled Hide your photostream from searches on 3rd party sites that use the API?  Great.  You’d think that once a user selected this setting that any search would filter out their photos/vidoes at the API level right?  Wrong.  flickr4writer uses photos.search calls to query data (actually technically the library that Flickr4Writer uses does).  Again, by definition of this API, only public searchable photos will be returned.  UNLESS you specify a user name.  What?!?!  Yes, that’s right…if you specifc a user name, their results will come back in the API call.  Read that again.  If you specify a user name in flickr.photos.search it will not honor the user’s privacy setting.  So this sucks for me as an API developer/consumer who wants to honor those settings.

So on to the resolutions.  First, I added authentication.  flickr4writer now requires you to have a valid Flickr account to even use it (their accounts are free).  This helps with the first part about blogging.  If a user has specified they do not want their content to be blogged, I honor that and will alert the flickr4writer user with a message that the user they searched prevents blogging and no search results will display.  I feel that this complies with that setting within my application.  If a user wants to bypass my app and copy/paste the URL to the photo/video still…that’s Flickr’s problem now, not mine.  Adding authentication also enabled me to comply with the blogging settings of users because it identifies who the user is and whether or not they can blog the content.

The second thing I modified was to only return content that had Creative Commons or No known license attributes.  This actually makes sense and I needed to do it for a while.  The licenses I filter for are identified in the flickr.photos.licenses.getInfo API.  So if a user has content that is “All rights reserved” then it will no longer show up in the search…even if you are the owner of that content.  I’m interested in feedback on this one if you think I should do a check to see if you are the owner and allow you to see licensed content…leave a comment on how you feel about this one.

For the setting of hiding from 3rd parties…I cannot resolve this.  There is no setting for me to look at.  I’m quite disappointed that Flickr isn’t doing this at the API level as I think that they are violating the user preferences by enabling a loophole.  Should they enable a setting for this (I think they just need to fix the API), I will enable my application to comply even more.  Please if you are a Flickr user who has set this privacy setting, let Flickr know that you want it to be honored.

The authentication adds some initial screens to the use of flickr4writer.  When you launch the plug-in from within Writer, you’ll now see some prompts to authorize the application with Flickr.  There will be a button that will take you to Flickr to authorize the action.  This is only required one time and you won’t see it anymore unless you de-authorize the application on your account (which you have the complete control to perform).

Please upgrade to the latest version.  You will have to uninstall any previous version before installing, but will not lose any settings.  Thanks for your assistance in helping keeping flickr4writer compliant.

| Comments

One area where Silverlight can plat an interesting role for your web applications is wherever file uploading to your server needs to be done.  This may sound odd to think of it that way, but if you’ve ever done file upload in web apps (for larger sizes, chunking, etc.) sometimes it is no fun and involves a lot of Javascript.  There is a video demonstrating on how you can do file upload with Silverlight 2 and also helps demonstrate the OpenFileDialog API within the runtime.

I remember seeing a multi-file uploader that Jose Farado had started back in Silverlight 1.1 days.  It followed the UI inspiration from the Flickr picture uploader and I really liked it.  Jose has been real busy since then and hasn’t had much time to update his older 1.1 samples to Silverlight 2, but a few others have started to emerge.

Over at the Silverlight community gallery, you can find a bunch of user-submitted content that includes full solutions, samples, helpful tips, etc.  Right now you can find pointers to 2 solutions implementing multi-file uploading using Silverlight as a UI and controller in the process.

One is from Michiel Post and the other is from InetSolution, Inc.  Both of them provide similar functionality.  (NOTE: none provide full source code at the moment or have alluded that they will.)  One thing that the team at InetSolution did after receiving some inquiries about their work was to write a bit about it in an ‘under the hood’ post about their effort so far.

UPDATE: Michiel Post has now updated the control and provided source on Codeplex.

I’d love to see either of these adapt the UI that Jose had implemented…but in the meantime, check them out!

This work is licensed under a Creative Commons Attribution By license.

| Comments

Taking another cue from some great stuff Joel is doing, I liked his implementation of the ‘Leopard Screen Saver’ but wanted to make it more ‘real’ for me.  So I wired it up to my Flickr account.  Result here (using Silverlight Streaming):

I only had to change a few things.

First, in the Page_Loaded event, I removed the timer start function.  This was because with interacting with Flickr it was going to be async.  I didn’t want the timer to start until I knew the image collection was built.

My BuildCollection function now looks like this:

private void BuildCollection()
    // get Flickr NSID
    WebClient fu = new WebClient();
    fu.DownloadStringCompleted += new DownloadStringCompletedEventHandler(fu_DownloadStringCompleted);
    fu.DownloadStringAsync(new Uri(string.Format(FLICKR_USER_SEARCH, App.FlickrUser)));

This is a first call to get the NSID (internal Flickr user_id parameter) based on an initParam the user sends in.  The FLICKR_USER_SEARCH is just a const string parameter to the Flickr API rest call (with my API key in it) which looks like this:

const string FLICKR_USER_SEARCH = "http://api.flickr.com/services/rest/?method=flickr.urls.lookupuser

I also use a FLICKR_USER_PHOTOS const which is like this:

const string FLICKR_USER_PHOTOS = "http://api.flickr.com/services/rest/?method=flickr.photos.search

The completed event handler for the user search call looks like:

void fu_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
    XDocument resp = XDocument.Parse(e.Result);

    string nsid = resp.Element("rsp").Element("user").Attribute("id").Value;

    WebClient p = new WebClient();
    p.DownloadStringCompleted += new DownloadStringCompletedEventHandler(p_DownloadStringCompleted);
    p.DownloadStringAsync(new Uri(string.Format(FLICKR_USER_PHOTOS, nsid)));

to retrieve the NSID.  With that I then start the search photos call to retrieve 42 photos.  The sample is a little hard-coded with count values, but this is just a quick change to see if it would work.  When the async operation to search the photos returns, I use some LINQ to mash them into FlickrImage object types using a custom class I put in my Silverlight application.

public class FlickrImage
    public string id { get; set; }
    public string farm { get; set; }
    public string server { get; set; }
    public string secret { get; set; }
    public string title { get; set; }
    public int tagid { get; set; }
    public string url
            return string.Format("http://farm{0}.static.flickr.com/{1}/{2}_{3}_m.jpg",
               farm, server, id, secret);

and then the LINQ query:

XDocument xml = XDocument.Parse(e.Result);

var photos = from results in xml.Descendants("photo")
             select new FlickrImage
                 id = results.Attribute("id").Value.ToString(),
                 farm = results.Attribute("farm").Value.ToString(),
                 server = results.Attribute("server").Value.ToString(),
                 secret = results.Attribute("secret").Value.ToString(),
                 title = results.Attribute("title").Value.ToString()

Once I have these, I essentially moved the iteration code Joel had into a foreach loop for my images and then started the timer.

foreach (FlickrImage photo in photos)
    Uri imageUri = new Uri(photo.url, UriKind.Absolute);

    if (i <= 16)
        Tile tile = new Tile();
        Media media = new Media(imageUri, true);
        tile.Media = media;

        if (col % 4 == 0)
            col = 0;
        tile.SetValue(Grid.ColumnProperty, col.ToString());
        tile.SetValue(Grid.RowProperty, row.ToString());


        _images.Add(new Media(imageUri, false));



The result is the same visual sample Joel had, but using my live Flickr photos from my gallery.  This is made possible because Flickr has a) a REST api and b) a valid cross-domain policy file.  Both of these enable Silverlight to be a great client for consuming this data.  The visualization could be enhanced to provide mouse-over effects to zoom the picture I suppose, but I’ll get to that later.  Pretty fun that just a few changes (and none to XAML) enabled me to make this real for me.

The code for my changes is here but note you must have your own Flickr API key from their site.  I also implemented supporting an initParams value so you can pass in the Flickr user name dynamically. 

UPDATE: To use the initParams capability and display a badge for your Flickr account, you can use an <iframe> tag and point to http://silverlight.services.live.com/invoke/217/FlickrBadge/iframe.html?u=[yourflickrname] where the [yourflickrname] is the last part of your Flickr photos url.  For example if your account is at http://flickr.com/photos/uhoh_over than you would use http://silverlight.services.live.com/invoke/217/FlickrBadge/iframe.html?u=uhoh_over.


| Comments

In a previous post, I wrote about some samples of calling various types of services from Silverlight 2.  In the code, I was using constructors in my ASMX and WCF services with specifying a binding type and endpoint address.

It was called out to me that in other demonstrations, people did not use this construct.  While the method I demonstrated works (explicitly specifying the binding and endpoint), in some cases it may not be necessary.  One such case would be if you only have one endpoint and it is basicHttpBinding.

The error in my code/instructions was about changing the binding information in web.config.  The information is correct, however I wasn't clear on when/what you needed to do.  For example, the default information in web.config for the Silverlight project created for you uses wsHttpBinding.  If you add a service reference in your Silverlight project PRIOR to changing that binding information, your generated proxy will require you to specify a binding and endpoint as Silverlight doesn't support wsHttpBinding and it would be trying to use that as a default method.

So the appropriate way is to change the binding type in your web.config FIRST.  Then generate the service reference in your Silverlight application and your proxy code generated will then allow you to new up the service using:

WcfServiceClient wcf = new WcfServiceClient();

for both WCF and ASMX services...which is probably more familiar to most web developers implementing services in their applications.

Again, EITHER way is fine.  Providing no information in the constructor will use the default binding/endpoint information for that service, and if it isn't supported, you'll get a nasty exception.  Whether or not it is best practice to always explicitly call it out in your code is up to you.  I'd argue it is.  In looking at the code above do you know what binding/endpoint is being used at the time of the service call?  No.  You could make some reasonable assumptions (hey, I'm in Silverlight and I know I must use basicHttpBinding), but for maintainability, maybe someone else coming to the code doesn't have the same understanding.

To each his own.  Either way, I hope this clarifies and I've updated my post with the note about this as well.