Oh no!
I, along with so many others recently experienced the dreaded Omnia align screen bug. When Windows Mobile starts up, it forces you to align your screen. However, if the screen won't align, which is incredibly common with the Samsung Omnia, you can't get past this screen and your phone is completely unusable. Personally, I'm staggered that such a big company will ignore such a fundamental issue.
Since my phone is out of warranty, I decided to take matters into my own hands and replace the screen. So I went to ebay and found a new digitiser for $12.98. I bought mine from this seller (search for Omnia Digitizer) and was very happy with the service. The digitizer came with a selection of tools that were sufficient to do the entire job.
The digitizer is a clear panel that sits on top of the lcd screen. It's what is responsible for letting the device know when the screen is tapped.
Fitting the digitizer
Once the digitizer arrived I found these instructions and followed them. Although since I was only replacing the digitizer I didn't need to remove the camera or the keypad membrane.
I then reassembled the phone and crossed my fingers. It powered up then presented the dreaded "align screen" screen. I tapped each of the alignment markers once and.... it worked!
Success!
Since then the phone has been so much easier to use! The accuracy of the screen is so much better than it ever has been. It's still nowhere near as good as an iPhone or a HTC HD2 or a HTC Desire... but what can you expect from Windows Mobile 6.1?
From a brick to a fully functional phone for only $12.98. Bargain of the year!
Update
After a few days of living with the digitizer I have found that it's incredibly prone to scratching. I've been careful to keep it clean but still have 3 significant gouges out of the screen. So I'd definitely recommend a screen protector goes on straight away.
Friday, May 07, 2010
Wednesday, April 07, 2010
Windows Phone 7 Series
I've been experimenting and researching development on Windows Phone 7 Series. I've installed the CTP and written my first program! If you want to get started, look at this free book by Charles Petzold.
Here are some of my observations.
Dev Framework
You can only write apps using silverlight or XNA (Xbox development framework). This has some pretty big implications, such as the fact that all applications written for previous versions of windows mobile will not run on Phone 7.
All of them. Throw them away. All of those organisations who have built product and ip based on Windows Mobile will not be coming to the Phone 7 party with any advantage. In fact, most of the current applications will not even have a parallel in Phone 7.
It will be nice for people who are already familiar with Silverlight. So there might be some nice apps written targetting Silverlight. The downsides is that it will require a connection and the performance will be related to the speed of your network connection.
XNA might also bring some XBox devs across. But there's a fairly steep learning curve and isn't that accessable for noobs.
One really big advantage is that MS has taken a much stronger grip on the hardware. Their specs are much more stringent. For example there will only be two screen sizes allowed. Large and small. No more having to cater for 15 different screen sizes!
DataStorage
There is no database on the phone. Silverlight apps can access a sandbox storage location. The word I've seen on various forums is that you're supposed to use cloud for data storage and you can store simple data as xml in Isolated Storage. However, this guy (http://sviluppomobile.blogspot.com/2010/03/sqlite-for-wp-7-series-proof-of-concept.html) has a POC with SQLLite running on Phone 7.
Target audience
The phone seems to be squarely targetted at the consumer. Most of the enterprise apps will mostly likely stay at version 6.5 and earlier. In a lot of ways, it looks like they've copied the iPhone but with bigger icons on the home screen.
Does the world need an iPhone clone with no applications currently written? Who knows.
Here are some of my observations.
Dev Framework
You can only write apps using silverlight or XNA (Xbox development framework). This has some pretty big implications, such as the fact that all applications written for previous versions of windows mobile will not run on Phone 7.
All of them. Throw them away. All of those organisations who have built product and ip based on Windows Mobile will not be coming to the Phone 7 party with any advantage. In fact, most of the current applications will not even have a parallel in Phone 7.
It will be nice for people who are already familiar with Silverlight. So there might be some nice apps written targetting Silverlight. The downsides is that it will require a connection and the performance will be related to the speed of your network connection.
XNA might also bring some XBox devs across. But there's a fairly steep learning curve and isn't that accessable for noobs.
One really big advantage is that MS has taken a much stronger grip on the hardware. Their specs are much more stringent. For example there will only be two screen sizes allowed. Large and small. No more having to cater for 15 different screen sizes!
DataStorage
There is no database on the phone. Silverlight apps can access a sandbox storage location. The word I've seen on various forums is that you're supposed to use cloud for data storage and you can store simple data as xml in Isolated Storage. However, this guy (http://sviluppomobile.blogspot.com/2010/03/sqlite-for-wp-7-series-proof-of-concept.html) has a POC with SQLLite running on Phone 7.
Target audience
The phone seems to be squarely targetted at the consumer. Most of the enterprise apps will mostly likely stay at version 6.5 and earlier. In a lot of ways, it looks like they've copied the iPhone but with bigger icons on the home screen.
Does the world need an iPhone clone with no applications currently written? Who knows.
ASP.NET MVC
I've been working with ASP.NET MVC for a while now. I really enjoy working with the framework and had a very successful project delivered using it. Some of my highlights are listed below.
Separation of concern
The framework is a wonderfully elegant implementation of the MVC pattern. Once you get your head around the responsibilities of the controller, model and view you can very rapidly produce robust, testable code.
Productivity
There are huge productivity gains available when using ASP.NET MVC. It takes so much complexity away from ASP.NET devlopment, without reducing flexibility and power. When doing ASP.NET development, you need to be aware of the page lifecycle at all times and trying to work out which actions should be performed at which step of the page lifecycle can be extremely complex.
Testability
The framework really lends itself to testability. You have to be a little careful to keep it clean, but if you do, the whole system is very testable. The key point to ensure testability is to only pass ViewModels into your controller actions. I cannot stress how important this is. As soon as you try to access the Request.Form in your controller method it becomes incredibly hard to test. You have to mock out the HttpContext and it just gets messy. Even with some very complex forms, I always found a way to represent it all using ViewModels. If you get stuck, use a custom model binder.
Reliability
This is the area that surprised me the most. We had a very low rate of regression errors. I attribute this to two factors:
1. Separation of responsibility - Each controller method operates quite independently, so changing code should not affect other functionality
2. Testability - Having a good suite of unit tests helps to catch any errors that might creep into the code.
I put together a presentation explaining some of these points in more detail. It's available here.
Separation of concern
The framework is a wonderfully elegant implementation of the MVC pattern. Once you get your head around the responsibilities of the controller, model and view you can very rapidly produce robust, testable code.
Productivity
There are huge productivity gains available when using ASP.NET MVC. It takes so much complexity away from ASP.NET devlopment, without reducing flexibility and power. When doing ASP.NET development, you need to be aware of the page lifecycle at all times and trying to work out which actions should be performed at which step of the page lifecycle can be extremely complex.
Testability
The framework really lends itself to testability. You have to be a little careful to keep it clean, but if you do, the whole system is very testable. The key point to ensure testability is to only pass ViewModels into your controller actions. I cannot stress how important this is. As soon as you try to access the Request.Form in your controller method it becomes incredibly hard to test. You have to mock out the HttpContext and it just gets messy. Even with some very complex forms, I always found a way to represent it all using ViewModels. If you get stuck, use a custom model binder.
Reliability
This is the area that surprised me the most. We had a very low rate of regression errors. I attribute this to two factors:
1. Separation of responsibility - Each controller method operates quite independently, so changing code should not affect other functionality
2. Testability - Having a good suite of unit tests helps to catch any errors that might creep into the code.
I put together a presentation explaining some of these points in more detail. It's available here.
A strongly typed RadioButtonList for ASP.NET MVC
There are many strongly typed controls in ASP.NET MVC. For example TextBoxFor. I really like using the strongly typed HTML helpers because you get much better information at compile time. Especially if you've turned on compile time view checking.
The one control that was missing, however is RadioButtonList. There is no "RadioButtonListFor" to be found. So I wrote my own.
This is what the code looks like in the aspx
Here's the code in the controller to check what the user has selected
Additionally, at the risk of creating an infinite loop, here's a StackOverflow question that this post is an answer to. It's got some useful comments and more code.
The one control that was missing, however is RadioButtonList. There is no "RadioButtonListFor" to be found. So I wrote my own.
This is what the code looks like in the aspx
<%= Html.RadioButtonListFor(m => m.GenderRadioButtonList)%>
Here's the code in the controller to check what the user has selected
public ActionResult Submit(HomePageViewModel viewModel)
{
if (viewModel.GenderRadioButtonList.SelectedValue == HomePageViewModel.GenderType.Female)
{
// Do something
}
return View("Index", viewModel);
}
The code, plus a sample website using it, is in this zip file.Additionally, at the risk of creating an infinite loop, here's a StackOverflow question that this post is an answer to. It's got some useful comments and more code.
Subscribe to:
Posts (Atom)