Almost always connected scenario

  • Thread starter Thread starter Lonifasiko
  • Start date Start date
L

Lonifasiko

Hi,

We are planning a new project for devices running Windows Mobile. The
main doubt we've got at the moment is if we build a sometimes
connected scenario or an always connected one.

There will be a database server as the main application's repository,
but the most important part of the project targets people that need
mobility (no tied to desktop PC) in a quite reduced indoor space,
therefore, the idea would be to set up a WIFI network indoor.

Then, my initial idea would be to have a local database on the device,
that at a regular period synchronizes data with database server thanks
to WIFI connection (GPRS would not be needed). The unique limitation
we've got is that synchronization must be done quite often, that is,
we cannot be more than 15 minutes for example without synchronizing
data with the server. Changes made on devices must be available "quite
instantly" (15 minutes of delay would be nice) on database server for
other users to consume them.

As you can see, I'm talking about an scenario very near to "always
connected" paradigm. Then, would be possible to develop a Compact
Framework application that is "always connected" to the server. Some
years ago there were ASP.NET Mobile applications, but the problem
there was that you must open a browser and point to web application
server URL, the application was formatted depending on the device, and
so on, and that's a very different approach of interacting with a
Windows Forms Compact Framework "user-friendly" application.

Don't know if nowadays there's something similar and mor euser-
firendly that lets the user be "always or almost always
connected" (VIA WIFI, no GPRS) to a server from a device running
Windows Mobile.

Any advice or suggestion would be greatly appreciated. Thnaks very
much in advance.

Miguel
Blog: http://lonifasiko.blogspot.com
 
Miguel,

There's a world of difference between "always connected" and "almost always
connected". I think you are wise to plan for the latter by having a local
database that syncs with your server periodically.

There are some great resources here. In particular take a look at Sync
Services for ADO.NET (Devices) which is currently in CTP:
http://www.microsoft.com/downloads/...9F-1B5E-49BC-A21A-9EF4F34DE6FC&displaylang=en

There is also a sample Windows Mobile app that uses Sync Services here:
http://www.microsoft.com/downloads/...3D-64AD-4A3D-85D2-E711ABC87F04&displaylang=en

Ginny Caughey
Device Application Development MVP
 
It's pretty easy to do merge replication in this sort of a situation. You
need to be connected during the initial configuration, where the basic data
from the database is downloaded to the device. After that, you can have a
periodic timer fire a synchronization event, causing any changes that should
be replicated to the server from the device to be sent and the same for
changes to the server that the device needs.

The only advantage of this over sync services for devices is that it's
already released and you can use it with SQL Server 2005 and SQL Compact 3.5
(on the device), right now. It's too complicated to provide some sort of a
tutorial in a newsgroup, but most of the problem is set up of the server and
the help for SQL Server 2005 does a pretty good job (I figured it out from
reading that). The code on the device looks roughly like this:

-----

connString = <connection string for the local database>;

repl = new SqlCeReplication();

// Define the remote end of the subscription. This stuff points to the IIS
server that
// is used to communicate with the database for replication.
repl.InternetUrl = "http://" + INTERNET_SERVER_NAME +
"/sqlc35sync/sqlcesa35.dll";
repl.InternetLogin = INTERNET_USER_NAME;
repl.InternetPassword = INTERNET_PASSWORD;

// This stuff defines the actual database server to which IIS will direct
requests for
// replication data. You can, of course, run IIS and SQL Server on the same
server,
// if you like. In that case, INTERNET_SERVER_NAME and PUBLISHER_NAME
// would probably be the same name.
repl.Publisher = PUBLISHER_NAME;
repl.PublisherDatabase = PUBLICATION_DATABASE_NAME;
repl.Publication = PUBLICATION_NAME;
repl.PublisherLogin = PUBLISHER_USER_NAME;
repl.PublisherPassword = PUBLISHER_PASSWORD;

// Define the local end of the subscription.
repl.Subscriber = SUBSCRIBER_NAME;
repl.SubscriberConnectionString = connString;

if (<first time run on this device>)
{
repl.AddSubscription(ao);
}
repl.Synchronize();

// Now that the local database has been created or synchronized, open it and
use
// it using SqlCeConnection, etc...
 
Thanks both Ginny and Paul,

Yes, in fact, two years ago I used Merge Replication in a "less
connected" scenario, so I've got some experience in these issues. I
was asking this to the newsgroup because this time I need, as I
mention, a "more connected" scenario, that is, synchronization to be
made in shorter intervals of time, I would be talking about
synchronization taking place every 5-10 minutes.

As Ginny suggested, I'll take a look at Sync Services for ADO.NET,
although maybe Merge Replication option looks better at the moment.

Anyway, as you see, I was looking for a "more near real time"
solution, but I understand SQLServerCE does not allow me to interact
directly with a SQL Server backend database; in this case, I see I
should choose to use an ASP.NET application in the device (don't like
the idea very much), or even a .NET Compact Framework application that
calls a Web Service responsible of exchanging data. The problem here
is I suppose I'm permanently connected to WIFI network, so when
network gets down, I would not be able to exchange data and I would
not store anything in local database, which definitevely would run me
into problems.....What do you think here?

And last but not least: What about talking from Windows Mobile device
to MySQL database backend directly? I remember there was a connector
that let you directly access a MySQL Server on the network, without
using a Web Service...I think I'll take a look again.

Thanks very much again and regards,

Miguel
Blog:http://lonifasiko.blogspot.com
 
You can synchronize as often as you like with merge replication. My code is
set up to do it every 15 minutes, but you could do it every 1 minute or
every 1 month. It's entirely at the control of your desires.

You don't want to use any direct-to-database connection scheme, because you
*know* that you won't always be connected. Merge replication seems
absolutely perfect to me. Data is always saved in the local database, so
you don't have to worry about anything being lost. You have total control
of when the sync occurs (you could trigger is as soon as you return to
network coverage after being away for a while, once every 10 minutes, as I
said, etc.) Remember that merge replication only sends the *changed* data
back and forth, not the whole database. This is the best you can possibly
do...

Paul T.
 
Any advice or suggestion would be greatly appreciated. Thnaks very
much in advance.

Miguel
Click to expand...


FWIW, my very first .Net app has been an always-connected compact
framework design for forktrucks using WIFI. It shows the open "orders"
from the lines (refresh of 10 s to 3 min) from which a driver can put
into his "basket" and then pickup & deliver. Just started testing it
live but it seems to work fine. We'll be adding in a receive only
messaging capability soon (eg, send a specific forktruck a message) as
well as location of material. For our requirements, I don't think
using a local database would work well, but I am new at .Net.
 
Using a local database that is periodically synchronized to the main sever
wouldn't work *any* differently at all. The only change to your existing
code is the type of connection object that you create and the connection
string. The rest of the code is the same. Then, of course, you have to
periodically (or on some event), merge your database with the server
database, but that would normally occur outside of the execution environment
of anything else you might be doing and could be completely transparent to
the rest of the code.

Paul T.
 
Back
Top