Windows Phone 7 SDK First Impressions

by Jon Davis 25. April 2010 13:20

A couple co-workers and I had a couple days’ opportunity at my day job to tinker with creating a Windows Phone 7 app as a proof of concept. We successfully created an app that lets you find and purchase a company product (complete with checkout, although the checkout part was web-based), access account information via a web interface, and contact customer support via either an e-mail form or a “Call Us” button that, yes, would dial customer support via the Phone function of the device. (Strangely, the Phone part was the only part that did not work nor give any “Not implemented” nor “Not supported” feedback.)

We accomplished all that in two days, plus some reading up on XAML knowledge (i.e. I’d spent the entire prior Saturday wading through the Petzold PDF that had been linked from the developer web site .. where is that Petzold PDF link now?), plus some insider knowledge of existing APIs and some preexisting web interfaces used with other mobile devices. The only huge hold-up for us, as far as I was concerned, was the learning curve of the tool chain. I mean, it’s C# which I’m fluent in, but it’s also XAML which I’ve used but never mastered, and it’s brand-new Silverlight 4.0 (a binary-incompatible derivative thereof, I think). And I’m still pretty green to MVVM and still don’t understand a lot of the basics of MVVM such as how and when to use ICommand, etc. But we got a prototype built, with only two days to do it.

That said and done, however, I walked away from that little mini-project with a few opinions. A couple years ago I tinkered with iPhone development with the Xcode / Obj-C / Interface Builder tool chain, so I have the two phone SDK experiences to compare.

One theme – “minimalistic” – to rule them all?

My immediate observation is that the UI aesthetic guidance in the Apple toolchain is nowhere to be seen in Microsoft’s toolchain, and I expect this will hurt Microsoft. Sure, Microsoft pre-packages a couple white-on-black templates as an aesthetic suggestion to get you started with a basic theme. But that’s where guidance ends. You’re given a few XAML controls to get you started, and everything starts at a bland white-on-black. A button, for example, it’s just a white rectangle, no gradient, no border bezel, same story as the white-square-on-a-white-line slider control, all to reinforce the idea that white-on-black is good because OLED displays consume 50% as much energy this way versus 3x more energy if everything displays in full color.

image 
Wow, Microsoft, you outdid yourselves here, that is a
beautiful slider handle! (Not.)

And on that latter note, why didn’t Microsoft innovate here, such as this: as soon as the user interacts with the device, for a full 15-30 seconds everything’s in rich, full color, then after 30 seconds of inactivity the view goes into “interactive screen saver” mode whereby the colors fade to inverse and you see the color scheme that’s on the device color scheme now? Toggle this behavior for your app or navigation “page” in the SDK with a boolean switch and a timespan setting. Just a thought.

Whereas, with Apple, in Interface Builder (Apple’s GUI designer) you’re given a nice big library of richly colored controls and widgets including a nice tab control on the bottom, a header control on top where you can have your richly labeled back and forward buttons, and a number of nice interactive controls such as a “checkbox” that actually renders as a beautifully detailed ON/OFF slider, complete with simulated physics and even a drop shadow on the moving slider.

It’s not the absence of aesthetic tooling that bothers me here. Actually, Microsoft opened the door wide open to aesthetic freedom, as XAML richly supports deliciously detailed interactive graphics with Expression Blend and the like. My issue is the fact that other than “minimalistic white-on-black” there is no guidance, which is an issue that plagued Windows Mobile 6 and previous Windows Mobile flavors. You will have some beautiful Windows Phone 7 apps like the Foursquare app, and then you will have some apps from people who learned Silverlight and go nuts with gradients and bright, flashy, ugly designs, or who simply ported their Silverlight apps straight over to the Windows Phone 7 SDK. Aesthetic inconsistency is going to be a nuisance. This happened in Apple’s developer community, too, but you’re almost required to do this with the Windows Phone 7 SDK because the prefab tooling in the Windows Phone 7 SDK is, at least so far, incomplete. Then again, this is still just a CTP (a beta), so we don’t know how much more complete the SDK will be on its release.

The SDK comes also with a “list application” template, which demonstrates how to have that pretty list that has the 3D rotating items when you tap on them or navigate around. That was really neat, but then I found myself scratching my head wondering how to make that behavior stick across the rest of the application? Can I declare this animation/storyboard definition once and reference it with a one-line behavioral reference of some kind across all of my “navigation pages”? If so, that was not demonstrated at all, and it looked like I’d have to copy and paste everything in the templated demonstration to each and every page I’d create. We ultimately just ignored the animation code, saddened that only the “root menu” showed this animation, because it’s really not worth it to copy/paste so much code (about 50 lines of XAML) everywhere, making a mess of the markup.

No HTML DOM interaction

My other complaint is with the Silverlight 4 web browser component. It is truly wonderful that Silverlight has an integrated web browser component, and I adore Microsoft for adding it especially for the Windows Phone 7 SDK, as it’s absolutely necessary to integrate the web browser with many Internet-enabled applications. That said, however, I found no easy way of interacting with the DOM from the Silverlight CLR. In Windows’ Internet Explorer, you had to make a separate COM reference to mshtml.dll before you could interact with the DOM. I used to do this heavily. Perhaps I’m spoiled. But not having access to the document interface and, as far as I can tell, only being able to navigate and toggle scripting support really worries me that my hands will be tied here. It was, after all, Microsoft who invented dynamic HTML with fully dynamic content back in Internet Explorer 4, when Microsoft’s innovation inspired me so much that I decided to go all-out into being a web developer. That was way over a decade ago. I still want that power; XAML doesn’t always cut it.

Silverlight (and XNA) awesomesauce in a bag

I didn’t have a chance to play with XNA on WP7 much yet, but just knowing that support for XNA is there is very exciting. XNA is a fantastic platform to build games on, as it is approachable even for a beginning developer. My only complaint about XNA is that there is no virtual keyboard support. I did verify by fiddling with it that the physical keyboard seems to be exposed in the XNA API, though.

Despite my complaints about the WP7 SDK, WP7 is going to be a game changer, and a huge hit for the developer community, I’m sure of it, simply because it allows you to leverage your existing C# or VB.NET skills and prototype functional software on the device with beauty and finesse. Heck, you can even leverage Ruby skills for it. For some unknown reason, IronPython won’t run on it yet; I’m sure support for that will come before RTM, particularly given the volume of feedback for it.

But you could already?

Actually, C# developers have been able to write Windows Mobile software quickly and easily for years, albeit not with Silverlight nor with XNA. Windows Mobile has lost the market share, consumer sales is now akin to Linux’s market share on the desktop—about 2%. Microsoft is going to have to work hard—harder than they have worked so far, from what I can see—at winning over people to the Windows Phone 7 away from the iPhone, which now takes up a huge chunk of the mobile market share. They have to compete as well with the Android which already sought to compete with the iPhone, Blackberry, and Windows Mobile, and is doing one incredibly good job at doing so.

Frankly, looking at the iPhone 3GS vs. Nexus One (Google Phone) demos, I can’t help but look at the Windows Phone 7 and laugh at it. Windows Mobile 6 may have had the awful Start menu, the most ridiculous interface ever to have been put onto a mobile device, but with that stupid Start menu the platform also retained the “many apps and their icons” notion of an application playground which is strong in the iPhone and Android as well but not so easy to find in WP7. I have difficulty seeing how a marketplace would even work for WP7—will installed apps be categorized and the user would find their installed apps by category? Surely WP7 will not just throw all apps into one giant vertical list, oh good grief, please tell me no!!

Microsoft has also been alienating people who identify things based on icons rather than text. The Live applications team have demonstrated this, for example, by dropping icons completely. In so doing, Microsoft is also alienating the international communities. Sure, text can be translated, but it doesn’t make a particularly great sell when the first impressions of an interface are of gobs and gobs of Engrish text and you don’t speak Engrish. Meanwhile, many of us who do speak English still prefer attractive icons over avant-garde lower-case text headings. When you have five or so menu items in 72 point font size, it’s fine, but when you’re trying to find something among 200 others, nothing beats the simple icon. Throwing away the simple icon on a grid won’t make this reality go away; this is not like a floppy drive, it is actually essential.

WP7’s minimalistic interface could actually end up being its downfall. They’re taking a huge chance and risk. I’m hopeful, but sadly slightly doubtful, that it will be enough to throw Microsoft back into the playing field.

Starting over

Maybe I’m just not getting it. Actually, Microsoft’s new direction has had me scratching my head so much that I’m convinced that I’m still struggling to get it, and that actually all of my concerns are quite intentional for Microsoft’s part.

This video demonstrates this quite well. Microsoft wants to “start over” not just with their SDK but with deemphasizing standalone installed apps and reinforcing the notion of a phone whereby the many apps are not just active but are integrated with each other.

The only problem is, I don’t see such cross-app integration demonstrated in the SDK, at least not up front, not yet. Also, why should I as a developer be excited about this new direction if the apps—my development efforts, and yours—are deemphasized in favor of prefab packaging?

Stoked and confused

Overall, I’m both stoked and confused. This is an exciting time to delve into this new technology from Microsoft. Microsoft really needs to fill in some holes, though, and these holes are less technological than they are design.  Their design and marketplace support strategies seem very vague.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

C# | Windows Phone | Silverlight

Silverlight 3: 3D support has buggy occlusion?

by Jon Davis 10. July 2009 14:07

I just downloaded Silverlight 3 and Blend 3. First thing I did was try out one of the samples. I grabbed the Zune 3D sample, then ran F5 to run it. I was able to spin the Zune model by dragging the mouse from the base of the model. But then I immediately noticed that it doesn't look right. The arrows and artwork that are on the sides of the model do not get properly occluded while the whole thing is spun. The artwork occludes too soon, and the arrows don't occlude at all.

Could be a bug in the sample. But could be a glitch in Silverlight itself. I wonder?

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

Silverlight

Mix09: Silverlight 3 Bitmap API and Bitmap Caching

by Jon Davis 19. March 2009 20:38

At MIX 08 (yes 2008) one of the sessions I watched on video discussed game development on Silverlight 2, and I after watching it I was scared of ever creating anything with Silverlight of that sort, because of a serious limitation. These people making this game were unable to create bitmap sprites. Tiling, animations and the like had to be created with vector brushes and storyboards. What an awful joke! I swore off Silverlight for tinkering with games until Microsoft would expose a bitmap API that would facilitate bitmap editing, bitmap-to-canvas, as well as canvas-elements-to-bitmap.

I’ve mentioned my concerns in this blog before, even again recently.

It looks like Silverlight 3 is going to deliver. It will be barebones—the bitmap API is strictly pixel-level bitmap tweaking (no inherent System.Drawing equivalence or PNG import/export). But it’s SOMETHING, and something is better than nothing. Microsoft threw us a bone. Meanwhile, the bitmap caching is described as such: “Silverlight 3 dramatically improves the rendering performance of applications by allowing users to cache vector content, text and controls into bitmaps. This feature is useful for background content and for content which needs to scale without making changes to its internal appearance.” This sounds a lot like a solution to the original problem I (and apparently they) observed. I don’t know, however, how carefully that text was written. Can we really export canvas objects, such as the canvas itself, to a bitmap? If so, theoretically one could easily use this create screenshots of Silverlight, or even video recordings of Silverlight usage. This could also be a printer solution, assuming you can also export a higher DPI than screen default.

It’s all way cool, regardless.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Silverlight

MIX09: Silverlight 3 Supports Offline Desktop Apps? Cool! .. Er .. Meh.

by Jon Davis 19. March 2009 20:21

Silverlight 3 will support being deployed offline as desktop apps. That’s cool. It’s official, now, Microsoft has an answer to Adobe AIR. Really cool, actually.

Then again, Silverlight doesn’t do windowing. You’re stuck in a single window. Meh. Silverlight doesn’t do rich menuing (outside of the window canvas, except for right-click context menus). Meh. Silverlight apps deployed to the desktop aren’t actually installed (no true “Application” treatment), just a shortcut on the desktop—a feature (called “simplicity”) as much as a loss. No HTML / Javascript support! Meh!

I’d be no less interested than before of the idea of taking Webkit and building a third party AIR-like solution for Silverlight today even after the Silverlight 3 announcement, if it wasn’t for the annoying fact that even if such a thing was made, people wouldn’t use it, because they’d settle for the half-baked solution from Microsoft.

Do my gladness and disappointment cancel each other out? Hm. Not really. I’m disappointed by the details (or lack thereof), but at the end of it all, if I forget about Adobe AIR for a moment, .. dude! I can deploy simple, User Experience enhanced .NET apps on Windows or Mac with no trouble at all!

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Silverlight

Silverlight’s AIR Equivalent Has Been Here All Along.. At Least In Windows

by Jon Davis 5. March 2009 04:02

I think I know one more reason why Microsoft hasn’t pushed an AIR equivalent for Silverlight. It’s because it already exists in lightweight form, bundled with Internet Explorer, called HTAs, or HTML Applications.

http://www.microsoft.com/technet/scriptcenter/hubs/htas.mspx

HTAs are basically HTML files, renamed to .hta. Double-clicking an HTML file renamed to .hta opens it up in a form of Internet Explorer that has no status bar, no menu, no toolbar, just the content, and it runs in a desktop-accessible security context. You can even go chromeless (no border and no titlebar on the browser window) by setting the caption setting to false in the HTA header tag.

Of course, HTA is only usable on Windows, which, to many people, makes the comparison of HTAs to Adobe AIR fairly moot. I dunno, though, I’m not entirely inclined to agree. I just like the idea of producing Windows-installable RIAs in a portable codebase of my preferred architecture. On the other hand, cross-platform deployment of rich apps is the biggest selling point for AIR.

Technically, HTA is similar to Mozilla’s Prism (formerly “Webrunner”) in the Windows environment in that it is a way of accessing web content from a desktop icon without the bulk of the browser application. However, HTA is more like AIR in that it breaks out of the Internet Explorer security sandbox (sort of) and allows you to access the desktop environment from script.

Note: The reason why I added a “(sort of)” when saying HTA breaks out of the IE security sandbox above is because it seems there is a mis-trust that goes on when accessing some web content. I tried creating an HTA that redirected (window.location.href=) to a web page that had Silverlight content. It unexpectedly popped up a new window and then the Silverlight app failed to load due to “missing files”. I then tried referencing the web page in an IFRAME, and that worked without any problems. This was strange to me. These things said, I *am* using Windows 7 / IE 8, so it might’ve been a beta quirk. Dunno, really.

HTAs aren’t “marketed” as being very sexy. I don’t know why Microsoft stopped touting HTA as something interesting as of 2005; indeed, the Scripting Center makes HTAs seem somewhat geekish. And I never hear of HTA being compared with Adobe AIR, but I suspect that’s because AIR is presented in a sexy way and HTA is not.

There are some rough corners in HTA technology to make it awkward in its competition with Adobe AIR, here’s a quick list:

  • No app installer. You have to roll your own. HTAs are easy to produce, just take an .html file and rename it to .hta (and optionally add HTA tags to the file, etc.). The problem is that, as easy as that is, it’s not feasible for an end user, who typically won’t even be able to change the file extension (it’s hidden by default).

    Microsoft’s equivalent to AIR’s easy app installation process is ClickOnce Deployment, but once you’re using ClickOnce you’re not using HTAs, you’re using full-blown Windows binaries. Microsoft needs to produce a ClickOnce Lite that allows you to install HTAs and dependency files in something like a .docx, .xap, or .baml file (like, but not equal to, and certainly not being), maybe a new .htax file extension, being a ZIP file with all the CSS, scripts, .xaps, and other dependencies that a standalone rich HTA would need.
     
  • No app uninstaller, either. No app installer means it won’t get added to Add/Remove Programs, so if you rename an .html file to .hta and manually add it to your Start menu, well, good for you. But there is no realistic end user option for you.

    I think it’s time someone created a CodePlex solution for an HTA app installer/uninstaller if one hasn’t been started already. I’d be tempted to jump in myself if HTAs were cross-platform, but oh if I only had more free time ...
      
  • Not likely much in the way of special integration with Silverlight or other runtimes. It’s IE, so it all “just works”, just like with a normal web site. I haven’t really tinkered much with AIR so I don’t know but I’d be surprised if AIR didn’t have some special integration between Flash/ActionScript and the Webkit browser host runtime, such as alternative windowing or menuing APIs not normally available in a browser.
     
  • AFAIK, no transparency. I mentioned earlier that if you turn off the caption option in the HTA header tag, you end up with a chromeless window. (I’m not sure how you can drag windows around the desktop or resize without horribly painful hacks that work around security constraints that, frankly, suck.) But even if you drop the outer border, as far as I know, you can’t have transparency. Hence, no rounded corners. I could be wrong about that.
     
  • Not many tools out there for producing HTA apps. Adobe AIR comes with a full-blown SDK. There’s also Aptana Studio which provides an IDE for creating Adobe AIR applications. HTA, however, doesn’t really provide anything outside of MSDN documentation and “good luck”.
     
    This wouldn’t much matter since HTA truly builds on web technology (like AIR). The problem is that it’s more. The HTA SDK is the Windows Script (WScript.exe) COM server, exposing desktop objects like the file system to script, and Internet Explorer itself, which offers up extra rendering and transition filters and a script runtime that supports COM objects, alternate language support (VBScript), etc.

    So what HTA needs in order to compete in the area of tools support are
    • That HTA app installer I keep whining about for not currently existing.
    • A rich Javascript API that exposes common windowing and menuing programming options in an elegant manner, and that acts as an abstraction to WScript and other common Windows ActiveX controls that are accessible to HTAs and would be used in typical HTAs.
    • A fresh XHTML markup model, none of this all-caps HTML sample code. (And please, no more VBScript samples or ‘-o-matics’ unless side-by-side with JScript.)
    • First class support for HTA application development within Visual Studio, including:
      • Window (HTML) designer with all the HTA bells and whistles bundled into the editor and properties window (if it’s not already there??)
      • Debugger (already there, fortunately)
      • HTA installer package creation projects
    • A Silverlight and/or WPF/BAML integration API so that Silverlight / BAML code (C#/VB.NET/DLR) can “speak to” the HTA environment for such things as menus, windowing, etc. to the same extent as the “rich Javascript API” I mentioned above, and then some.
    • An icon exporter/integrator. (HTAs already support desktop icons.) 
    • Rolled into the Expression suite (export a Silverlight app from Blend to a desktop app, which can be edited further with Expression Web).
    • Some look-and-feel love on the above-mentioned, currently non-existent installer.

A fella can dream, can’t he?

Now for the money question. What would be the incentive for Microsoft to produce an AIR equivalent for Silverlight? I was always tempted to believe that there was a conflict of interest in the fact that introducing Silverlight in AIR-like form on non-Windows desktops like Mac or Linux introduced a competition problem with the primary competitive advantages of WPF, which is the XAML-based GUI environment for windowed apps, and which requires Windows. One might argue that giving Silverlight a windowing platform on the Mac or on Linux makes WPF, and thus Windows, less interesting. I used to claim this, now I’m not convinced, because I’ve seen how painfully limited Silverlight is compared to WPF. WPF has the whole of .NET available at its fingertips, as well as extra features like 3D.

That said, though, if Microsoft made HTAs a competitive AIR-like product that gave Silverlight apps a windowing and install-based platform, even if it would be exclusive to Windows, the sole argument I can think of that makes an AIR equivalent for Silverlight a competitive conflict of interest for Microsoft suddenly goes away. Now Silverlight becomes a Windows-favoring technology again, something Microsoft can use to its advantage.

And yes, I’m playing devil’s advocate with that previous paragraph. Meanwhile, you still have AIR and Prism, although, no, you can’t run Silverlight on AIR (apparently there’s some kind of security lock-down on plug-ins, although one wonders how hackable this is) and I don’t think you can access desktop objects such as COM objects from within Prism or AIR, although I believe Prism claims to have scriptable access to desktop files.

Looking at the simplicity of AIR—really, there are only a few key files, notably “Adobe AIR.dll” and “webkit.dll”—it surely can’t be hard to create a new AIR for Silverlight. The more I reconsider, the more I am back in my original agreement that AIR is all about being cross-platform, and that Silverlight needs something more. And certainly, Prism is looking more and more interesting as well.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Silverlight | Software Development

Silverlight 3: 3D Support, But Is This True 3D?

by Jon Davis 6. December 2008 13:49

Just a couple days after my repeat whine about Silverlight not having a rasterization API and 3D support I saw that Scott Guthrie announced that Silverlight 3 will offer "3D support and GPU hardware acceleration". I nearly crapped my pants when I read that. :)

What's not clear is whether 3D support will come via GPU hardware acceleration. I'm of the firm mindset that true 3D is OpenGL or Direct3D; anything else is fake. So if GPU hardware accleration is fully applied to the 3D support, it may be using OpenGL / D3D under the covers.

Otherwise, I'm just going to assume that the so-called GPU acceleration is intended to assist in video playback and vector graphics. And I only base that assumption on the fact that Adobe Flash "supports 3D" (has an API) but its hardware acceleration is limited to video playback and vector graphics. And I'm honestly not familiar with graphics acceleration on vector graphics, how that works, but given that they claim it, I believe it's feasible.

To be honest, I think it would be just about as bad if GPU acceleration was applied to 3D support but not to vector graphics.

Now on "rasterization", I over-use the word really, but all I wish for is two things: a mutable bitmap buffer, where we can plot pixels, and the ability to take "snapshots" of the vector brushes being displayed (i.e. myEllipsis.ToBitmap()) and export them to the same bitmap feature. This buffer should be reusable for textures on vector artwork as well as the coming 3D support. This is NOT an advanced component that would grow the framework, such a thing is EXTREMELY simple, particularly considering that Silverlight already supports images and manages bitmaps under the covers, it's just so heavily encapsulated that you're limited to URL maps and embedded files. I'm not asking for GDI+ functions! I just want to be able to retain a bitmap in memory and reuse it, and maybe be able to modify it by plotting pixels. There is no workaround for this; one could create his own bitmap class and write to a data stream but then Silverlight still can't use it (without persisting the data stream somewhere) because it's limited to URLs and embedded files!!

I'm starting to get a better picture of Microsoft in the Silverlight context lately. While I greatly respect Microsoft's tools and capacity to think brilliantly, as well as their enthusiast division(s) (XNA, Zune, Xbox, Games for Windows, etc), I think the fact that their enthuiasts division(s) are not very involved in the Silverlight product is seriously undermining the adoptability of Silverlight in competition with Flash. I acknowledge that there's not a lot of money to be made from it, but I at least consider it good marketing.

But on the enterprise business side, I truthfully cannot give Silverlight credit for meeting demand yet, despite the remarkable uses some have found of it (with some effort), because of the lack of high-level controls and APIs, although I fully respect and appreciate the fact that it is on track to meet demand. The new Controls Toolkit is great, but the controls as demonstrated in the samples, and the preexisting datagrid as demonstrated by normal use, all demonstrate that Silverlight has performance issues. Performance issues are of serious concern in business environments every bit as much as in enthusiast niches because it amounts to decreases in usability, which in turn amounts to turned off customers and ultimately lost profits. An example of this is the horrible scrolling performance issue, most seen in the datagrid, although I've come to realize that Silverlight's scrolling performance issues seem to have been improved somewhat since the last beta (when I stopped watching Silverlight because I was so turned off). Still, not improved enough. The Silverlight datagrid looks good until you touch it, and then makes your computer feel like something from the late 90s.

Actually, scrolling is only one example. It's user responsiveness on the whole; buttons have a similar problem. Actually, all the input objects have the problem. In general, while I don't question nor doubt Silverlight's capacity to look beautiful or to have very high FPS animations, etc., I think where it doesn't shine at all is in user input responsiveness. There are exceptions. Microsofts and Silverlight enthusiasts will always have some great demos lying around. But generally I've noticed a problem with user responsiveness, particularly when scrolling or dragging comes into play.

It's not a dealbreaker issue; not so bad that it's unusable. It's just bad enough to keep me from using Silverlight in everything I do. I prefer DHTML and its less-sexy appearance. Responsiveness is more important than appearance, and AJAX gets the job done in most cases. Silverlight meanwhile can fill in gaps where Javascript can't cut it, but then, so can Flash, and by the time you're already choosing to stick with HTML for the basics there's no compelling reason to use Silverlight except for the CLR and WMV support.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

C# | Silverlight


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  October 2014  >>
MoTuWeThFrSaSu
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar