I am currently finishing off a tiny little WP7 application for a client here in New Zealand, which as such is not that very impressive. It seems like there is a LOT of apps on the way for the phone. I like it! At least the developers seem to have adopted the phone as their newborn child…or at least as a potential platform for future mobile apps…
But I am not going to be writing about that app. At least not right now. Instead, I wanted to write a little about something that surprised me. I have not been doing too much WP7 development. At least not the kind that includes a load of input controls. So I was kind of stumped when I found out that the phone does not have a ComboBox. Or rather, it does, but it doesn’t have a template suitable for the phone.
I found this to be rather odd, but could on the other hand understand that a ComboBox is probably not a control that is very well suited for a device like the phone. The OS itself seems to be using a list picker thingy instead, but that control seem to have stayed in Microsoft’s own control library and is not available. At least not that I have found.
So I guess the only solution is to do it yourself…at least after you Google it, which was what I did. I did find a couple of interesting ideas on how to style it, but they didn’t seem to follow the Metro style well enough to make me happy. Finally I found http://dotnet.dzone.com/articles/metro-style-combobox-windows, which got to act as the foundation for my control…
More...
Lately I have been working a bit on a couple of Windows Phone 7 apps, and I found a couple of interesting things along the way. I am going to try to blog more frequently soon, and try to cover as much of the interesting stuff as I can find. But it will have to wait until after TechEd New Zealand. But if you happen to be going to TechEd Australia or New Zealand, don’t forget to come to one of my talks and say hi.
Anyhow, the funky problem I am going to write about today is around a feature called InputScopes. On the phone, you can configure your TextBoxes to use different InputScopes. The InputScope defines which of the different software keyboards to use when writing in the TextBox. This is a really cool feature as it helps the user to write the type of info he/she is supposed to provide. It can be things like numbers or currency or chat. Each InputScope results in a different keyboard. Or at least some of them do. There seems to be more InputScopes than cool keyboards at the moment though…
More...
In my last post I wrote about how I had created a ViewModelLocator that was a bit different from what everyone else was using. I had come up with the awesome idea to use the same VMs at design-time as I used at run-time. This idea sounds very good, as it means that I only needed to build a single set of VMs and instead could switch the service implementations using DI. At the time, it sounded like the most “correct” solution. Little duplicated code, no chance of messing up the bindings and so on…but it has a huge problem…
More...
[UPDATE] This post is somewhat interesting, but the idea doesn’t really work in the real world. More info HERE [/UPDATE]
I have tried to stay out of certain areas when I blog. Why? Well, simply because some things are still heavily debated, and some debates even seem a bit infected. Some topics seem to cause people to get somewhat rabid and I don’t feel like causing a big flame war of any kind. But still, I have decided to talk a bit about some of the options we have when binding our views to our viewmodels, or vice versa. I can’t even write that with out having to be careful…
More...
I want to start off this blog post with saying that I love Expression Blend! I have only used Blend 2 SP 1 before today, but I love the idea, the interface and the program in general. But in Blend 2, there were a few things I missed. The most obvious flaw in Blend 2 is the missing intellisense. It also expected me to do ALL my coding in VS, which to be perfectly honest is a good thing. Coding should not be done in Blend. Blend is the tool for the interaction designer, or possibly the “devigner” and not for the developer.
But this is where I start getting a little ambivalent. I want to be a good developer and say that that is the way that I generally do my Silverlight problems. The developer doing the coding in VS and the designer doing the layout on Design and then the interaction designer/”devigner” putting it all together in Blend. Unfortunately that doesn’t add up in my world…sorry Microsoft…I love the idea, but in my world it doesn’t work, even though I wished it did.
More...
At my talk at TechDays 09 here in Sweden, I was followed on stage by two guys from RTC Factory. They were there to talk about the workflow between the developer and designer. One of the big upsides to Xaml and Silverlight/WPF is that we can split the design and coding between the developer and the designer. No more mock-ups from the designer that the developer needs to implement. In the world of Xaml, the developer creates the functionality and the designer the design. Like it should be. We are all specialized within our area, which is natural. And hence it is also natural to split the responsibilities. So how does this work?
More...