I am working on a project where I need to send an amount to a credit card terminal such as verifone vx520 or Ingenico ict250.
If it was from Windows 10, would there be a way to communicate with the terminals to show an amount on the terminal screen?
(we are trying to avoid manual input on the terminal)
If it is not possible to send an amount to either verifone vx520 or Ingenico ict250, are there any other terminals that can accumplish this?
If so, it would be very helpful if you can also show me their API documents.
Thanks
The device you want to use is called CAT (Credit Authorization Terminal) in the UnifiedPOS specification.
Get the specification PDF from this page and refer to the specification from page 281.
Document -- retail/17-07-32 (UnifiedPOS Retail Peripheral Architecture, Version 1.14.1)
However, this device specification has been standardized at the request from the Japanese market and is likely not implemented in countries other than Japan.
Perhaps neither Verifone nor Ingenico provide control of CAT devices OPOS/POS for.NET/JavaPOS.
It seems that other vendors do not have it.
Vendors such as Verifone and Ingenico have their own developer sites and SDKs.
Also, vendors will have information on ISVs that use them to provide applications/solutions with the features you want.
Register to a site such as the following to get information on SDKs and applications/solutions.
Verifone Developper Central
Retail Solutions
Ingenico ePayments Developer hub
POS Solutions
While working, I'm always having problems related to data sharing.
For example:
I have a computer connected to the printer but my laptop is not and I want to print a file, how do I easily move that file to the printer computer?
How to share a file from my mobile to laptop?
What I'm doing right now is moving the file using a USB disk, e-mail address or facebook.
You as developers, what are you doing for such purposes?
What I do is using network because its fast and safe.
But if I have a good internet connection I would suggest you to use Ziggs.io - Smoothly Share Content Between Devices.
The bad fact about Ziggs is that you need an internet connection to use it.
What I like about it that you don’t have to register, you can share files up to 500 MB per file and they don’t store messages.
More about Ziggs from their website:
What is Ziggs?
Ziggs is a platform that exists to facilitate peoples communications
Ziggs is like a meeting point with your devices, it helps you to
transfer contents between these devices smoothly.
Drag-and-drop PDFs,
images, videos, APK apps and other files directly into Ziggs.
Messages
are delivered directly from your device to the connected clients.
Ziggs doesn't store any type of data and doesn't require your personal
information.
Ziggs uses smart solutions based on client-side to share channel conversation history with new clients.
Exists channel clients will act as seeds, helps new clients to follow up with the conversation.
I've built my own cloud for this exact function:
https://www.github.com/TheWlr9/LocalCloud
However, this question should've been posted on some forum page, and not Stack Exchange.
Is it possible for a mobile browser to send an SMS using the device's built-in capabilities?
By that I mean, NOT using some online SMS services provider but actually making the mobile device send the SMS (same you would do using J2ME).
There are lots of different mobile browsers out there, so I doubt that this is standardised. Safari/iPhone supports SMS URIs, which strikes me as a sensible approach to the problem and one that might be more widely supported than just the iPhone.
Based on the link (above) I found, and a comment from Zamel, I suspect this would work:
SMS
Although with a real phone number, and possibly escaping the + sign as %2B.
Some versions of the Opera Mini browser provide a javascript interface for authoring SMS messages to be sent from the user's phone.
Also, some versions of Nokia's Symbian browser include a javascript interface with similar functionality.
There might be others, but these are the only two I've found documentation for so far.
I think a GSM modem is capable of acting as a SMS Gateway but you have to have the software installed on the modem to do this. You might also look into the Carrier Gateway Emails to SMS as another option. Example is AT&T number#txt.att.net
There are a couple of free services popping up these days like ZeepMobile that you might also want to look into.
What exactly are you trying to accomplish?
No as a mobile browser is specifically built to render markup (html) documents. Therefore, if you wanted to send SMS via a mobile browser it would call a web server page and send from the server NOT the mobile browser.
Mobile OS and their applications have quite a lot of limitations. The closest you will see is the ability to hyperlink a phone # in a mobile browser to send a message but it will be handled via their SMS app not the browser.
Its not possible . You can call device functionality from browser . That is the way to go about it . Webkit lets you do it
Android and blackberry support
"mailto:" and "tel:".
Android supports "sms:" (and maybe iPhone, I don't have one :))
good luck and please post your result.
It's a good thing that is not possible. It would be quite a security risk IMHO. I imagine spammers would be all over it.
Recently I started developing a J2ME app prototype. I noticed how difficult it is to develop a good looking UI. Consider developing an app in J2ME for booking flights interacting with webservice.
A website to book flights will be easy to develop with nice ui and can be accessed by browser on a handset. I understand not all handsets have browser but all the new and upcoming ones have browser and have big screen as well.
Is it a good idea to develop such a application in j2me which need to talk to webservice for it to work? Or j2me is only suitable for standalone apps?
Advantages of J2ME:
Can access phone resources, like file system, phone book and GPS. The last is very important in map applications.
You can build richer User Interfaces. It may be difficult as you say, but there are many GUI libraries that could assist you. On the contrary the UI for a mobile browser (you can't rely on CSS and javascript working) would be very poor.
Greater flexibility on the communication logic. You can encrypt/decrypt data, compress them, use SOAP web services. With the browser, your best bet would be to develop REST services.
Disadvantages of J2ME:
Midlets need to be signed. This has some cost and there are situations that even a signed app won't run properly in specific phones.
Developing a midlet to run in all types of phones is a nightmare. On the contrary, a well designed mobile web application would be displayed properly in all recent phones.
You need to have a channel for distributing your application. People would need to download it and get charged for the required bandwidth. You would need to care for angry customers having problems with the application. Things are easier with a web site.
J2ME apps are inevitably compared with native applications (iPhone, Windows Mobile, Symbian). Compared to these, they are very poor and many would find that paying for them or even using them isn't justified.
My conclusion: Nowadays real smart phones are becoming more popular and win an ever growing market share. Under these circumstances, the advantages of J2ME can't really overcome its restrictions. The only exception I could think of, is if to have to develop a GPS application. For all other cases, a mobile web site is a better idea.
There are a lot of misunderstanding and plain wrong statements in the previous answers.
I advice you to just do your research yourself. Nowadays you CAN develop really good looking apps with J2ME without writing your own GUI framework. Take a look at LWUIT really. For example they have a virtual keyboard as one of their touch screen functionalities and this you have on devices like the N97 which itself does not have a Virtual keyboard. BTW using LWUIT you have a Blackberry and Android port included if anyone cares.
Also Apps nowadays become the center stage on many platforms not just the iPhone. Look at the recent developments in this area like OVI, RIM, Samsung, SE, Orange World they all start with app shops.
"Getting people to use a website on their mobile phone is easier than getting them to download an application." this is just a claim without proof. you cannot say that like this. It depends on a lot of other factors. - Why should users type in your mobile url into the rather small screen again?
Anyway, this answer is probably too late so I'm not gonna write much more. The mobile industry is changing fast right now but there is not yet a alternative to J2ME for crossplatform development. Maybe in the future with better browsers and widget technolgies.
Just a short note, applications like google maps or gmail mobile probably don't use WebServices to talk to their server part. A WebService has a lot of overhead, especially when considering that mobile users are usually rated by the amount of data they transmit. The best way to perform communication between your client app and its server part is to use binary data over a socket connection.
I personally think it's really hard to make a consistent and reliable J2ME application that will run across a large set of mobile phones. Based on my experience, I would only develop a J2ME application (instead of a Web application) if it's a strict requirement - for example, to be able to view your bookings without being connected to the network. There are other costs associated with J2ME applications - the applications must be downloaded, the user will be asked if the application is allowed to connect to the network when it attempts to (there are exceptions for this case but I believe the application has to be signed by 3rd party company - more $$$ involved), you will have to maintain different versions of the application running on a variety of mobile phones (more complexity to the application), and so on...
Think about it this way - if you were developing a similar thing for a computer, would you build a desktop application or a web application? With the cellphones of today (many of which can access full-html sites with javascript - which means ajax), the proposition of the question is valid.
I thing a good rule of thumb should be: If what you're trying to achieve can be done with a mobile website - go for the website.
IMHO, apps should only be used to if they cant take advantage of the mobile hardware - like location, sound, video, 3d, pictures etc...
Even if the dev costs for the app were insignificant (they usually aren't), you'd have to offer some really amazing capabilities to make the users go through the trouble of downloading it.
(All of this is essentially true for J2ME/BREW. The iPhone is a little different as apps take the center stage)
One thing worth highlighting: the only standard way of deploying a MIDlet is via OTA download so you wouldn't expect a J2ME-capable phone to not have a web browser.
Mobile web browser like Webkit and Opera are getting better faster than J2ME (at least until MIDP3.0 starts shipping, if ever).
No matter which platform you choose, you will need to test your service on many devices. I don't think switching from J2ME to webapp makes a huge difference in that regard, because phone manufacturers keep changing the binaries that go into the phones firmwares.
Getting people to use a website on their mobile phone is easier than getting them to download an application. unless that application is already installed when they buy the phone, that is.
You might want to look at LWUIT for better and easier J2ME GUI.
One thing that J2ME will accomplish for a flight booking service is save battery life by not requiring constant network data transfer, thanks to the local storage mechanisms.
there are many great j2me apps that (need to) talk to webservices. just think of the google apps, like gmail mobile and maps for mobile. they are faster and easier to use than using the services via cell phone browser. so if you can design a good app, it's definitely worth it.
EDIT: also, a j2me app makes possible features that can't be provided by a web application: integration with phone features (address book, calendar), "call this number", location api, etc.
I think for business apps, or more text/data oriented things, a mobile web/wap site might be easier to maintain, since you won't have to deal with pushing client updates out to handsets.
For UI-intensive apps (maps, games, etc.), client apps are probably the way to go, so you can handle the more of the processing and rendering on the client side.
Both options are difficult though, since there are so many compatibility issues with phones. You might be best served by narrowing down what types of phones you want to support for your app. If you think most of your customers will be iPhone or Android phones, you can target those platforms (with either client apps or web apps) and avoid old-school j2me completely.
I hate WebApps on phones. They are slow and they don't work in a semi-connected environment.
J2ME apps can do local backups, bluetooth backups, bluetooth data sharing between 2 phones and better responsive UI. However that requires money,skill,time etc.
My main gripes with MIDP though is pushing software updates and wav real time mixing. Technically those are possible within the scope of MIDP but the goons at wheel are not very creative.
How can I save data in mobile phone using j2me?
I want code examples which describes how to store data in mobile phones using j2me.
Further how to give access permission to read/write in mobile phones?
I am using netbeans 6.5 and motorola L6 phone.
Can any one tell me a code example giving how to store, give read/write permission?
You can save data in the record management store. There are some limitations though. The biggest one is that only your application will be able to read the data.
An alternative is to use the FileConnection API, which offers access to the device's file system. All modern phones should support it. However, unless the Midlet is signed, the user will be nagged to give permission to access a file.
Use the PDAPDemo example code from the Sun Wireless Toolkit.
Last time I checked it had a few error handling bugs but it is easily modifiable.
It will tell you what parts of the handset file system your application can read from and write to, both on the phone and on any eventual memory card.