Hi Victor,



Thanks for the information I will check it out.







Agree and like the idea, this way, it would also be easier to use different devices.

Edhy Rijo

if you want to do all the legwork in asp.net then you could try using the Wavelink Industrial Browser.



http://www.wavelink.com/products/ibrowser.aspx



I have had success using this with Motorola MC3090 handheld guns. The browser lets you access a lot of the handheld features, scanning, battery life, wifi signal, etc...



using a webserver approach also eliminates having to deploy changes to all the handheld units.

Thanks Bill!

Edhy Rijo

The model that we have is the MC9090. Our devices are definitely running Windows CE rather than Windows Mobile. I doubt there is a significant enough difference between the two development environments to discourage you from one or the other. Have fun!

Hi Bill,



Thanks for the suggestion, I will look at the CE to see some sample code. all the Symbol/Motorola devices I see in the web support MS Windows Mobile 6.1 which I believe should be the OS I need to use CE, right?



What device model did you use?

Edhy Rijo

You can try the ASP.NET way, but there are complications there that I believe are unnecessary. There is enough power in the CE .NET components to provide all of the data manipulation that you will need on the Symbol device. I'd highly suggest you spend your time in the ADO.NET code to do the mobile apps data work. I never needed any special device SDK in order to make the little app to work. For the scanning capability I leaned on DataWedge to initialize the laser for me when the device was booted. That way I do not have to integrate any kind of SDK to manage the scanning functions. Ya...I was a little lazy, but it sure took out a ton of complications.



Bill

Hi guys,



Thanks to all for responding, much appreciated.



I am looking at Symbol devices. The plan is to do some ASP.Net application, but don't know yet how to handle the capture of the signature or if that can be done from a web application, otherwise I would have to look at the specific device SDK to try to create a simple app to read the database via WIFI.



I will post more info once I get into the device specs and prices.

Edhy Rijo

I would have to echo just about everyone else's comments here: Keep your requirements as simple and finite as possible, and manage what devices and (more importantly) platforms you are going to support as much as possible (ideally just one.) 

I had a quick conversation with Trent regarding what it would take to leverage StrataFrame on those mobile platforms, and the short of it is that providing a mobile platform solution isn't something that is on the drawing board right now. You may be able to refer to and (to some degree) port very specific pieces of the SF source over to the compact framework without too much massaging or re-working, so if you are looking for a leg-up on some specific core aspects of your mobile app that may be an option. If you are looking for full BO, data layer, etc support just like you have in winforms, however, then I'm afraid you aren't going to find what you are looking for there.

For what it's worth, we used to develop and support a full-featured app on PocketPCs. By the end of the development cycle, we were able to almost completely mirror our charting and perscription writing components, albeit in a dumbed down version. You can do some impressive things on those platforms if you are dedicated to them, it just takes about 4 times as long to develop and maintain .

It appears that MonoTouch (beta?) is limited to iApple devices only. I'll keep this in mind once we start using the iPads at the loading docks.



We have four Symbol devices in two different plants that do exactly what Keith mentioned: "do as little as possible and get the heck out". These devices do things like inventory control, quality checks, picking ticket fulfillment, material label printing, packing list processing, etc. The interface is boring, but pragmatic.



The differences between WM, PPC and CE (and others...sigh) will demand slightly different code bases. Definitely keep that in mind as you consider implementation and device selection.

I came to the same conclusion as Bill. We have an application that run on mobile devices and sync inventory as it is pulled off the shelves in an inventory management system. It is vanilla .NET

If you have a Symbol (now Motorola) device you will be using their SDK. The Compact Framework is limited in what it can do and it a subset of the same version of the .NET framework, as such I try to do as little as possible actually on the devices, also since memory will be limited it is another reason to use vanilla CF, do as little as ppssible and get the heck out

Yoru biggest choice might be platform, CE versus Windows Mobile, versus embedded. We used CE because it was more "powerful" but it has since fallen out of favor a bit with WM taking frontstage. Targeting different platforms can require code changes.

Hopefully you have the ability to provide the devices or dictate which are used.

Keith Chisarik