Java Programming

EPoS systems are just PCs. As such, you can install a JRE on it provided one exists for whatever OS is installed. There's nothing specific to EPoS about this. Touch screens tend to plug in as mice anyway, although you'll probably need a driver specific to the touch screen. No reason why it won't be shipped with the screen itself. Yes, it will really work as easily as you hope, with dragging on the screen being mouse movements, and tapping being mouse clicks. You don't need to write any code specifically to capture touch-screen input.

Question is, though, have you got an EPoS till? They ain't cheap, unless you can pick one up on Ebay from bankrupt stock or something. Even then, the price compared to an equivalent-powered PC is high. Touch screens aren't cheap either.

For a rough guide to the actual cost, every time we buy a PoS for testing on, the same as we have in-store, it costs about £2k, with the box itself, a touch screen, a cash drawer, receipt printer and barcode scanner.

I don't but read below my thoughts.
For this you will have to talk the manufacturer(s) of those systems. I doubt they agreed to a standard way. Some may run a version of Microsoft Windows, some may run a proprietary OS.
I can't say, you have to check the functionalities it has.
There you have the manufacturers info. If you're serious about making software for these, go ahead and collect data from various makers.

Thanks for the excellent answer. You've helped settle some worries further down the line. Yeh, as you mentioned the issue is testing, as it's quite hard to get your hands on an EPOS system for testing.

I suppose the main issue then is GUI design with consideration given to the size of peoples fingers.

Thanks.

All depends on the background. I have no idea what you're actually doing, whether this is software you've written, if so who are you planning to sell it to, or anything. You said you don't intend to use cash drawers, or take cards, so I'm baffled as to what will actually go on in this PoS system

I can think of some - tourist information or local area map kiosks etc.

Some what? If no money is changing hands, no sale needs to be recorded. All that's needed is stock control

It's actually a table booking system for a restaurant so customers ring up and the employee inputs their details into the EPOS the EPOS application notifies them when the customer is arriving amongst other things. Typically it could be used with a laptop but as the main port of call for a restaurant will be an EPOS system it would be useful for it to be integrated on an EPOS system as I doubt they will have a laptop handy in the main restaurant area.

Why EPoS?
Why EPoS?
Why would it?
That's a completely different question to what you asked. If you think you're going to be able to just dump a jar on a till, and have your app magically integrate with whatever POS system the customer is using, you're in for a big shock. Seriously, ask about what you're actually trying to do rather than random wild mad guessing about something that may or may not be relevant in the future. Depending on what EPoS system the restaurant is using, this will vary in difficulty from fairly hard to outright impossible. Your first question should be "can I integrate my own code with this EPoS software?" and of course, there's no point asking that here.

Because the main port-of-call for employees of a restaurant is an EPoS system rather than a desktop or laptop.

> Because they won't want to be notified of a customer arrival when they're sat at home eating doughnuts. They need to know when the customer arrives whilst in the restaurant, the main port-of-call for the employee of a restaurant will be the EPoS system.

> It may well be the case that the restaurant has a laptop in the restaurant, good point, but it's far more likely that they'll have an EPoS system.

> Are you saying that the cross-compatibility of a Java application will not run on differing EPoS systems or are you saying the system will be hard to integrate with existing PoS software? I don't intend to integrate the software with existing software at all - I can see that being very hard. I intend to integrate the software separately as it's own application. Am I misunderstanding something here; is there a piece of PoS software which takes over the computer and only allows EPoS based functionality or is it seen as bad practice for EPoS users to switch between applications?

Thanks for the help. I'd ask elsewhere but as I said; it was hard to find forums dedicated to EPoS programming let alone JavaPoS.

I thought it was a table. I'm not being facetious, either.

>> You talk as if the maitre'd spends all his time hovering about a computer. He doesn't.

>> It may well be they have nothing but a PDQ behind the bar.
Both.
Ah. I mistakenly thought you did want to do that, after you said "it would be useful for it to be integrated on an EPOS system".
Launched how? These people are restaurant staff. They don't want to be closing down full-screen apps, switching screens, opening up other apps and what-not. They're trying to feed people and earn tips.
Most PoS software runs as a full-screen application. It is bad practice for users to have to switch between applications, or indeed to be aware that they're using an application at all. The idea is, we use old-fashioned push-button cash registers as the UI metaphor, because that's what people know how to use. Once you introduce steps like "now close this application down, find a mouse and click twice on this icon" you're into the arena of them saying "we don't bother using that because it's too complicated and time consuming. We just write it down on this bit of paper". That is, if closing down the app, or minimizing it, is even an option. It often isn't.
I know it is. I'm from a PoS background, and the arena you're entering is a bit of a minefield. Basically, if I've understood you right, you hope to piggy-back some booking application on some PoS hardware that's already running PoS software. Forget it. Not going to happen, unless you get in bed with the PoS vendor. If this is an actual venture you've got in mind, rather than just a toy project, don't even bother writing any code just yet. Find out whether there's a market for it - there probably is - and then, more importantly, find out if someone else is already doing it. They probably are, and they're probably already selling PoS systems to that sector. For most verticalised PoS applications, you'll find a specialist vendor that tailors solutions to suit a certain market sector. The hospitality sector is a biggie. Seen those Chip 'N' Pin devices waiters carry to tables? Whole companies exist solely to sell that solution. There are companies that specialise in selling PoS systems to football clubs, theatres, garages, chemists, you name it. Whatever great idea you think you've come up with, your first step is to find out if someone else already does it. I know it sounds like I'm trying to put you off, but really I just don't want you to waste time. I'm happy to answer your questions of course, but the answers will be grounded in what I know of the PoS market already.

What I mean there is if someone rings the restaurant's phone, the nearest computer and hence access point to the application will be the EPoS system.
Yes I understand that, notifying the restaurant is not a major part of the app, it was more of a feature which crept in which doesn't necessarily need to be there.
Agreed and hence this application would not be a good solution for them.
This is all interesting and new to me, surely what they need is an OS (a very basic OS mind you) tailored directly for EPoS machines. This OS could allow users to easily install and switch between full-screen applications using a permanent menu. Either way, from what I've got from you it seems that whoever gets their software deployed on the machine first wins. If the user wants to get additional functionality they must either have to stop using the current app and use a different one or redevelop the current one which seems odd.

My system as you probably understand does not need an EPoS machine, I'd like it to work on an EPoS machine as it would increase the user-base and I'm sure I can get it to do that but this full-screen, app-switching business seems a bit off-putting. Thanks again.

Nah. They tend to run Windows or a Linux.
You don't need an OS to do this. Just a neatly extensible application framework.
Other way round. The restaurant needs a machine to be a PoS. So they get one. That's what it's for. It's not like they install a dozen general-purpose computers at strategic points around the building.
Why does it seem odd? Why would they keep needing new functionality that's orthogonal to what they already have?
I don't think it would increase the user base at all, to be honest. Tell you what a nice platform to target would be: smartphones and hand-held devices. They're increasingly popular in jobs where people are on the move a lot. So write your app so it runs on, say, a Symbian 60 platform, and go from there.

Have you actually ascertained that booking-in functionality is lacking in restaurants? A paper-based system works perfectly well. Especially if tables are being booked over the phone. Someone who's very busy, running around serving people, can hold a phone in one hand and write a name, time and number of people coming on a piece of paper, a lot easier than they can bring up an application, switch to another one, and type in all these details on a keyboard. Experiment with it. Time yourself writing "Alex P 4@8:30" on a piece of paper, then time yourself - using one hand - opening up Notepad, and typing the same details in. Then time yourself walking across the room to answer the phone, and doing the same things.