This past weekend I had the wonderful opportunity to attend and speak at the Southwest Florida .NET Code Camp 2012 in sunny Naples, FL. It was a great event with over 80 attendees. I was there as both a speaker and a sponsor and I also brought my father and brother to the event. I’d like to thank John Dunagan again for putting on a fantastic event. I presented 3 sessions at the code camp and I wanted to take some time to provide some additional resources for those that attended the sessions.
HTML5 and jQuery Fundamentals
Originally, my boss Jason Beres was supposed to be attending this event but he needed to attend TechEd Australia instead. Since he was planning on presenting a session on HTML5 and jQuery I figured I would take that session slot and give it a try. I’m still learning HTML5 and jQuery so I’m certainly not an expert. However, I took Jason’s content and made some slides of my own and gave it a shot as a high-level overview. I thought the session went well and the attendees seemed engaged and appreciative. I promised I’d share my slides and Jason’s original material (including some content I didn’t get to talk about). Here are the links:
The material in this session hasn’t changed since previous events I’ve given the talk at. You can find more details on those here and here. However, one thing that is new is that I’m writing a book on the subject. Please pre-order Designing for Windows 8 today and you’ll get it when it’s done in December!
Designing for Windows 8
Create iOS apps using C# with Monotouch
I added this session for a bit of fun after I noticed that there weren’t any sessions at the code camp dealing with MonoTouch or Mono for Android. I think these are very important technologies and I didn’t want to let them go unrepresented. The session was at the end of the day so I kept it lighthearted with no slides and a few “Hello World”-style demos. I discussed the origins of MonoTouch and Xamarin and a little bit of the turmoil those have been through in the past. Thankfully, those things are in the past and we can safely use MonoTouch to build iOS apps without worrying about Apple interjection. I showed how to use MonoDevelop in tandem with Xcode to create a very basic application. I then showed how to build the same application using just Xcode with Objective-C.
I didn’t have slides for this session but I do have one follow-up piece of information from the session. I mentioned a service that allows you to run MonoTouch in the cloud in case you don’t feel like buying a Mac. That service is called MacInCloud and it might be a good option for you.
I had a great time at this event. I would highly recommend it to anyone next year. The location is fantastic, the facilities were very accommodating, and the people were very friendly. If you’re looking for an excuse to take a trip to Florida, this would be a good one.
While watching the live video from the Microsoft Office Preview event, me and my colleagues all had the same reaction (almost simultaneously in different locations) and we posted it to Twitter at roughly the same time:
“Formerly known as Metro style Applications”…did I hear that correctly?
Microsoft all made us scratch our heads because I think we’ve all gotten used to the term “Metro style apps”. Originally this term seemed awkward (especially the use of the work ‘style’ in it), but we all got used to it. We wrote posts about it. We gave presentations about it. The term maybe even grew on us a bit. So now Microsoft seems like they’re going to replace it with “Windows 8 Style Applications”? Immediate reaction from my colleague @brianlagunas:
I think we’ve had some time to digest this (pun intended) and maybe it’s time to revisit the term and whether or not Microsoft meant this as a replacement term because I have my doubts. Here’s my theory:
There is a lot of confusion in the software world regarding the Metro design language. For starters, when it is applied to an immersive, full-screen Windows 8 application that is launched from the Start screen, we have been calling that a “Metro style app”. But what do you call a desktop application running on Windows 8 that has been styled using the Metro design language in an attempt to fit in with the system even though it is running in the classic desktop? It is still technically “Metro style”. Is it possible that Microsoft was just referring to this scenario? That’s my theory at the moment but I’d really like some clarification from Microsoft on this soon. It’s hard to communicate these things to customers when there are competing terms floating around.
What are your thoughts? I’d really be interested in hearing them, so comment on this post or find me on Twitter @brentschooley.
I had the privilege of speaking at the Philly .NET Code Camp 2012.1 at Penn State Abington this past Saturday. My talk was titled Filling in the UX Gaps in Metro Style Apps, which should sound familiar since that was the title of my TechBASH presentation. However, I’ve modified the presentation quite a bit since then so the new title for it is Metro Design Fundamentals. The modifications I made were mostly related to beefing up the section on design inspirations and spending a bit more time talking about just how important design is to Metro style apps. Your app isn’t going to make it into the store without taking UX and design into account. This stuff’s important!
Thanks again to the folks at Philly .NET for allowing me to speak at this great event. I had a blast!
When I posted the “Better Grid Application” template for Metro style app development in XAML, I posted the wrong file. It was an older version of the template. Sorry about that. I have updated the file in the original post but here is the link again:
Fast forward to today: Microsoft announced the editions of Windows 8 that will be available upon release. Among these was a new name for what was previously referred to as Windows on ARM (WOA for short). The new name for WOA is Windows RT. Now, the observant amongst you probably immediately recognize the potential problem with this new name. For those that don’t, let’s review the concept of name collision.
Name collision is a programming concept that occurs when two variables are given the same name within areas of a program in which they would conflict (i.e. they are in the same scope). What is the result of name collision? Confusion. The compiler doesn’t know how to distinguish between the two variables and will complain. Thankfully, most compilers won’t even let you do this sort of thing. So, given that Microsoft has built a lot of software over the years, why have they made what seems to be a mistake directly akin to name collision? Amusingly enough, there was a post on the Building Windows 8 blog back in August entitled “Designing the Windows 8 file name collision experience”.
I’m not going to throw stones about whether or not “Windows RT” is a good name or the right name for the ARM version of Windows 8. What I do know is that it has the potential to cause some confusion in developer circles. There is a hashtag on Twitter #winrt. Can you immediately tell whether it’s referring to Windows Runtime or Windows RT? The longer version #windowsrt is a lot of characters for a system designed in such a way to limit the length of a post. Then there’s WinRT People, the site that collects posts from around the web about WinRT and related topics. Microsoft clearly established and communicated the “WinRT as Windows Runtime” naming scheme and now they’ve muddied the waters with this Windows RT naming decision. In a conversation with a Microsoft technology developer I’ll need to ask the question: “I’m sorry, were you referring to Windows Runtime or the ARM version of Windows?” Not sure I understand this decision at all.
Windows 8 Consumer Preview is finally here! I’ve already talked about my initial impressions of Windows 8, followed along with the BUILD keynotes day 1 and day 2 and provided developers with tips on how to get started with Windows 8 development. For all of this time since the BUILD conference, everyone has been able to try Windows 8 but it has mainly been aimed at developers looking to develop apps for the new platform. That all changes today with the release of the Consumer Preview. Now it’s everyone else’s chance to try it out. What’s up first? The installation! Continue reading →
It doesn’t seem like a great idea to go into a series of posts talking about Metro-style apps without briefly defining the core components that they are built on. The most fundamental piece of the puzzle for these apps is Windows Runtime, or WinRT for short. WinRT is probably best described as an unmanaged, native API that can be leveraged from many different languages via a mechanism called language projection. Read more to find out some more details about how WinRT works.
In the process of writing my first Windows 8 Metro style app using C# and XAML, I came across some limitations of the current WebView control’s implementation. The flow for the feature I was working on is fairly simple:
Content for a webpage is displayed in a WebView (using the WebView’s Source property).
User browses the page until they find something they want to save.
User clicks a save button and the app parses the information into a readable format for saving in the app’s storage.
This is a pretty straightforward concept and I thought the implementation would be just as intuitive. Judging by the similarity of the WebView control to the Silverlight WebBrowser control, I went about implementing this functionality as I would have for Silverlight. I set the WebView’s Source property to the initial Uri where I wanted the browsing to begin. I wired up a test button that I thought would kick off the parsing process. That’s when I started to run into problems.