|
Question : 3G CDMA VS GPRS 500 PTS
|
|
HELLO EXPERTS ....
HERE IS WHAT I AM LOOKING TO DO:
I HAVE ABOUT 25 GUYS "IN THE FIELD" I WANT TO EQUIP THEM WITH MOBILE POCKET PC'S POSSIBLY WITH BLUETOOTH FOR GPS.
I HAVE LOOKED AT AUDIOVOX THERAS AND THE HP IPAQ.
BASICALLY I WANT THEM TO HAVE A "WIRELESS APPLICATION" FOR THEIR POCKET PC THAT COMMUNICATES WITH A DATABASE AT OUR OFFICE. THE DEVICE WILL NOT BE USED AS A PHONE!!!
THE APPLICATION WOULD: CAPTURE GPS COORDINATES AND SEND THEM TO OUR DATABASE EVERY FEW MINUTES OR SO /// PROVIDE US WITH CUSTOMER REFERENCE NUMBERS /// HAVE SIGNATURE CAPTURE /// ABLE TO USE A BARCODE ASSECCERY
I WANT AN ALWAYS-ON CONNECTION. VERIZON'S EXPRESS NETWORK SEEMS YOU HAVE TO "DIAL IN" TO CONNECT. NEXTEL PHONES SEEM TO HAVE PACKET DATA THAT DOES NOT SEEM TO REQUIRE "DIALING IN"
I AM FAMILIAR WITH VISUAL BASIC, BUT I HAVE HEARD A LOT ABOUT J2ME, BUT I AM NOT FAMILIAR WITH OBJECT ORIENTATED PROGRAMMING, SO I WOULD PREFER TO DEVELOP THE APPLICATION IN VISUAL BASIC. I HAVE ALREADY ORDERED VISUAL STUDIO.NET 2003.
WOULD IT BE BETTER IN THE LONG RUN TO LEARN JAVA 2 AND J2ME?? WHAT WOULD BE A GOOD DATABASE THAT WOULD COMMUNICATE WITH THESE POCKET PC'S?
AM I MISSING SOMETHING HERE???
|
Answer : 3G CDMA VS GPRS 500 PTS
|
|
Okay Daler...You have a lot of questions here...I'll try my best to address each individual one first:
- First, choose a solution based on your needs, not on the technology...for example you may not need a Bluetooth to GPS connection...
- It seems your application needs to run on a mobile device, capture some data (including GPS coords) and "upload"/"sync" them back to your central office DB. Both Palm and PocketPC's are able to run applications such as these and use wireless connectivity for data syncing. Deciding between the two may also depend on the variety of features you may want your users to have access to.
- Developing an application of this sort on Palm can be done in a variety of ways, with C or with C++ or even VB (via a 3rd party engine, Appforge). Developing this application on PocketPC can be done with Embedded VB, Embedded Visual C++, VB (via Appforge), and what Microsoft is pushing, a .NET-language (e.g. VB.Net, C#, etc). Using .NET for PocketPC is probably the way to go, but you will face some deployment issues, as you will have to install the .NET Compact Framework Runtime on your devices to support any .NET applications. Slowness of the app may also be an issue.
Java/J2ME can be done on both devices, but if your main objectives are ease of programming, code maintenance, Microsoft support, and only targeting PocketPC, then just go with VB.NET, which is the long-term path for Microsoft-based products.
- Your device will have to have wireless connecvity. Look for a device with built-in wide-area network connectivity (e.g. GPRS, CDMA 1xRTT). Examples include the Tungsten W (Palm w/ built in GPRS). On the PocketPC side, there are more options, but they tend to be ones which are Phone/PDA combos (Samsung, HP/Compaq, Toshiba) on GPRS networks (T-Mobile, AT&T).
You also mentioned using a barcode accessory... This could make things even more compilcated for the user, if they have to juggle all these accessories with their device.
Another device to look at is the Symbol's line of GPRS-enabled, Bar-code scanner-enabled ruggedized PocketPC's (http://www.symbol.com/products/mobile_computers/mobile_pdt8000.html). These seem to match your requirements, other than the GPS aspect of it.
To get your locations coordinates, there are two approaches: One is GPS, which is satellite based. There are a variety of add-on's for GPS for both Palm and PocketPC. THe problem is, will these add-on's (Garmin, Magellan) work with your chosen device? These add-on's are usually form-fitted for certain devices, which makes this whole thing pretty challenging.
The other approach is network-based. Your coords can be obtained through your wireless provider network, that is, if your wireless PDA is using connectivity via Sprint, T-Mobile, AT&T, they may provide access to your location information via some approved interface. A specific API may be offered to developers to access this information programmatically through your application.
Whew. This is a lot of information and I'm sure it's very confusing. There's a lot to sort out and it seems you may have to approach your solution in a carefully planned and phased implementation.
If you have any more questions, please feel free to contact me at [email protected]. You can also find out more about us at http://www.rjbcomputersinc.com if you're interested in finding out more about how we could possibly develop a solution for you.
Good luck!
|
|
|
|