I'm trying my hand in the food industry. I'm going to be developing my epos system in house. All the fancy touch screen systems cost an arm and a leg. I was wondering what are my options if I wanted to integrate a chip and pin device as well? Could I use something like paypal? I doubt supermarkets use such a system though.
Have you considered Openbravo POS? It's great for a basic EPOS system, and has features such as Restaurant Mode (tables etc), as well as reporting facilities etc. It's also free :-)
If you want to use Chip & Pin though, you'll need to write a custom Java module to compile into Openbravo, to link between whatever software your C&P device provides, and Openbravo itself. I've done this for a custom Openbravo installation, but it is specific to the C&P device provider.
PayPal is an online web payment service provider - this is different to the hardware-based C&P.
Edit you're probably also better off talking to your bank about their options regarding C&P - they may be able to offer you such a service, or recommend a partner to lease you the hardware and provide support etc.
Ocius for PC, is a pre-approved chip and pin solution from Commidea, which you can integrate with your software. You will need to have your integration tested by Commidea before you can deploy to any live sites.
Changing your software to work with Ocius should take a few days of coding and testing.
YESpay also offer chip and pin solutions, but I have no experience with them.
I would suggest ERPLY POS , its also free, usable over WWW and its really nice UI
Related
I plan to go with the free version in order to promote the paid version.
Few questions:
In your experience, is it helps?
After a user has installed the free version, if he wants to install the paid version,
he needs to remove the free version first ?
how it effects downloads rates ?
What is the correct way to do it?
After some research for one of my applications, I have found the following options:
1 - Have all your code in one big library then make two applications using this shared library and have them toggle some flag saying the application is in trial or full mode.
To me, not very nice, because you'll need to handle the fact that the user can have both the free and full applications installed, when the users gets the full application, you'll need to move his data from the trial version to the full version (databases cannot be shared easily)
2 - Have one single application that can be unlocked by buying a code on a particular website
Good thing is you can provide alternate payment options (paypal, ...) and also avoid being limited to the Android Market. Can be nice when dealing with countries that don't have access to it.
3 - Have a single application with all the code plus one small unlock application to unlock the free application limitations
Good thing is you just need to update the free application and all users will get bug corrections. You also take advantage of the Android Market. Downside, is that your users need access to the market to get the full application.
I have personally chosen option 3 but I will add on top of it the option 2 because I intend to distribute my application on countries/devices that do not have access to Android Market
Edit 2/2/2011: I have published an article about that on our website. Your can read it there: http://www.marvinlabs.com/2011/01/sharing-code-full-lite-versions-application/
It's always a good idea to provide a demo (assuming there is incentive to buy the paid version, like a time trial, feature cripple, whatever is best to demonstrate the app without ruining the experience).
Add two versions of your app to the market, one free, one paid.
No, since they're two separate apps, but it would make sense to remove the free one in order to not have two apps installed.
They're two separate apps, so they have two separate counts.
As an alternative, you could use a keyfile to unlock the features of the full version. If you do that, you should probably use Google Checkout for processing (all "fees" must go through Google's processing as per the TOS, IIRC). There's a lot more involved if you go this route (especially coming up with a keyfile system that cannot be easily hacked).
How do you weight the pros and cons between a Midlet and Browser based client/server app for a phone ...
What are the pros and cons of both...
And based on your experience what will you prefer to go in for and why?
I have listed some points based on which we can compare both feel free to add your own...
Rapid development.
Rich UI.
Mild data transfer between client and server.
Ease of use.
Portability.
Wide phone target audience.
Here's a great blog post tackling this exact issue. I used to work with the poster and know he's spent a significant amount of time on both sides of the fence, mobile app development and mobile web development, to have a well formed opinion on the subject.
APPropos? Are native mobile apps as supportable as mobile web apps?
I myself have only worked on the mobile apps side of things and there really isn't anything rapid or portable about the process, especially when your target platform is...all of them. However, mobile web apps will of course not allow you to supply as robust a feature set as a native app. It's all about trade-offs and concessions in the general mobile space at this time, and I think your taking the right approach to figuring out what is more important to your project.
The general answer is: It depends. Without knowledge of the goal, is it hard to suggest the road to it.
What type of application are you going to make?
What is most important? Performance or rapid development? Which features do you need? Database, inter-client communications? Do you need specific UI-elements, which is hard to create on a webpage? Do you need it to be portable? Which devices do you want to target? And a lot more questions...
My friend and I are planning to build a simple chat client to let people in a (physical, real world) room chat with each other (people chatting over the same wifi network, possibly pinging some external server to organize things by the external IP address of the wifi network). Partly we planned this as a chance to play around with Groovy, which we haven't done much with. But then I thought - damn, how many people have the Java 1.5 runtime? Maybe this is kind of thing where Flash would be better (when I say "Flash" I mean "Flex")? I hate ActionScript and I have very little experience with it, and I've no real interest in using it, but I'm thinking, if we want 9 out of 10 of our friends to be able to use our software, Java is possibly not the way to go?
My concern is in particular with the demographic we have in mind, which will tend to be freelancers and artists and individuals, rather than people at work. I'm aware that Java still has a decent overall market share, but I'm under the impression that its use is heavily concentrated in the computers that people use at work. Folks who don't work at corporations may not have a modern runtime?
I then decided to look up Java market share. It is surprisingly hard to track down info about specific JREs.
There was this on stackOverflow, but its focus is on RIAs, which isn't what I'm talking about:
What's all this business about Flash, Flex, Adobe Air, Java FX and Silverlight?
And then conversations like this make it sound like Flash is the only reasonable choice to make if you want people to be able to use your software without jumping through a lot of hoops:
http://forums.java.net/jive/thread.jspa?messageID=317749&tstart=0
This seemed like a reasonable summary of Java versus Flash issues:
Client Java vs (Adobe) Flash for web applications, what to choose and when
I found it surprisingly hard to track down actual market share data on particular JREs. And I found no easy way to find out if folks who with modern JREs installed are mostly using their computers at work.
So I'm open to hearing some anecdotal information here. If we built our simple chat client in Groovy/Swing, would our target demographic be able to use it? Is Flash the only reliable way to go here?
If portability is your goal, why not go for a JS only approach, perhaps using one of the COMET styles of push? Here's an article to learn more:
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
If a JS RIA isn't what your after. Then Flash/Flex are your next best bet. I'm usually biased towards Java as a technology, but based on your target app and audience I think you'll get more joy using a Flash-based technology.
Adobe understand RIAs better than Sun, which was kinda demonstrated by some high profile Java 2D devs moving to Adobe in 2008/09. Plus with recent Flash Player developments you'll get your app onto more mobile devices.
Obviously server-side in Java ;-)
I have to design a new hardware with a uP (not determined yet) to run JavaME applications.
I've searched information about how do it, but for the moment it has been useless.
Can anyone explain how I can do it?
From what I found in my search:
- Using a uP (ARM for example) with an OS (ie: Linux) (using JIT for better performance)
- Using a uP with Jazelle. Do I have to use also an OS???
The application is an alarm control system, so it doesn't need graphical interface.
Minimal requirements are: ethernet port, 2 UARTs, SPI bus, I2C bus, min 16MB ram, min 4MB rom, IO ports.
Any suggest?
Regards,
Juanma
Since you are using JAVA application, I guess ARM926EJ (with Jazelle core) might be helpful.
What I am not sure is, why would you need a Java application for an alarm controller?
Anyway,
Step-1: Decide on the microcontroller
(ARM with Jazelle) seems to be a good
bet, considering the large number of
tool chains and eval boards already
available
Step-2: Based on your requirement
decide on an eval board from a
vendor. Most likely, the vendor will
also give you, the schematic, ported
embedded linux version with the
associated drivers
Step-3: On top of the embedded Linux
write your application
Step-4: Check the final RAM and ROM
size after you finish developing the
application
Step-5: Modify the schematics and
design your own hardware
This is normally how we develop embedded hardware ...
ARM's Jazelle page certainly implies that an underlying OS supporting Jazelle is needed. This HOW-TO article on embedded.com may help clarify things.
Good luck comes to mind. Embedded platforms can be a huge pain to develop from the ground up. Also most off-the-self micro controllers share their SPI bus with many devices making it only useful for quick short messages (don't plan on doing much else with the ethernet if you try to do webservices). I have not used any of the devices below but they looks like they might point you in the right direction.
http://www.systronix.com/
http://en.wikipedia.org/wiki/Sun_SPOT
http://www.is2t.com/en/index.php
http://www.parallax.com/tabid/517/List/0/CategoryID/13/Level/a/Default.aspx
Based on your question, here is what I believe are your requirements:
New embedded computer system
Runs Java Micro Edition applications
Question:
Do you know what Java ME configurations and profiles you need to support: CDC, CLDC, MIDP and to which version? (you say no GUI, so MIDP may not be required.)
Recommendations:
Don't try to develop your own PCB and software simultaneously. Find an embedded hardware system that has your needed peripherals and use that.
Preferably, find an embedded hardware system that comes with a royalty-free POSIX firmware layer.
Do NOT pursue Jazelle. It would be a lot of work for something you may not need. If you're running Java ME without MIDP, your performance will be satisfactory.
I've been asked to look into the development options for BlackBerry. My client wants to build an application that represents their brand. I realize that there are different techniques for doing development and the Java/J2ME approach is probably the most powerful.
Does anyone have experience with building branded applications, or have screenshots of BlackBerry applications that push the envelope in terms of user interface/experience?
I'd also like some feedback on the impact of the techniques in terms of experience. I'm sure there are various drawbacks to approaching an application from the branding angle, but I'd like to highlight these to my client.
The maker of PodTrapper (my favorite BlackBerry app), posted a great writeup on his experience here: http://www.versatilemonkey.com/story.html
One interesting thing I learned was that the framework actually makes you rewrite a lot of the display elements from scratch. So, yes, it's pretty easy to brand an app as your own (too easy).
I'm currently developing a blackberry application for my company. It's heavly branded (uses the company logo and colors from our cooperate identity). The blackberry api delivers many methods to display custom content. Personally, I see no problem in it.
Just set up a sample enviroment (it's free) and start developing.