Skip to main content

Motorola MC65


We have a new PDA in town now. As a replacement for the army of MC9000 and MC70s that are in the field and are being discontinued, we now are moving up to the Motorola MC65. I have had the new handheld for about a week now and have been impressed so far. It's a great improvement over the MC70. I have no idea how the numbering system of the Symbol / Motorola devices works. I assume there must be several ranges such as the 50s 60s and 70s.?

Anyway the?PDA?has windows mobile 6.5.3, a better touch screen and is faster. Much faster. The skin that has been put on the OS has also applied to our software and I think it makes it look much cooler. We had several problems in adjusting our software so it would work with the new MC65. First was the change in resolution. The MC70 has a much lower resolution than the MC65s and as some of our screens were not using the auto scale settings in the form and some of the buttons on our forms were created at run time rather than design time, this posed a bit of a problem for us.?

Ultimately the main way to handle the form resolution changes is to ensure you forms are auto scaling?

Me.AutoScaleDimensions = New System.Drawing.SizeF(96.0!, 96.0!) Me.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Dpi

I calculated the size of the controls that were being generated at run time by taking sizes off the controls that were automatically being sized correctly at design time.?

There were a couple of other problems as well, the speed at which the?PDA?goes was causing some problems when we were using a FileInfo object. When we do an over the air update of the software, there is a certain degree of file handling and the deletion of a file was being reached before the garbage collector came and got rid of the FileInfo object. Without a significant rework there wasn't a nice way to do it so we had to manually gc collect which was a bit of a stinker.?

Every morning our users carry out a download to get the latest stock movements to the?PDAs?for scanning. This is a fairly large chunk of information generally and can often take up to 7 minutes on the MC70. Not so on the MC65. It managed to do the exact same download in just over 1 minute. It made for very interesting viewing because we had always thought the transfer of data was the biggest killer, however it looks like just handling the large datasets that were being downloaded was a major contributer to the slow speed of the old?PDAs.?

The final problem is a real sneaky one. The test unit (in the picture) we had to develop on had an alpha numeric keypad. When you press either the Yellow or Blue function button on the Keypad, a small blue or yellow circle replaces the keyboard icon on the screen. For some reason this stops you from programatically showing the on screen keyboard, causing a crazy exception. When we tried the same thing on the numeric version the problem was not there. Luckily we are getting in the numeric versions and so decided to let some other poor soul worry about this.?


Dom Finn said…
Hi there,I have changed jobs since I have posted this. Overall though I was very impressed with the MC65. The quality of the handset was excellent and the speed was a serious jump up if you are used to older handsets!Regards,Dom

Popular posts from this blog

Creating star ratings in HTML and Javascript

I'd searched around a little for some shortcuts to help in doing this but I couldn't find anything satisfactory that included the ability to pull the rating off again for saving. I'd ended up coming up with this rather cheeky solution. Hopefully it helps you too! This is my first post in a while (I stopped blogging properly about 8 years ago!) It's strange coming back to it. Blogger feels very crusty and old by todays standards too.

Make your objects immutable by default

More about the Good Dojo In my post last week , I discussed creating objects that are instantiated safely. Please go back and read if you are interested. At the end of the post, I mentioned that I'd also written the class so it was immutable when instantiated. This is important!!! I feel like a broken record in repeating this but I am sure at the time of writing your code, you aren't modifying your object all over the place and so are safe in the belief that protecting against mutability is overkill. Please remember though, your code could be around for a hell of a long time. You aren't writing your code for now... you are writing for the next fool that comes along (including you) . Nothing is more upsetting that coming back to fix a bug on some wonderfully crafted code to say "Who has butchered my code?!", but often you were involved at the start of the process. You made the code easy to modify, allowing objects to be used / reused / modified without thi

An instantiated object should be "ok"

I've been QA'ing quite a bit of work recently and one common theme I've noticed across both Java and C# projects I have been looking at is that we occasionally open ourselves up unessacarily to Exceptions by the way objects are being created. My general rule of thumb (which I have seen mentioned in a Pluralsight video recently but also always re-iterate in various Robust Software talks I have done) is that you shouldn't be able to create an object and then call a method or access a property that then throws an exception. At worst, it should return null (I'm not going to moan about that now). I've created an example below. We have two Dojos, one is good and one is bad. The bad dojo looks very familiar though. It's a little class written in the style that seems often encouraged. In fact, many classes start life as something like this. Then as years go on, you and other colleagues add more features to the class and it's instantiation becomes a second