• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 506
  • Last Modified:

Sending Data over wi fi to server.

I have a windows mobile application that runs on a PDA.  It is written using eVC++4.  The application stores data in a databse on the PDA AND also sends the data via wi-fi to a server as soon as it is recorded.
I am trying different methods to do this properly and ensure that the architecture is right.  I am able to store the data in the database properly and also send it via wi-fi to the server.  I have the wi-fi sending part running on a different thread.

I want to do the following:
1. Tap a button on the PDA that is associated with some data.
2. Store this data locally on the PDA AND send it via wi fi to a server.

I want to check each piece of data and ensure that is sent, if it did not send then send it again. (Wait for acknowledgement)
If I tap a button and then wait for it to be sent to the server (it may take a second or two at most) then this slows my application down as I want to enter data quickly on the PDA.

How should I best do this?  Please advise.  If you need any more information just ask.

Thanks

networking
0
Wanting2LearnMan
Asked:
Wanting2LearnMan
  • 5
  • 4
  • 2
  • +1
5 Solutions
 
alb66Commented:
For each record in your database you can add a flag (status):

0 = none
1 = sent
2 = ack received

You can set it to 0 when you add the record,
set it to 1 when you send data
set it to 2 when you received the ACK

0
 
alexey_gusevCommented:
depending on the nature of the data and the application, you may or may not use asynchronous approach (ie with threads).

if you just need to enter the data on PDA and don't use it afterwards, I'd go for threads with possible callbacks/messages back to UI to let the user know about any errors (if required)

besides, you might want to have some mechanism to upload all unsent data at some point (at the app's startup perhaps)
0
 
Wanting2LearnManAuthor Commented:
Thanks for both replies.
At present I have tried two methods.

Method 1:
Have the wi-fi thread try and loop round the data that I have stored in the database and check a flag (like what alb66 said) to dee if the data has been sent and if not send it again.  The problem I have here is that  I got errors when both the wi-fi thread and my main program thread tried to access the database together.

Method 2.
Store the data in the database and at the same time put in into a CStringArray.  The wi-fi thread then loops round this CStringArray and sends the data in it to the server.  This way I dont get the clash of two threads accessing the database.  But then afterwards I have no way of looking at the database and knowing for sure if the data was sent or not.

The user must to be able to enter data fast on the PDA, thats why I want to use threads so as to seperate out the sending part.

Any other suggestions

Thanks for your help.
0
Put Machine Learning to Work--Protect Your Clients

Machine learning means Smarter Cybersecurity™ Solutions.
As technology continues to advance, managing and analyzing massive data sets just can’t be accomplished by humans alone. It requires huge amounts of memory and storage, as well as the high-speed power of the cloud.

 
alb66Commented:
>>>>I got errors when both the wi-fi thread and my main program thread tried to access the database together.
You can use e syncronization object to avoid access at the same time
http://www.codeproject.com/KB/threads/Synchronization.aspx
0
 
alexey_gusevCommented:
you'd need to add some synchronisation for database access to prevent potential conflicts, usual producer/consumer mechanism would do I think
0
 
Wanting2LearnManAuthor Commented:
Ok I'll check out the synchronisation link above.

So You think this is the best way to move forward on this?  Storing the data in the database and also having the wi-fi thread read from the database and send it?

Thanks.
0
 
alexey_gusevCommented:
I'd vote for this, yes
0
 
Wanting2LearnManAuthor Commented:
Ok thanks,
I have further questions on events and synchronisation etc, will I ask them in a seperate new post?
0
 
alexey_gusevCommented:
ask here ;)
0
 
Wanting2LearnManAuthor Commented:
Ok I have two threads: the main thread and the wifi thread.  Both need to access the database.
The main thread puts data into the database when the user clicks a button and then continues to either wait and do nothing or put more data into the database on another button click.
The wifi thread will constantly look at the database and check if the data has been sent, if data has not been sent then it sends it.

I'm wondering how I will get the synchronisation right as I DO NOT want the main thread to slow down in any way if it has to wait on the wifi thread to finish accessing the database.  If it did slow down then the user would experience a slight 'freeze' in the program.

Here is one idea I have, it may be silly so please correct me if i'm wrong: Introduce another thread to handle STORING the information into the database.  This 'database' thread could then fight it out with the wifi thread over whos turn it is to access the database.  Ideally I do not want to do this as I dont want to indroduce another thread and complicate things.

Thanks
0
 
Wanting2LearnManAuthor Commented:
well...any ideas??? anyone
0
 
mrjoltcolaCommented:
You should consider using something like iAnywhere or SQL Server Mobile edition. That is state of the art / best practice. Of course writing your own works, but it all depends on how much time and money you have. iAnywhere (Sybase Ultralite) has specific support for background synchronization while user is using the application.

http://www.sybase.com/products/databasemanagement/sqlanywhere

If your data schema is just simple, 1 or 2 tables, then maybe writing a custom solution is best, but past that, I would go with a commercial synch solution.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 5
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now