JavaOne

I registered for JavaOne today. I’m totally pumped!

Update: It had to happen. I registered for a bunch of stuff on the 18th, and didn’t remember I have tickets for a show that night. That wouldn’t be a huge deal except it’s the third set of tickets in a row that Cathy has bought for me, and then one of us had to cancel.

Update 2: It had to happen. After I rearrange my JavaOne schedule to be able to go to the show, the show gets cancelled. Oh well. Now I’m back to my original situation, which, according to my blog, had me totally pumped.

Synchronization with .NET Compact Framework (cont.)

So, suppose we were going to sync over the network whenever we have a network connection(some thoughts on that here), and suppose we have a user that is only connected to the network when he is plugged in to the cradle. How could we ensure that his data will get synchronized when he is cradled, even if our application is no longer running?

I think the answer is in having a console or ‘headless’ sync app. This is an application without a user interface. Whenever our main application is running, we check to see if the headless sync app is running and shut it down. Then, whenever we close our main application, we start up our headless sync app.

The headless sync app will basically detect when it has a network connection, and when it does, sync anything outstanding and shut itself down when finished. It would have to be able to tolerate network connections that did not last long enough to complete the sync operation.

In this way, whenever there was sync work to do, an application (either the main app or the headless sync app) would be running, waiting for a network connection to do the sync. Whenever there was no sync work to do, we would not have any extra applications running.

Of course, the downside of this is that we would have a lingering application running as long as there was sync work to do. That can be seen as bad behavior (I’m looking into whether it would be bad etiquette.).

Also, how do we tell that there is sync work to do? We can tell that the user has inspections to upload, but how can we tell whether there are label changes or a new version of the application to upload? For this problem, we could use the same pattern we use today. We check whenever we are sending something. So, if there are no inspections to send at sync time, there will be no label uploads either. We would probably also want to give the user an opportunity to force this check, or to set up an interval to do the check – e.g. if we haven’t checked for new labels in 1 week, there IS sync work to do. Of course, this would only get updated if the user actually opened the application, so he could be very far behind for one session until his next sync.

We would also have to tolerate the less common case of a user doing a soft reset of the device, killing our headless application before he connects to the cradle.

So those are all the challenges/problems with the idea. What’s the upside? First, we get a background sync in most cases. Users don’t have to remember to sync anything. This background sync can happen at any time the user has a network connection, which would be nice for our wireless users. Last but not least, we don’t have to go through all the ActiveSync headaches.

I’m not necessarily sold on this approach. I could be talked out of it. But for now, it’s my recommendation.

Synchronization with .NET Compact Framework

I thought I would take a few minutes and get my thoughts down on synchronization on Pocket PC.

ActiveSync does not play nicely with .NET (so called ‘Managed Code’). You can write ActiveSync service in C++ and COM and compile it in a special way that lets it call a ‘Managed Code’ .dll, but it is not very natural, and we don’t necessarily want to learn C++ and COM anyway. There is a two part lesson on how to do it here and here.

It was surprising that there was this big barrier between ActiveSync and .NET. The only explanation I can see is that they want you to synchronize your data in a different way (at least as far as I can tell.) They want you to do things like database replication or syncing over the network. Database replication seems like a very bad way to go to me, as it requires us to host a SQL Server instance that can be accessed from outside our firewalls.

That leaves sync’ing over the network. We want to have that ability anyway, so why not just do it all the time. The problem is that for users that do only have a network connection when the Pocket PC is in the cradle, we cannot expect them to always have our application running when they cradle it. If it only syncs when cradled and running, then we have a problem.

I’m still looking into whether anyone has some best practices around this.

Optimized Null Check Pattern

Jonas Bonér has posted an Optimized Null Check Pattern that he’s pretty proud of.
(Hint: He’s kidding.  Don’t do this!)