This is more of a terminology question...
I'm developing an occasionally connected application that will run on a tablet for clinicians or field service workers but I'm struggling with what this type of computing is referred to. Mobile computing as connotations of a phone app. Whereas our clients may be occasionally at their desk. Microsoft uses Smart Client a lot, but I'm not sure if that best describes this scenario or is the common term for this kind of computing.
In healthcare, it's called "Point of Care" or POC, e.g. using a POC device or application while taking care of a patient.
Is Tablet Computing a bit too blunt for you? It's certainly a well-known term, and it seems to adequately describe your client's use case.
Related
When doing an EMV online transaction (ARQC), an EMV device needs to communicate with the issuer (or gateway) to get approval/denial. I am writing POS software and need to support EMV, thus I need to support this interaction. What I can't seem to answer is, is it part of the EMV specification for the EMV device to communicate directly with the issuer, over internet? Or do I need to be looking for some sort of send function in the device's API?
I know this question could be directed at a hardware manufacturer's design, but I have read a few API's for different EMV devices and non of them seem to detail this communication. Most of them have a function to initialize the EMV capabilities (with the transaction amount) and then a callback/event when the transaction is completed. This leads me to believe that all I need to provide is a good internet connection to the device and the magic will happen.
As a followup to that, I see some devices have USB communications (instead of ethernet). These devices (obviously) couldn't talk directly to an outside network. Is it safe to assume these devices are going to do every EMV transaction offline? Or am I missing something?
As far as I have come to understand, EMV covers the finer details of the communication between a card and the reader device, then gives the procedure/standards to be followed when delivering that data online. Thus, once you have performed the local processing of the card, you will use whichever means you can find to deliver that info to an online acquirer (assuming its an online transaction) and that communication must fulfill the EMV (and also PCI) security requirements. So Yes, you will need an Internet connection for online transactions. That part, which will "encode" the data according to financial standards and protocols and send it to a specified acquirer/issuer, will need to be created by the developer (you).
After much research and headaches, I think I have answered my question. And it is..... Level 2 Kernel. This is the piece that I couldn't find anywhere because (i think) the whole EMV thing is so new in America. As Peter posted in his reply, EMV covers the finer details between the card and device, but only gives suggestions on delivering that data. The Kernel is the "vehicle" by which the Cryptogram (created by the card and device talking) is delivered to the card issuer for approval. Because the Kernel is (usually) a piece of software running on a computer (as a network service for example), it can house both IP communication with the pin pad or monitor a USB port.
From there I realized that I had two choices, first develop my own kernel and go through the whole pinpad integration AND EMV certification (ummm no thank you). Or second, find a company that has already done the certification and pay for use of their solution (yes please).
I found a company named CreditCall offering a product named ChipDNA which is an interface to an existing certified Level 2 Kernel. They have a Microsoft and Java integration. They have already integrated with certain keypads and handle the entire EMV online communication (end to end). They offer a lite version of their API for free, which I created a little console prog for. Worked like a champ! Cut a ton of development time off and a big [certification] cost.
....now I've got to get the accountants to "ok" the ChipDNA cost.
One that I know of is User Agent detection to find out the device. It look like user agent could be change by the service providers for some reason. Are there any other robust methods of device detection or the mobile technology is yet to evolve?
Note: The detection is not restricted to any particular technology. Primarily looking for video compatibility across devices. I have tried to implement solutions available in market, but they have some limitation or other and does not allow full customization required. So I'm looking to develop one.
Have a look at OpenDDR, a device detection library available in .NET and Java, and a repository of devices updated every month. http://www.openddr.org
The library is licensed under LGPL.
It depends what you need, but I usually use this one: http://51degrees.mobi/
If you don't need very detailed info you can use free service, but for example, if you need mobile/tablet division you would have to pay for their service.
I'm looking to develop a mobile app which is going to help people find out whether a train is going to go to a particular platform or not.It is very simple. I know the timetables. I'll be making database of train timings and compare with the timings of user, when he uses the app and tell him, if the next train coming at the station he's at, is going to this platform at location X or not.
There won't be any fancy UI. There would be a dropdown of all stations. That's it. Response from the app will be going to platform no A. I don't know if I will include any feature as of now. The requirement that I see is, app should be offline and platform agnostic.The database entries are fixed and if they change then I should be able to give a new update.I have been reading about HTML5, but I don't want people to use the Internet for this. It should be available on Nokia phones,Android phones, Blackberry,Apple in that order.
Offline and platform agnostic will be hard to combine, unless you use one of the toolkits that pretend to do this (we started that way, but reverted - cost more time to chase bugs in the toolkit than to write code). Easiest is you give up the first requirement - most people with smart phones will have data bundles anyway, a tiny query is not going to make them frown.
Assuming you're not dropping the requirement, HTML5 for the UI can still be an option as most platforms let you embed the browser in your app. That way, you'd only need to port some small wrapper code and the business logic. If it's a commercial app, pick one or two key platforms (that will give you the necessary user feedback to make your app better) and outsource porting of the rest.
This is a tough one... I'd choose native programming. Id just have all the different platforms linked so they use the exact same database. Unfortunately, they all use different programming languages. I don't know about Nokia or Blackberry, but Android uses Java (or C# through MonoDroid) while Iphones/Ipods use Obj-C (or C# through MonoTouch).
I have to architect a commercial vehicle fleet tracking system.
Each vehicle (a few 100, max a few 1,000) will have a GPS and satellite transmitter and will periodically report its position. Positions will be stored in a database and used to create a Google Map.
There will of course be other functionalities. Security, log in, etc and probably lots of interaction with other corporate databses (drivers start/stop time for salary purposes, etc).
Question: pure GoogleMaps is probably best implemented as a browser based app (Php & MySql?), but with the additional functionality of a commercial vehicle fleet tracking system, would it be better doing something PC based (Windows/Linux)?
Any other advice? Thanks
I think with the capabilities of modern browsers, along with various mature client-side frameworks, we are witnessing an always thinning distinction between web and desktop interfaces.
You may want to take into consideration that a web application automatically solves some important problems for you:
Distribution: No need to distribute your application. Simply provide a URL.
Updates: Upgrading and fixing problems in your software will be easier and quicker if you distribute it through a web interface.
Security: Deriving from the above, you are able to fix security vulnerabilities more promptly.
Compatibility: Your application will be able to work on any operating system that can launch a web browser.
Last but not least, remember that the Google Maps API is not free for this type of application. Article 10.9.C of Google Maps API Terms and Conditions explicitly restrict using the standard Google Maps API for fleet management and asset tracking. You would need the Google Maps API Premier to legally use Google Maps for your application.
According to one unofficial source (dated April 2008), this would cost USD 10,000 per year, which entitles you to track 100 vehicles. If you exceed the 100 vehicles, you would need to add USD 24 per additional vehicle per year.
Implement solution for the domain problems first. It means data storage, data transmission between vehicles and your system, methods of data analysis, aggregation and visualisation.
These will likely to sit as a head-less system on a server and provide access to it remotely, in both directions: to input data and to query data.
Now, PC or Web is more related to presentation on a client side. You can make both if you like. Web client as well as desktop application can serve as a client to remote data and operational server.
Don't forget that you can always host a web control in a thick client app. This is actually trivial with .Net on the Windows platform with the IE control. You can also access the browser's DOM this way and do some neat things. So just because there's a strong web component to what you're doing you're not necessarily "stuck" writing a pure web app.
One big question is what kind of hardware you'll be able to put in the vehicles. Will they be laptops or small PCs with full fledged OSs or something more mobile like CE or a pared-down Linux distro?
Google Maps is JavaScript based so you can do most things with it, e.g browser based, widgets, etc. However due to the licensing Google won't allow you to use it in anything other than an Internet environment unless you use there Enterprise License.
In terms of integrating it into other systems, its really difficult to say what's best without knowing what other software you are using, what protocols they use, are web services available, etc. I agree with Daniel though in that any distributed system not implemented in a browser better have some good reasons not to, simply because the benefits are substantial. You'll need to weight them up though with a full break down of all the different systems you will need to interact with and work out what fits best.
The great thing is that with it being JavaScript based you have a lot of flexibility in what you can do with it.
This is more an extension to #Daniel Vassallo's answer. Although a web based application would solve most problems there may be the small potential issue of bandwidth usage and reception for internet access. This may or may not be an issue for the fleet management, depending on how that is tackled on the hardware side of things.
An offline solution may assist with this issue but then a clever architect could find a way to create an initial web based solution which can be accessed with an offline application which can pick up the slack and/or provide predictive reasoning until a connection is re-established.
I friend asked me this today.
Picasa Web has a cool (and frightening :-) feature where it will recognize all the faces in your photo album.
But the PC (desktop) version doesn't have this.
Several reasons I can think of:
They just haven't gotten around to writing the PC version of the code.
They are licensing that feature and it costs a lot more (or isn't available) on the PC.
Takes a lot of processing power (this seems odd b/c MY PC cycles are free to Google, but they have to pay for for cycles consumed on their server.
Any other thoughts?
I'm certain it'll make it out in coming releases but Google is a funny company when it comes to its own competing/complementing services. One thing is for sure, only somebody on the Picasa team could give an accurate answer.
But we could hypothesise several things...
They don't want their code reverse-engineered.
(As you say), they aren't licensed to redist
It's blocked in the dev version by other new features that aren't complete yet
They don't want to release it because they want people to use PicasaWeb as a social photo network.
I don't think processing power is an issue. If they're running it in bulk on their own servers for free, a modern desktop could probably run it without issue.
From my limited contact with face recognition software, it's probably the redistribution issue. When I dealt with it, face recognition was its own little world with extremely high per-CPU licensing costs and tremendous paranoia about code getting loose.
I'm not so sure it's not a processing issue. It took Google's massive servers 30 minutes to run through all my photos. I can only imagine that same task would have taken days on my local machine.
Actually, its in, just in limited functionality when you do a search, there's an icon to find only photos with faces. The experimental passport feature also works that way.
So the answer is:
Not the same base (APIs) available or used and not the same language so its not directly portable.
Not the same software and there are no stated goals to make both apps feature equivalent.
Programmers are limited and their time is too. They make choices as to what implement now.
No idea if this is the case for Picasa, but there's another case where licensing could be the issue. If the server-side code is using code with a restrictive license with DRM (GPL, for example) which restricts how you can distribute modules using the code. Running that module on a web server, where the user only gets the output, is legal under such licenses. If that code was distributed, there would be many legal requirements attached which would likely be very undesirable for commercial software companies, including google. This is one very good reason to have some capabilities only accessible through web services.
This was also the case with Riya (who was arguably the first to market with reliable facial recognition for consumer photo collections).
The biggest reasons are likely:
Processing Time (they can't control
how fast your CPU is and therefore
they can't control the experience).
Facial recognition is very likely to
be process intensive (this was Riya's
stated reason for not doing it
client-side)
The recognition process requires a
LARGE volume of data for processing
that is only accessible on the
server? (In other words, the process needs to spin through millions of faces, not just the faces that you have on your hard drive?)