New to mobile dev, need some recommendation to get started.

[FunkyDexter]

Hi All

Some of these questions (actually, probably all of them) are going to be a bit vague and I'm really only after pointers and recommendations rather than exact answers. Also, if I'm asking the wrong questions please feel free to slap me upside the head and let me know.

We have an ERP system that's desktop based. it covers everything: Marketing, Order Processing, Customer Service, Manufacturing and Delivery. At the moment we have surveyors who visit customers for appointments, take down their details (primarily conservatory dimensions - we sell blinds). At present they fill out paper forms which are then input into our system by admins. We would like to allow the surveyors to enter data direct into some kind of moblie device. So here come the questions:-

1. How tightly should we be specifying the device the surveyors will use? I did a bit of java mobile phone development a few years back and the whole thing quickly turned in to a mess of complier asserts. Initially we can supply devices but our surveyors are self employed so I can envisage that we might want them to be able to use their own devices in the future. How strict should we be?
2. Should we develop a fat client or should we use browser technology? I can see browser would give us some platform independence (particularly useful if surveyors use their own devices) but we're primarily a desktop team with a smattering of web skills so a fat client is more 'natural' to us.
3. How should we communicate with our DB? I kind of imagine we're best have a compact DB on each device and then synching it to the main DB on a nightly process or something like that. Is that the right aproach or could we communicate with the main DB live?
4. What other sneaky mouse traps await our toes in the dark? (yep, I've been playing Baldurs Gate 2 again)

[KMDcomp]

I've done several mobile projects over the last couple of years both for windows mobile and blackberry and I've learned that the very first question to ask yourself is, can the data needed be easily entered into a mobile device? Keep in mind how much typing will need to be done and where you can take advantage of drop down menus and such. Typing on a mobile device is a real time waster and I've found it faster to just hand out voice recorders for projects if more than a few words need to be typed out for each submission.

Given that my job doesn’t require a ton of programming on a monthly basis (sometimes, 2 or 3 weeks will go by where I don’t even touch programming) my programming skills are far behind most others on this site, so take this for what it’s worth. I've found it easiest to just create a simple no frills web page using ASP.NET that stores to an SQL server if I need to use it on multiple platforms. The down side is that the application feels sluggish while it waits for page loads and while transmitting data. If it will only be used on a windows device, I like the extra performance I can get by using a standalone app built in VB.NET and SQL mobile server; then you do a bulk data transfer when you are ready either by plugging the device into a workstation or wirelessly.

[petevick]

Hi,
my 2 cents
1) Strict specs are always better in the long run - no scope for arguments.
2) Up to you - browser depends on connectivity. 'Fat' client using SqlMobile and replication allows for offline collection, and connecting when needed.
3) SqlMobile on the device and Replication or the newer SynchServices to exchange information.
4) Tight spec, decent comms, standard components - it's a breeze

Pete

[FunkyDexter]

Thanks for the feedback, Guys.

On whether the data is suitable to enter into a mobile device, I'd say yes. It's basically a repetitive series of measurements so I think we could walk them through a sort of wizard with minimal entry on each screen quite easily. That and the data tends to be numeric.

What's the deal with communicating direct via an ASP page? Does this involve the device making a call? (BTW, I still don't own a mobile phone myself so I'm a complete Luddite where knowing this stuff is concerned).

How easy are the synching services to set up? To be honest we could probably write a program ourselves to handle it but if the synching services make that process easier, so much the better.

[KMDcomp]

What I've done a couple times for some survey data we needed to collect is build a simple set of ASP.NET pages (hosted on a web server in our DMZ) that can be accessed through a PDA's web browser and using VB.NET classes (that I had already written for a fat desktop app) to verify and store the data into an SQL server. This requires some kind of data service for the phone. Since the pages don't have any large images or complex configurations they load fairly quickly, but not as fast as a fat app would. When the next button on each page is pressed, the data is transmitted and stored on the server. Using this approach, I can usually turn something out in a day or two if I don't get interrupted too often .

The other benefit is that our surveyors don't have to come in to get their devices loaded or updated, I just email them the address and they are off.

If they don't have a data plan (this is where those mousetraps you mentioned come into play), then you are going to have to store data temporally on the device and making it device independent is much more difficult. If you use java, be prepared for some variation between java ME support on different devices, they don't always support all the features of the language and many replace java ME classes and functions with their own APIs. Some phone features may be locked down and require extra steps (such as signing your code with a key given or bought from the phones service provider) to access which can cause you more headaches trying to support the multiple operating systems on different phones.

IMHO, it would easier and cheaper in the long run to just buy up some used Windows PDA's and issue them to your guys then to try and support multiple brands of phones. Or you could make owning a smart device with a data plan a condition of doing business with you, whatever works!