For those of you who already have some experience developing Windows 8 apps, I compiled a (partial) list of changes that I find notable on the UI side. For those that haven’t, the below are things that you should absolutely not think twice about implementing in your apps.
- Tiles now have two new sizes, while older ones has been renamed. The new sizes : “Small” and “Large”, while “Normal” was renamed to “Medium”.
- This does not mean that your old code would stop working, as the older names are still mapped to new ones in the enums for backward compatibility, but if you want to support the newer tile types, you would have to update your code.
- The only restriction is that in order to support the Large tiles, you will also have to support Wide tiles in you app.
Multiple windows/No more snap-view
- Snap view was replaced by a variable size window mechanism allowing the user to have multiple apps and windows running on the screen at the same time, with different widths, while an app may also spawn other apps and share the available space with it.
- You now have to the following new properties in the ApplicationView class: AdjacentToLeftDisplayEdge and AdjacentToRightDisplayEdge used to determine if your app window is adjacent to one of the edges, IsFullscreen and Orientation.
- The Search charm, while still there, will now act more of a global (computer-wide and/or web) search, and less of an in-app search. Visual Studio 2013 now offers new SearchBox control to be included in the apps themselves and used for in-app searches. Older, search-ready Windows 8 apps will still work with the search charm as they did before, but in order to search within the app the user would have to run it first and select it as target on the search target combobox. Not as intuitive as it used to be, or as using the in-app SearchBox control.
- Flyout: No need to use third party vendors’ flyout controls anymore. The Flyout control allows you to display a floating window which is not a dialog (unlike MessageDialog). Deriving from the Flyout control, you now also have the MenuFlyout and the SettingsFlyout controls.
- Hub: New navigation control allowing you to to aggregate different types of information controls within one content control, therefore controlling the width of your app’s main screen. For example: Displaying a GridView of images in one hub section, a ListView of detailed information in another, and a form on a third section.
- AppBar: Windows 8 already allowed you to include various controls in the app-bar, but Windows 8.1 offers the AppBarButton, AppBarToggleButton, and AppBarSeperator controls right out of the box to be used as part of the new CommandBar control within your app-bars. So, what is the difference? It’s all about styles and conventions. Using the new controls allows you to have your app-bars look and behave in a more conventional way while the CommandBar control automatically lays out the commands on the bar,
As you can see, developing for Windows 8.1 is definitely not different than developing for Windows 8. It is actually easier. Migrating your apps to Windows 8.1 is mostly performed automatically, and you can make the required changes to support the new features in a fraction of the time it took you to develop your app originally. I would definitely suggest migrating your apps to allow your users to benefit from these improved UI capabilities.
While I did not cover all of the changes in Windows 8.1, and not even all of the changes to the UI, what you do have here are the ones that will make your development easier, while, and most importantly, enhancing the experience of your app for your users.
Featured on MSDN Canada’s Canadian Developer Connection
Have you ever tried to run/debug your Windows Phone 8 apps when using Hotel mode Wi-Fi?
Hotel-mode Wi-Fi are guest access Wi-Fi routers that do not require a password to connect, but rather the first time you attempt to open a web-site you are routed to a login form, where you’re prompted with either a confirmation page or a user-id/password page.
So, where’s the problem?
You have your Visual Studio 2012 open, you already connected to the Hotel-mode router and made sure to open a page (google.com/microsoft.com/whatever) in order to go through the intermediate page and get internet connected.
Now, you launch your app, causing the emulator to load (takes about forever…) and the app to run just to find out that your app cannot connect to the internet!…
Checking again, you discover that your computer somehow reset the connection with the router and you have to go through that login page again. But, that’s not enough, as the connection will keep resetting every few seconds, making it almost impossible for you to run and debug your app, assuming it requires internet connection.
So what can you do if you just have to debug or demo your app from the emulator on such a network, assuming you do not have a
After many tries (and failures), I found only two possible solutions:
The first is to use your phone’s mobile data and tether the internet connection through Wi-Fi to your computer. But, mobile data doesn’t come cheap and you would rather use that complimentary Wi-Fi for your tests.
The solution I found was to run a USB tethering app on my Android phone, have the phone connect to the Hotel-mode Wi-Fi and tether the connection to the computer using cable.
That way, the connection is not being reset when using the emulator and you can run/debug your Windows Phone 8 app.
Thanks to everyone who attended my “Azure as the backbone” web-api based talk today @DevTeachConfere in Montreal.
Demo code can be found on my sky-drive here.
See how easy it is to create a web-api based app using the Visual Studio 2012 wizard, deploy it to Azure and then create Windows 8 and Windows Phone 8 apps that uses the service from within Azure.
Going through these examples you’ll see that there was very little code required in order to get these Windows 8/Windows Phone 8 apps connected to the web-api based Azure app.
Please note that the web-api MVC 4 project uses a bunch of NuGet packages, automatically installed by the wizard within my project.
Write me or comment for questions!
Microsoft Kinect SDK is claimed to work under Windows 8.
Well, before you run-off starting to develop your next Kinect multi-touch experience for the Windows 8 UI, it is important that you know that there are limitations to that.
Although using the latest Kinect SDK driver, released October 2012, you can develop and run apps under the Windows 8 operating system, it only works for developing traditional desktop apps, meaning what you would call “Windows 7 apps” and not what is called: “Windows Store apps”, also formerly known as “Metro-style apps”.
The Kinect libraries are not compatible with Windows Store apps and therefore you cannot add a reference to a legacy library that works against the Kinect SDK. Visual Studio 2012 prompts you with an error message saying: “Unable to add reference”.
I’m currently working on a work-around that may enable a small portion of the Kinect features in Windows Store apps and will surely update when I come-up with something.
Latest Kinect SDK information and download to be found here: http://www.microsoft.com/en-us/kinectforwindows/develop/new.aspx
So, you’ve created an amazing new app for the Windows 8.
Everybody loves it and tell you that you should make it public and that people should pay you to use it.
But, how do you do that? It sounds complicated, isn’t it so?
It sounds like something companies does, not private people or small groups!
Well, it’s not that complicated and surely everybody can do that. It just takes some learning and a few correct steps and you’re there, at the app store, with your brand new app waiting to be downloaded and purchased!
So, to help you jump the hedge, I’ll be giving a lecture @devacademytoronto titled: “From a New Windows 8 Project to the Store“, in which I’ll show the list of actions to be taken in order to have an app in the store, explain the methods and show the pitfalls to avoid along the way.
See you there!