Fog Creek Software
Discussion Board




Development for Handheld device

I work for a large retail company, and we are beginning work on porting our POS applicaiton to a handheld device to make a mobile Point of Sale that can accept credit cards.  We are still in some of the planning stages with this and I was wondering if anyone else has had experience with this. 
Our plan right now is to use Pocket PC 2002 and porting out app (written in c++) to embedded c++.  But for all new development on these devices, I wanted to go with .Net.
Is anyone else doing retail applications on handheld devices?  What OS are you using? What are you writing it in? 
Also, before we can use .Net we have to evaluate all other possibilities on this device (Embedded c++, Java, etc).  What has been your experience using these languages?  Would you use it again? Why or Why not?

Thanks for any input.

Matt Watson
Friday, April 25, 2003

My main recommendation: develop a solid specification for your handheld device and evaluate the market, because you'd be amazed at what *isn't* available.

Philo

Philo
Friday, April 25, 2003

We have been using Embedded C++ v3.0 (also working with v4.0), with MFC (without the wizards), to develop a modile point of sale system.

There are a number of MFC classes that are missing, but nothing important. There are also different problems with different platforms/handware that may need to be looked at. One big problem we have found is that by the time you have finished creating your system, the hardware has moved on.

We looked at using Win32, but this was too complex to support later on, using VB, but this was a joke, using .Net, but not all hardware supported it and using java, but again not all hardware supported it.

If you ask me it would be best to use Embedded C++ with MFC. People know MFC and will do in the future too.

Stephen.

Stephen Hassall
Friday, April 25, 2003

It might be worthwhile to port it to the .NET Compact Framework which was recently released with Visual Studio .NET 2003.

I messed around with a minimal proof of concept (restaurant POS) client app using the .NET CF (in beta form) - I have to say I was impressed with how much of the .NET Framework is included in the Compact edition.  If you're going to port it to the PocketPC platform, I wouldn't use anything but the .NET CF unless porting your application to Embedded C++ is an easy/straight forward thing.

GiorgioG
Friday, April 25, 2003

If it's a commercial application, I would recommend C++ using straight Win32.

This gives you maximum flexibility, and performance, and keeps you protected from various implementation bugs in libraries built above that, such as MFC and eVB.

Net CF I see as being more for in-house developers at this stage. 

.
Friday, April 25, 2003

And by the way, don't even think about Java.

.
Friday, April 25, 2003

We develop (eVC 3.0) for Pocket PC 2002 devices using pure Win32.  We do data acquisition and size and speed are necessary.  While Win32 is more maintenance, it is more flexible and portable to future devices.  It also doesn't have as many dependencies as MFC or .NET stuff.  A consideration for the future (once .NET is everywhere) might be to switch to C#.  But its too early to tell yet.  And Win32 will always be around.

sedwo
Friday, April 25, 2003

One of the problems we are facing is that our organization is trying to go purely java and we are getting blasted for wanting to use anything else on the device.  They think that Java is right in all situations no questions asked.  How can I convince them that Java is not the best option in this case?

Matt Watson
Friday, April 25, 2003

>How can I convince them that Java is not the best option in this case?

Make a business case for it.

"If we use java for [Insert Project Name], we can do everything you want but it will take X number of months or years, which in turn will cost Y dollars.  Using [Insert Platform], it would cost y1 and have it done in x1 time.  As a result of using [Insert Platform], we would save X-x1 time, and Y-y1 dollars."

GiorgioG
Friday, April 25, 2003

I have been working at LinksPoint (http://linkspoint.com) for over a year and a half now.  We have been using embedded visual C++ WITH MFC for all our handheld applications (I have worked on 3 in my time there).  One of the applications is called Starcaddy (http://starcaddy.com).  This is a shrink-wrapped, consumer application that allows you to determine distances on a golf course.

I bring this up because I read these arguments against MFC and using straight win32: "we need it to be more flexible and portable to future devices" or "it is more flexible (twice I read this)" or "it protects you from bugs in the library".

Could someone tell me what they mean by it being more "flexible"?  Where exactly does using MFC here make it not flexible?

As for other devices, StarCaddy was tested on numerous devices before it shipped.  Also, since it has been released, it has been tested on many, many, many PDA's.  Not once did I ever hear a customer support issue of this type: "darn it! because we used MFC instead of Win32 it won't work now!!!" :)

As for bugs, I never once got into a situation where we couldn't develop a portion of the application because "MFC got in the way".

My personal opinion is that embedded VC++ WITH MFC is the way to go.  I've worked on multiple applications with it and my co-workers have worked on multiple applications using this technology.  My company in the past couple of years has developed many custome applications and products using eVC with MFC.  It works just fine.  And there is no need to increase your development and maintencance costs because of some MFC-bugaboo.

Then again, I could be dead wrong.  I'm willing to listen to all detailed arguments against it.  I have just seen what my company has been doing for the past couple of years, so the proof is in the pudding.

As for embedded Visual Basic.  Don't waste your time.  I'm not saying this because I have some VB bias.  My company did look into using eVB to create StarCaddy and it was determined that it could not do the job.  On top of that, I've heard through other handheld developers (we have a GPS API so we are in contact often) that it just can't get the job done.  I don't know the specifics, I just know that it isn't a good idea.

Java is slow and a bad idea also.  Trust me, don't get involved with Java for the handheld.

.NET we have been looking into it.  But it is just too early to think about developing with it.  For us anyway.  Because the .NET compact framework is not part of the OS, that's something that we would have to ship as part of our application.  And because we are shipping it and installing it on their PDA ... we then have to support it.  Not microsft -- us.  Angry customer, "That stuff you had us put on our PDA caues bad things to happen!".  Us, "Well, it's .NET what can we do?".  Angry customer, "I don't know...but you better fix it!!!"  I wish I could remember some of the other issues that were discussed at this meeting we had on the exact topic.  I'll have to bring this subject up again .. but maybe there were some bug issues or memory issues or something.  I forget.  But it's just not a good idea, right now, to use .NET.  But we do have our eye on it.

William C
Friday, April 25, 2003

One other point, the original poster said that the app they wanted to port was written in C++.  Was this C++ using Win32?  using MFC?

If it was written in MFC, this is more of a reason to use eVC with MFC.  When we were developing StarCaddy, we kept a simultaneous Windows version that we would run through boundschecker.  Because embedded MFC is a stripped down windows MFC, the app that was developed on the handheld pretty much just compiled in a regular Windows Visual Studio project.  We would just change the dialogs for the Windows app (make them bigger, prettier, etc.)

So, the move from a MFC app to an embedded MFC app would most likely make your life easier.

William C
Friday, April 25, 2003

Nice to see a unified coherent strategery is being adoopted by the MSFT camp. 

Rock on.

Nat Ersoz
Friday, April 25, 2003

Nat,

I'm not being fecetious.  I'm serious when I say that your comment went way over my head.  Could you explain the point you were trying to make in a little more detail?

William C
Friday, April 25, 2003

"We have been using Embedded C++ v3.0 (also working with v4.0), with MFC (without the wizards)..."

"If it's a commercial application, I would recommend C++ using straight Win32."

"We have been using embedded visual C++ WITH MFC..."

"It might be worthwhile to port it to the .NET Compact Framework which was recently released with Visual Studio .NET 2003."

"We looked at using Win32, but this was too complex to support later on, using VB, but this was a joke, using .Net, but not all hardware supported it and using java, but again not all hardware supported it."

Basically, its great to have many different ways of doing something.  Like second and third sourcing hardware, always a good idea.  Its another thing to have the anvil of discontinued support hanging over your head after you've made your choice.

Nat Ersoz
Friday, April 25, 2003

I've been porting C++ code to Pocket PC 2000/2002/2003 and Windows CE.NET 4.x for a couple years. The only Win32 porting problems we had on Pocket PC were a few missing features (mostly some uncommon ActiveX interfaces to Pocket IE). eVC is not a adequate but not great dev environment. You can do most of your dev work with the Pocket PC emulator on your desktop PC. It's very close to the real Pocket PC.

As a disciple of Joel On Software ;-) I would strongly recommend that you do not rewrite your existing C++ application. Do not rewrite it using Java, eVB, or .NET. You have lots of tested C++ code and that is a huge running start.

Porting it to Pocket PC won't be that difficult. The hardest part will be adapting your exiting GUI to Pocket PC APIs, but you should probably rethink your app's UI for the Pocket PC form factor anyways.

Good luck!

runtime
Friday, April 25, 2003

William,

My definition of "flexible" regarding the use of Win32 is mostly due to the level of control you attain with it.  Its the "assembly language of windows" as I've heard it called.  And while MFC is a viable choice, it does abstract the developer from some of the underlying layers.  And all the better if your purpose does not require it.  But aside from the possible digression of using the "right tool for the job", IMHO Win32 seems to remain more tolerant of change then those libraries built on top of it.  I view the Pocket PC platform as an embedded system, and hence focus on issues regarding size, speed, and dependancies.  To distribute an MFC application, you also need to package its dependant DLL's and such. The .NET CF is even worse.  Pure Win32, just the executable.  Which makes it all the better for wireless GPRS distribution, since its so damn slow.

Either way, whatever route is chosen to develop in, you will soon enough discover its limitations and either modify your design, or modify your tool.

sedwo
Friday, April 25, 2003

The problem with eVB is that it's basically VB Script. It doesn't provide compile time type checking and doesn't support classes. Nuff said.

It can be slow-ish in displaying forms and it's iffy in keeping up to date with the UI changes that are happening in Pocket PC. MFC might also suffer this, although I take on board the MFC enthusiast's points. If it works for him, OK.

One thing eVB is good for is quick data entry apps, because it works well with ADOCE ( cut down ADO.) However ADOCE has its own set of signficant bugs.

SQL Server for CE is the direction for data access on Pocket PC. For corporate developers interested in VB, VB.NET is the way to go.

.
Friday, April 25, 2003

I've done MIDP Java apps for motorcycle couriers using the Motorola Accompli 008 (because it has a touch screen you can even capture a signature on delivery etc).

More recently I've been playing with programming the Sony Ericsson P800 smartphone, using C++.  Symbian has a very very well-thought-out C++ framework.

The world isn't Microsoft.  Just much of it.

Nice
Saturday, April 26, 2003

"How can I convince them that Java is not the best option in this case?"

How did you convince yourself? Bingo, you just answered your own question.


Monday, April 28, 2003

I've been working with both Java and .NET CF (C#) for the last 3 months. Assuming you don't have expertise in either language, productivity is pretty much the same, unless you are creating a Web Services client, that is just as easy in the CF as in the regular .NET Framework. By the way, don't count on visual editors when scheduling. Sooner than you think, you'll be writing and tweaking UI code by hand.

In terms of performance, both are *way* slower than eVC. A good Java VM is a must if you end up with Java, a good JVM can be as fast the CLR, while bad JVMs are more like 5x slower.

Marcos Rubinelli
Monday, April 28, 2003

I almost forgot: no matter what you choose, integration with device drivers will be really painful.

Marcos Rubinelli
Monday, April 28, 2003

Hello guys,

    I am not sure this dicussion is still going on.
    Me I was evaluating SuperWaba (a java VM), does anyone has experience with it?... I am planning to create a GPS application (no maps... but yes.. some graphics involved... and specially connectivity towards serial connections and IP).

    Do you think Superwaba could be a good option?... as targetted platform we have both Palm OS and Pocket PC... but we are not sure how difficult would be to port to each one...

  With Superwaba, it seems not much of a hassle to port them.... but not sure someone has experience on this one...


  Would people recommend me to go to the .Net Compact Framework?

  thanks for your comments...

Gustavo Lopez
Friday, February 06, 2004

If you like to take a look at a real cool device, please go to www.orderman.us - this is a firmware based thin client with a touchscreen, 2.5 times the size of a PALM. It does not require dealing with drivers etc. as it is a wireless "Visual Display Unit with a keyboard". It communicates via  902 - 908 MHZ RF which has a better range than 802.11 and uses 1/10 of the power.

Presently it is integrated with 150 POS applications world wide. Main use is restaurant POS.

Bernie Schwentick
Sunday, February 15, 2004

*  Recent Topics

*  Fog Creek Home