Feeds:
Posts
Comments

Google Web Toolkit 2.0 brings web apps one step closer to… Silverlight

December 10, 2009 by Tim Greenfield

What is GWT?

In case you haven’t had a chance to explore, Google Web Toolkit (GWT) is a great new tool for building web applications. At its core, GWT allows developers to code in Java and essentially “compile” to Javascript. But it offers much more: GWT also provides a set of common controls (or widgets) to build UIs and even provides a plugin for Eclipse that allows developers to debug both client and server-side code in the same environment that they write their code. Cross browser compatibility is taken care of for you and if you stay within the confines of GWT, for all practical purposes you’ll think you were building a native Java client/server application.

What’s new in GWT 2.0?

Yesterday Google released Google Web Toolkit 2.0. GWT 2.0 provides a number of improvements but the most important one is the ability to define your UI using markup instead of code. You could always create good old fashion html with GWT, but if you wanted to use the native UI widgets, you’d have to do all the creational work in code. With 2.0 you are now able to use a feature called uiBinder to build your own native GWT widgets (the equivalent of UserControls) all in markup. The cool part is, you can mix html with your GWT markup if you want to.

The Good:

GWT helps developers build complex client/server applications with first class tools in a first class language and target any browser without the need for a plugin. The developer doesn’t have to know anything about Javascript, Html, or cross browser quirks and can use accepted design patterns for building complex web applications.

The Bad:

Before my time, assembly programmers must have argued with C programmers that they could never write code in C that would be as efficient as assembly. They must have argued that there would be certain advanced tasks that couldn’t be done easily in C, and that the compiled C would be bloated by comparison and nearly impossible to read if something went wrong and you needed to inspect your code. This is the same argument GWT faces today from the Javascript camp. Ultimately, a javascript app is still being created under the hood and because of it, GWT developers will never have the same level of control and flexibility as if it had built in Javascript from the beginning. All choices have tradeoffs and this is one of GWT’s.

The Ugly:

The product that GWT allows a developer to create will always only be as good as the browser running it and will be held back by the older browsers that it needs to support. In the near term, in order for the GWT feature set to progress, 2 things have to happen: 1) browsers have to natively start supporting new features (can anyone say HTML5?), and 2) certain features in your GWT app won’t support older browsers. While this is a reasonable way to compete with ASP.NET Webforms, jQuery, and Ruby on Rails, this is not a sustainable path to compete with Flash, Silverlight, or Java FX. Hence…

My opinion on GWT’s long term strategy:

Either GWT will ultimately be positioned as a technology suited for catering to lowest common denominator scenarios or…

Google will have to adopt something similar to the plugin approach. GWT developers will still build their app using GWT the way they do today but if they want access to all those extra goodies that Flash, Silverlight and Java FX have (the ones that are not supported in the current version of HTML or Javascript), GWT will need to build those features into Chrome and allow developers to build apps that require some variation of Chrome (Chrome browser, the Chrome OS, or the Chrome Frame plugin). Google may try to bake these feautres into whatever the next version of HTML is at the time but my guess is that they won’t always be willing to wait around for W3C to agree and will start adding them to Chrome as they need them. In the end, GWT apps that need the latest features will essentially be native Chrome apps built on (for all practical purposes) a Java powered plugin framework.

Personally, I say unless you need a plugin independent app, why wait? Silverlight, Flash, and Java FX give you today everything that GWT will provide tomorrow.

Posted in Commentary | Tagged , , , , , | 2 Comments »

PuzzleTouch wins the ComponentArt Silverlight Coding Contest

November 4, 2009 by Tim Greenfield

UPDATE: The results are in and PuzzleTouch won the grand prize! I had some tough competition so I am extra excited to have won.

The ComponentArt Silverlight Coding Contest results are in for the five finalists and I am super excited to annouce that my creation: PuzzleTouch Online Jigsaw Puzzles made the cut! Thanks to all who voted for me!

If you haven’t see PuzzleTouch yet, check it out. It’s as fun to play as it was to write and is a great testament to what Silverlight is capable of producing.

PuzzleTouch Free Online Jigsaw Puzzles

It’s the only online jigsaw puzzle on the web that supports 360 degree rotation, 100% mathamatically unique shapes, unlimited levels of difficulty, full multi-touch support (my favorite for those that have the hardware!), out of browser mode, the ability to save games, and the ability to run offline (great for planes, trains, and autos).

Posted in Silverlight tips and tricks | Tagged , , | 4 Comments »

Host your Silverlight apps on Amazon S3

November 1, 2009 by Tim Greenfield

Silverlight apps are nothing more than big zip files and Amazon S3 is dirt cheap and hyper-scalable. Why would you ever host your Silverlight .xap files on your own server or ISP? … especially with Silverlight Streaming being dropped soon.

Here’s a quick guide to putting your Silverlight apps on Amazon S3 and depending on your app, never worry about scalability or bandwidth costs again…

1) Create your Amazon S3 account.

2) Install S3 Organizer FireFox plugin (this is the equivelent of an FTP client for Amazon S3).

3) Run S3 Organizer, log into your account and create your bucket.

Create a bucket in S3 Organizer via the toolbar

4) Upload your xap file to your bucket. BUT… you must add custom headers unless you are also going to host your .html file there too. Silverlight xaps need a MIME type specified when they are loaded from another domain. The good news is, this is easy with S3 as long as you do it at the time that you upload the file. There is probably a way to set it after the fact but not with S3 Organizer.

Upload your .xap file to Amazon S3 but don't forget to add custom headers

Set the content type for your xap file

Simply set the content type to ‘application/x-silverlight-app’ and send up your xap. Don’t forget to do this EVERY time you upload an update.

5) After uploading your .xap file, set permissions so everyone can read your xap file. Right click on your newly uploaded xap file and choose “Edit ACL…”. Then check Read access for Everyone and Authenticated Users. You do NOT need to do this every time as S3 remembers your ACL settings.

Edit ACL settings in S3 Organizer for your xap file

6) Add the enableHtmlAccess param to your object tag within your html file to enable access to the DOM bridge (assuming your Silverlight app needs access to the DOM bridge).

For example:

Set EnableHtmlAccess param in the object tag

7) Change your html page to load your xap file from S3 directly by setting the source param in your object tag.

For example:

Change the source of your xap file to load from S3

Note: ‘mybucket’ is the name of your bucket on S3.

8 ) Upload your html (or aspx) page to your web server. GoDaddy.com offers cheap hosting for only $5 per month.

That’s it! At this point, the only scalability concerns you should have are those of your web services (assuming you call web services from your Silverlight app).

And with S3, the costs depend on the usage — which will literally cost you just pennies per month until you have some descent traffic. Do the math and you’ll see that it would only cost 17 cents to have a  300K .xap get hit 3500 times. At that rate you’d pay ~$48 to have 1 million new users per month. (I say “new” users because unless you update your xap, users should be caching your xap file and won’t need to re-download it).

Happy cheap hosting and Silverlight coding!

Posted in Silverlight tips and tricks | Tagged , | 5 Comments »

Silverlight Presentation at EADNUG

October 22, 2009 by Tim Greenfield

Thanks to all who attended my presentation tonight at the Eugene .NET users group (EADNUG)! There were many great questions I had a fantastic time showing off all the cool things Silverlight can do.

Click here to get all the fun little projects covered (and a few we didn’t have time for).

See you again at the next meeting.

Posted in Silverlight tips and tricks | Tagged , | 3 Comments »

How HTML5 can compete with Silverlight and Flash

September 23, 2009 by Tim Greenfield

In case you haven’t heard, Google just debuted Google Chrome Frame; allowing developers to run the Google Chrome rendering engine inside IE as a plugin and thereby trumping IE.

Reading blogs like this one, I distinctly get the feeling that most of the tech journalists out there don’t understand what this is really all about. This is not about Google being annoyed with old versions of IE, it’s about HTML5 vs. Silverlight vs. Flash. Right now HTML5 has 3 big disadvantages over their plugin counterparts…

  1. Different browsers will implement HTML5 differently. Even if it is standards based. 
  2. Most browsers don’t support HTML5 and getting a user to switch browsers is a lot harder than getting them to install a plugin.
  3. Standards based innovation is slow. HTML5 in its entirety should be ready for browsers to implement in 2012; just in time to be as far behind Flash and Silverlight as HTML4 is today.

In the end, there are only 2 ways around all of these disadvantages:

  1. Either get everyone to use your browser or
  2. Run everything thru a plugin.

Google Chrome (the browser) and Google Chrome Frame together make it possible for developers to write and test code in an IE-less world, thereby getting more developers to care about Chrome, less to care about IE, and more to choose HTML5 as a framework to develop apps on.

Right now the plugin is an ActiveX plugin and therefore only works on IE, but give Google some time and I’m sure they’ll have a Netscape plugin too that will work in Safari and Firefox. It’s only a matter of time before you Google will be nearly in complete control over how HTML5 will be rendered (if the developer chooses so) and thereby won’t need to wait on a standards committe to approve further innovation to HTML.

Of course, the picture is even bigger than that… whoever owns the developers will own the dominant OS. In my opinion, this is all a tactic in the Android/Chrome OS vs. iApple vs. Windows war and the reason Google built Chrome in the first place.

Posted in HTML5, Silverlight tips and tricks | Tagged , , , , | Leave a Comment »

You say hello and I say goodbye (to Windows Azure)

July 19, 2009 by Tim Greenfield

This week Microsoft finally revealed its pricing structure for Windows Azure hosting services. Using Azure to host the simplest website in the world costs a minimum of $0.12 / hour. Work out the math: 0.12 * 24 * 30 = $86.40 / month.

While this might sound reasonable to a large organization with tons of traffic or anyone currently using Amazon EC2 or Rackspace’s Mosso, this is way out of reach for the majority of developers and organizations who are just trying to create a useful webservice or website that could scale in the off chance their idea took off or got mentioned by the press.

Based on this pricing it’s obvious that Microsoft is trying to compete with Amazon and targetting the same market. Nevertheless, I personally had high hopes that Microsoft was actually trying to compete with Google App Engine by offering the first and only affordable and scalable Windows hosting option… which raises the point: (in case anyone from Microsoft is listening) if Microsoft wants .NET to compete long-term as a server-side platform (which is essential for Windows to thrive as a server-side OS), someone is going to have to solve this problem soon or it will find itself playing catch-up.

I love Windows Azure and I believe it is a great, simple and affordable option for the big boys. But as Windows Azure leaves beta and the world says hello, I say goodbye before I have to start coughing up ~$100/mo for my personal websites. Back to shared hosting at GoDaddy ($4/mo for Windows + SQL).

Posted in Windows Azure | Tagged , , , | 3 Comments »

Cropping an image in Silverlight 3

July 12, 2009 by Tim Greenfield

Silverlight 3 introduces the WriteableBitmap class and with it, the ability to crop an image programmatically on the client!

All you need to do is create a new instance of the WritableBitmap class as your destination (supplying the dimensions in the constructor). Then create or acquire another instance of the WriteableBitmap class fully loaded with an image (among other ways, you can do this by creating a BitmapSource object from a stream via .SetSource and passing that BitmapSource instance into the constructor of a new WriteableBitmap)

Once you have your source and destination WriteableBitmap classes, just retrieve one pixel at a time from the source instance and set that pixel on a destination instance. The pixels are stored in a property on the object call Pixels which is a 1 dimensional array. Geting the index of a given pixel in an array is simple: index = x + y * width.

In my first pass, I just looped thru pixel by pixel. This was fast but not as fast as using Array.Copy (almost twice as fast)…

private static WriteableBitmap CropImage(WriteableBitmap Source, int XOffset, int YOffset, int Width, int Height)

{

    int SourceWidth = Source.PixelWidth;

    WriteableBitmap Result = new WriteableBitmap(Width, Height);

    for (int y = 0; y <= Height – 1; y++)

    {

        int SourceIndex = XOffset + (YOffset + y) * SourceWidth;

        int DestIndex = y * Width;

 

        Array.Copy(Source.Pixels, SourceIndex, Result.Pixels, DestIndex, Width);

    }

    return Result;

}

The result (a WriteableBitmap) can then simply be used as the source of an Image control to display your cropped image.

Note: WriteableBitmap.PixelWidth is expensive. Be sure to call it only once if possible.

Possible Improvement: Had the source width and destination width been the same I could have done it in a single call to Array.Copy and presumably made it even faster.

It’s high time that web developers are able to do complicated tasks on the client and not forced to use the server just because the client-side platform doesn’t support it. We’re still not all the way there yet but Silverlight gets us a lot closer than anything before it.

Posted in Silverlight tips and tricks | Tagged , , , , | 5 Comments »

According to my stats: Silverlight install base over 50%

July 8, 2009 by Tim Greenfield

How many people have Silverlight installed? According to Rich Internet Application Statistics, Silverlight is installed on 30.27% of the machines out there. However, I’ve been tracking stats on my own site: MyPadlock.com (a free password manager for Windows) and have seen a much different number. Here are my results from the previous month:

SLStats

Find out more about tracking Silverlight usage over Google Analytics.

Caveats: There are a number of differences that could account for why I’m seeing a larger percentage than the Rich Internet Application Site. First of all, I doubt I have the same volume of traffic being tracked. However, I do have a fairly healthy volume, most of my visitors are not repeat, and the numbers have shown relative consistency from month to month, so think what you like, but I’m going to rule this out as a relevant factor.

Also note that my site does not use Silverlight in anyway nor does it receive any real traffic from a source that uses Silverlight. Oh, and my own visits are not counted either.

Most likely, the difference is due to differences in audiences. Certainly, a password manager is the kind of software that power users would use for more than novice users. Also, power users are probably more apt to explore new corners of the web are therefore more likely to have encountered Silverlight at some point. And lastly, my site gives away a Windows only app and perhaps Windows users are more likely to have Silverlight installed (might be a reach but worth speculating).

Nevertheless, whatever the reason is, I still belive the statistic is valuable and at the very least, tells me what to loosely expect for anyone thinking of porting a Windows app to Silverlight.

What kind of numbers are you seeing? I’d love to hear from anyone with access to similar stats for their own site(s).

Posted in Silverlight tips and tricks | Tagged , , , | 3 Comments »

Look what Silverlight can do

June 22, 2009 by Tim Greenfield

I just finished one of the coolest and most exciting apps I’ve ever written and the client-side was done in 100% native Silverlight 2. Fortunately, I was able to get it done just in time to debut for the NewCloudApp Windows Azure contest.

It’s an online jigsaw puzzle and it was as fun to write as it is to play. You can choose from over a hundred images or use your own photo, select practically any number of pieces (I recommend 12 to start), and even send puzzles to your friends.

Click the link below to check it out and tell your friends if you like it!

PuzzleTouch Online Jigsaw Puzzles

I can’t wait to write more about why I chose Silverlight for this project (really, why Silverlight was the only platform up for the job) and all the new things I learned along the way. But for now, go forth and play puzzles.

Posted in Silverlight tips and tricks, Windows Azure | Tagged , , , , , | 4 Comments »

Optimizing sending xml to a service

April 25, 2009 by Tim Greenfield

Here’s a tip to get the better performance when sending xml to a WCF web service from Silverlight or WPF…

Never send or return xml as a string. Anytime you pass around a string data type as a parameter to your service or send back a string return value, the string will be XML encoded. Imagine, the following string:

<hello/> (8 bytes)

this is really sent around as:

&lt;hello/&gt; (14 bytes)

Something that should have taken only 8 bytes of your bandwidth, took almost double that. Now an extra 6 bytes isn’t bad, but you can see how it wouldn’t take long for your xml to quickly inflate the overall size of the request or response and at some point even have a noticable delay for the usability of your app.

Fortunately, the solution is simple! Use an System.Linq.Xml.XElement object instead. By doing so, WCF is smart enough to encode your xml right in the message envelope as pure xml. Furthermore, if you need to work with that xml on the receiving end, it’s already in an object type more suitable for most purposes than a String.

To demonstrate and prove what is happening, I wrote a test app that sent a test parameter to a service as a String, XElement and byte array. The test data being sent in all three cases was the xml: <test/>. Then I used fiddler2 web debugging proxy to see what was actually sent to the server. Check out below what I saw:

Sending a String:

<s:Body><DoWorkString><param1>&lt;test/&gt;</param1></DoWorkString></s:Body>

Sending a byte array:

<s:Body><DoWorkByteArray><param1>PHRlc3QvPg==</param1></DoWorkByteArray></s:Body>

Sending an XElement:

<s:Body><DoWorkXElement><param1><test /></param1></DoWorkXElement></s:Body>

XElement wins! :) And just to be sure, I also confirmed that responses for the three data types produced identical results.

 

A note about compression

Compression does not completely remove the benefit of sending as XElement. Besides the fact that server compression only works on responses, it doesn’t eliminate the benefit from sending xml without encoding. This was surprising to me. I thought that compressing my responses on the server would find common xml encoding phrases like “&lt;” and “&gt;” and find a way to turn them into single bytes using a mapping technique and make an xml encoded and non-xml encoded response virtually identical in size when compressed. To test my assumption, I ran a test where I took a big xml file, and added it and an encoded version of it in a zip file. Here was my result:

encoded and decoded compression results

Acording Although encoded xml can be compressed at a slightly higher compression ratio, it was not as dramatic as I thought and suggests and the final compressed sizes show that although compression on the server helps reduce the size of your response a great deal, xml encoded strings will still be larger than necessary. Check out my previous blog post to find out more about opimizing responses by turning on server compression.

Posted in Silverlight tips and tricks | Tagged , , , , , | Leave a Comment »

Older Posts »