Windows Mobile 2003

Topics: Mobile Client Software Factory
Apr 25, 2006 at 7:18 AM
originally posted by: ThoreB

This looks really great. But I have a lot of customers with Windows Mobile 2003 devices. Will this project support this OS?
Apr 25, 2006 at 12:41 PM
originally posted by: jeff_at_CWRMobility

You must have read my mind. Indeed, it looks really great and I was also wondering if Windows Mobile 2003 is supported.

Or maybe another question. I haven't looked at the sources in detail yet. How much Mobile 5.0 specific code is there and would it be (relatively) easy to change it to get it to work on 2003?
Apr 29, 2006 at 10:11 AM
originally posted by: jeff_at_CWRMobility

At a first glance, it looks like only the ConnectionManager application block uses WM5 specific classes. The DisconnectedService makes use of the ConnectionManager AB.

So, if we could create a WM2003 implementation of the ConnectionManager, it should work on WM2003.

Anybody, correct me if I'm wrong.
Apr 29, 2006 at 3:05 PM
originally posted by: EdJez

And we built the CM thing so the connection definitions are 'pluggable' - not explicitly to support 2003 (which we won't test against, but would love to hear your results) but as a result of having to accept different criteria for what it means to be connected. For example, our expert advisors suggested to create connection definitions that only report connection if the underlying connection has been around for a certain time (to avoid flukes), if the signal strength is so-much, or depending on battery power. The pluggable approach lets you define your own connectivity status strategies. Let us know how it's working with 2003 and if there are any simple things we could do to improve your migration we might get to do them (no promises thou).
May 20, 2006 at 7:27 AM
originally posted by: JohnSocha

To expand on what Ed said, a number of the blocks should work on Pocket PC 2003. However, we're not testing our work on 2003. I did do some testing about a month ago just to see if things worked on 2003 and they ran fine.

Except for CAB (which should work just fine on 2003), all of the other blocks we've written are designed to be stand-along as much as possible. When they require other blocks, the references o the other blocks are done via either abstract classes or interfaces so you can change the implementation if you need to. So in the case of the disconnected service agent block, it uses a connection manager block (which we're renaming the connection monitor block) to monitor and check network connections so it knows when to send messages out, and which messages can be sent out. You could easily replace this block with something simpler that would meet the needs of your applicaiton without having the full functionality that is provided by WM 5.

If you have suggestions for how we should document this or change it, please let us know. Now is the time to do it because we're rapidly approaching the June 30 release date.

-- John Socha-Leialoha
May 20, 2006 at 9:23 AM
originally posted by: jeff_at_CWRMobility

It just so happens that I rewrote the ConnectionManager to be usable on PPC 2003 today. Also, for the app I'm working on I don't need the advanced functionality like pricing connections etc, so I just made a really simple ConnectionManager class that polls for a connection, raises an event when the connectionstate changes and exposes an IsConnected property. That's all I need and it works fine!

I have to say that DisconnectedServiceAgent is awesome! I made some changes to that implementation too, but just minor. A few things I noticed: The ReturnCallback and ExceptionCallback values are mandatory to save in the queue table. You get an exception when they're null. However, in some other parts of the code, the possibility of null is taken into account. Personally I think they should be allowed to be null.

In my case I'm saving different kinds of objects and it would be nice if I could identify the type of object, so that when synchronizing I could show e.g.: "Syncing 2 appointments and 3 tasks". Hmm, I could use the Behavior.Tag for that ofcourse...

Something odd I think, but maybe I just don't understand it completely: The Configuration AB uses the namespace Microsoft.Practices.Mobile.CompositeUI.Configuration.WM5. I'm not sure what CompositeUI has to do with the Configuration Block.

Jun 1, 2006 at 6:54 AM
originally posted by: JohnSocha

The configuration block used to be in the CompositeUI assembly, and when we moved it out of that assembly, we neglected to change the name. More recent drops contain a correct namespace. Thanks for pointing that out.

-- John
Jun 9, 2006 at 10:28 AM
originally posted by: michael_baltic

Are you willing to share your code for the 2003 connection manager? I don't seem to be able to get the OpenNETCF events to fire on my device either.

I think with the majority of 2003 devices out there, a non WM5 version should be available. The SystemState property and its changed event handler is the only WM5 specific code in the current release...
Jun 17, 2006 at 9:24 AM
originally posted by: jeff_at_CWRMobility

I'll post a sample of my code as soon as possible. However, keep in mind that it's a very simplified version of the ConnectionManager. I built it just to suit my needs. I took away the different connections and networks, and also the connection pricing.

The ConnectionManager is just a class that polls for a network connection at an interval and raises an event when the connectionstate changes. I've also removed parts from the DisconnectedServiceAgent code that I didn't need anymore, especially concering the relation with the ConnectionManager.

So, it's not generic and extensible anymore, just my implementation of it.
Jun 25, 2006 at 3:10 AM
originally posted by: AsadNafees

I've edited all the project files in the source to make it work with WM 2003 and except for the Orientation Component and the ConnectionManager, everything works fine. I'd like to see how you corrected the ConnectionManager, it would be great if you could post it soon.
Jun 25, 2006 at 10:57 AM
originally posted by: jeff_at_CWRMobility

Ok, I've got some sample code ready. Can I upload that somewhere?
Jun 26, 2006 at 11:23 PM
originally posted by: donelodes


It would be great if you could share your code with the community :)
Jun 27, 2006 at 4:54 PM
originally posted by: PerVonge

Jeff, please upload the samples to the "User Samples" on gotdotnet and post the link in this thread; we will point to this as well. THANKS!
Jun 29, 2006 at 11:05 AM
originally posted by: jeff_at_CWRMobility

Ok, I've uploaded the sample code. As soon as I get a confirmation from GotDotNet I'll post the link.

Some explanation and disclaimer in advance :)

As explained before, it's not a generic ConnectionManager application block anymore. I changed the code to suit my needs which means I stripped out stuff, changed stuff, so only the necessary parts for me stayed. I also removed the advanced parts like adding different networks and connections and pricing. The ConnectionManager simply polls for a network connection periodically. First by looking at the IP address and then trying to connect to some web url. That way you can see if you're connected to a network and if you can reach a certain web url (a webservice in my case).

I'm not satisfied with the CheckConnection method in the ConnectionManager yet. If there's a connection it returns true, otherwise it throws an exception (instead of returning false). But you get the idea :).

Because of these changes I also changed the DisconnectedAgent quite a bit. Removed the specific pricing and network parts.

The ConnectionManager is implemented as a singleton. You can create on like this:
ConnectionManager connectionManager = ConnectionManager.CreateConnectionManager();

When working with the RequestManager in the DisconnectedAgent block, you create a RequestManager like this:
RequestManager requestManager = RequestManager.CreateManager();

The RequestManager itself takes care of creating the ConnectionManager.

You can explicitly check for a network connection like this:

You can also start polling periodically like this:
connectionManager.EnablePolling = true;

The polling method used the OpenNETCF BackgroundWorker and raises an ActiveNetworkChanged (I changed this event a bit) event when the connectionstate changes.

So to listen to changes in the network connection you do this:
connectionManager.ActiveNetworkChanged +=new EventHandler<ActiveNetworkChangedEventArgs>(ConnectionManager_ActiveNetworkChanged);

Well, I think that's about it. I'll let you know when the download link is active and when you have any questions/improvements, let me know!

Jun 29, 2006 at 11:36 AM
originally posted by: jeff_at_CWRMobility

Oh, something else I forgot to tell. I've changed some more things to the DisconnectedAgent block. I used my own SQL helper class and changed something in the table structure of the RequestQueue. So make sure that you compare that code to the actual DisconnectedAgent block from the Software Factory. Don't just copy my code!

Jun 29, 2006 at 11:44 AM
originally posted by: jeff_at_CWRMobility

Ok, it's me again. My upload was approved, so here's the link:

Let me know if it works for you.

Jun 30, 2006 at 4:19 AM
originally posted by: donelodes

Did anybody succeded using the PINAuthentication and OrientationAware modules on WM2003?

I tried using them, and was able to compile both, but when running the application both throwed exceptions...

Jul 2, 2006 at 12:11 AM
originally posted by: ThoreB

Have you seen Jim Wilsons WebCast about the orientation aware controll. (Adapt your app 1 of 3). He explains the reason for some of the exceptions you migth get.
Jul 2, 2006 at 5:24 AM
originally posted by: donelodes

Thanks for the advice!! I didn't know there were webcasts for the MCSF...

Do you know if there are more available?
Jul 2, 2006 at 8:43 PM
originally posted by: nrandolph

There is another, perhaps more significant IMHO, issue with the DisconnectedServiceAgent when you are calling a webservice that takes a byte array (for example if you were to upload an image to a webservice). As this parameter is serialised it is converted to a base-64 encoded blob and an attempt made to store it in the queue datatable. Unfortunately this either crashes the app (without exception) or throws an exception that claims out of memory. I resolved this by placing byte array parameters in a table of their own - perhaps this needs to be extended to other parameter types???
Jul 2, 2006 at 10:16 PM
originally posted by: dcazzulino

I believe this has already been fixed in out latest source. It should work fine when we ship.