I want to have a software to manage my drivers of a delivery-service.
My plan:
A googlemaps-route planner where i can fit in the orders to drive.
The driver has a netbook with the same googlemaps-route planner in his car. it gets synchroned with my map.
the driver has a GPS that show me his position on the map.
the driver can use the route-planner as a navigation software.
Is this possible? how can I implement it?
Is there already a solution where I can use?
There is no easy solution for that. This will require some advanced programming skills, so if I were in your place I would simply equip your driver in a tablet/smartphone which usually come with GPS receiver and try to find ready made solution for Android/iOS platform as those are the most popular today.
Answers to your 4.points:
1) can work, you send the position via internet to the app on his tablet which calls the routeplaner for that position.
2) yes, see 1)
3) yes, your app on the netbook sends the coodsinates to your server.
4) no, what i know this is prohibitted by google. see google license conditions, and further it would technically not work.
Point 4 could theoretically be solved by OpenSoure Navi solution(s) but they all give a bad route compared to professional navis.
recently TomTom provides a solution to interact with a (special version) of a TomTom navi.
But consider that your task needs some person years of effort.
Related
My company writes software that installs on client machines to perform point-of-sale transactions. The software interfaces with a variety of external peripherals (receipt printers, bar code scanners, credit-card readers, etc). We do this with a WinForms app that we created in Visual Studio using the Microsoft OPOS library, which in turn communicates with our cloud server.
There are obvious inefficiencies in this model, primarily with updates. I'm researching other ways to communicate with these peripherals over the web, preferably via web browser. So far as I can tell, Java is one of the only technologies out there that can do what we're looking for (via applet), and I assume Adobe Flash can as well (via the Air platform). These are viable, but not preferable because we want to run our software on web-enabled mobile devices.
Does anybody have suggestions for other ways to communicate with external peripherals over the web?
UPDATE (Jan 16th, 2019): The Credential Management API has been announced. It's currently only supported on Chrome and Opera but it's looking promising. Google Developers wrote an article elaborating on the spec.
UPDATE (Dec 28th, 2016): Another couple years gone, and another update. This one will be more focused on two new developments than anything else. See the new "WebUSB & Web BlueTooth" section under "Full Device API". But the answer remains the same.
UPDATE (Nov 3rd, 2014): It's been just over two years since the original post was made, but the answer remains mostly the same for now. We are, however, closer to your original goal in several areas.
ORIGINAL ANSWER:
There would be a number of ways to go about this.
Background
The HTML5 specification has entered into the "Recommendation" state. This means that HTML5 is pretty much set for what it looks like. However, I will be using HTML5 in the same way that every marketing person in the world has decided is best. That is, I will not be talking about HTML. Well, I will, in so far as you will utilize it from an HTML page, but not really. What I'll actually be discussing is JavaScript (JS) and that's a horse of a different color. But for all intents and purposes, we're putting it all under the same heading as HTML5, which has been decided to mean "shiny and new" now.
Also, the items which I am discussing will vary in support. Some are very browser dependent projects (like Chromium specific implementations), and some are more standards driven projects that may not have browsers implementing or experimenting with them yet. I'll try to distinguish between the two as I go along.
Full Device API
Status: Incoming, but not ready
Being able to access devices from the browser is making slow but steady progress. Right now, many modern browsers have access to some of the more common devices like the camera or gamepads, but they are all high level APIs. Browser vendors, the standards groups, and lots of companies involved with the web are all trying to make webapps just as powerful as your local applications.
But the APIs you are looking for are still in progress and a ways off. For your particular case, and for the more general case of connecting your webapp to most devices, we're still a few years away from something we can use. If you want to see what awesome things are coming up in that field, here are just a select few items that may help you directly:
Web Near Field Communication (NFC) API
This one unfortunately may be dead in the water for now. But it looks like originally some folks at the W3C (mostly Intel it looks like) were looking at adding a NFC API to the web.
Media Capture Streams
The WebRTC group is working on programmatic access to media streams like the camera which would allow to integrate things like barcode scanning or other features. This has reached CR status and is available in browsers, but is less helpful on its own.
Web Bluetooth
If you had bluetooth capable tools, this API would help you connect with them from computers and devices that were able to listen and connect. The primary driver for this at the moment seems like it is the Chrome team, including an experimental implementation, but I wouldn't consider it anywhere ready to use yet (See "WebUSB & Web BlueTooth" section).
WebUSB
This would allow full access to low level USB information including listing devices and interacting with them. Same as Web BlueTooth, this seems to be current Chrome pet project, but I also wouldn't rely on it (See "WebUSB & Web BlueTooth" section).
Network Service Discovery
If you have other devices or items on the network which broadcast and use HTTP, this API would allow you to discover and interact with these services. No browser implementation, but it is in a working draft for the W3C.
Originally, Mozilla was pushing a number of these forward because of Boot2Gecko (or Firefox OS). However, with that project officially cancelled, we aren't seeing much progress from them in these areas now.
Members of the Chrome team, however, seem to have decided to dive in and start not only working towards these, but putting them live in browsers. Which leads us to...
WebUSB & Web BlueTooth
Like sausages, it's better to not know how Web Standards are made
-Abraham Lincoln (probably)
There's been a little bit of buzz in this area as it looks like the Chrome team snuck in these as experimental features and developed their own specification for it. Which is great! Just maybe not in the way that you were hoping for.
Each browser vendor and W3C contributor group has their own style and makes contributions towards the specs in their own way. The result is usually a fairly decent specification that the browsers have agreed upon. But getting from nothing to something is... messy. Real messy. And is quite a process a lot of times. It doesn't always result in a good spec (yeah, I'm talking about you Florian compromise...) but even when it does, it takes a while.
However, It seems like Google developed this version of the spec all on their own. And, in my experience, Google's approach to the specs is always a little... well... setting my personal opinions aside we'll say "gung-ho". They tend to just dive right into the deep end. And that seems to be what they've done here.
I highly doubt these specs or implementations will look anything like this when they become standards. And there's nothing wrong with that. That's part of the process. But I wouldn't go relying on this implementation or developing any code or products against it. This is an unprecedented feature on the web and all the browser vendors are gonna want a big say in this.
That said, this is actually good. One of the things Google often does (for better or worse) with situations like this is forces the conversation and it can push things along. And having a feature shipped in the browser, even an experimental feature, can turn up the heat on the demand for it. So we may see more progress in this area soon.
PhoneGap Apache Cordova. You know, for your phone
Status: Not fully featured and phone only
Apache Cordova, previously Adobe PhoneGap, is a way to write your program in HTML, CSS, and JS that allows you to access lower level functionality on things like phones, and compile across devices. This would be a way to implement your program, but it would be a phone application, not necessarily a desktop one. An option to consider, and something I figured I would mention.
Cordova implements a few of the above features already, but doesn't have some of the more powerful ones like NFC or BlueTooth.
The Native-App solution (for Windows 8)
Status: Possible, but OS specific and desktop app
Windows 8 offers the ability to build applications in HTML and JS. This would allow you to easily access lower level functionality on the OS via their API. From the looks of it, it is pretty extensive and you can do a lot. You mentioned cross OS support, however, and this obviously limits you to one OS.
It's so Flash-y!
Status: Dying/Dead, not possible as a web app
Flash won't have direct access to the system through the web. You could create an AIR application, but that will sort of defeat the purpose of having it web based. In addition, Flash support on mobile, and on the web it would seem, is on the decline.
NodeJS
Status: Can be a bit of a pain and only possible as a desktop app
NodeJS and JS applications have sort of been a hot topic the last couple years. I didn't discuss it in my original post because I felt it wasn't quite there yet. However, things have progressed and it is much closer to being ready for this sort of thing, and has the support and power of a growing user base. That said, for your particular case, I wouldn't recommend using it. It would have to be local on the users machine, and because of how NodeJS (and similar engines) are at the moment, it would require a lot of extra configuration and setup that would complicate things a bit.
So you could build an app using HTML, CSS and JS with NodeJS or similar engines and have low level access to what you need, but it has to be local, and it would take more work than I'm sure you want to do every time you'd like to install it for a customer.
... Now where was I?
So where does that leave us? Well, simple: if you want a single language/set of code as your code base, HTML/CSS/JS aren't a great option... yet. But they could be some day. For now, your options are limited to what you feel is best for your customer. Java is a stable option you listed, but obviously comes with its own drawbacks. As the web develops, I think we'll see a lot of really cool things coming out of the new functionality, but we've got a ways to go still.
More reading:
Brian.IO: Beyond HTML5
HTML5 Apps on Windows 8
Wikipedia list of projects built using JS
This is possible, but it would have to be done indirectly. In theory, you could write a socket-server in a low level language, which gets I/O, and sends the I/O through the socket (relaying, I guess). HTML5 uses WebSockets, or some equivalent to communicate with this socket-server.
Now it can be achieved with WebUSB API.
It is available in Chrome since version 54.
It is a W3C editor's draft so we can expect (hope) that it will be adopted by other browser vendors...
I've been thinking about this a lot lately... have a POS app mostly written in VB6, considering what to do next. HTML5 is an option and I was thinking I'd use VSPE to get the serial stuff into the JS.
http://www.eterlogic.com/Products.VSPE.html
Love this product! Works very well for getting serial traffic where you need it, so I think it would work well, at least as a proof-of-concept to get you going. You'll want to use a combination of "connector" types along with the "tcpclient" and "tcpserver".
Just for the record, a method that works well in 2016 (since chrome 26), but is to be withdrawn over the next 2 years is to deploy your html5 as a chrome app and use chrome.usb (or chrome.serial or chrome.bluetooth).
I am currently using chrome.usb and planning to migrate to a web app using WebUSB API (see Supersharp's answer), which I hope will be adopted by the time Google discontinue chrome apps 🤞.
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 am a final year Computer Science undergraduate student from India. I want to create a WPF application that displays 3D buildings like in the latest Google maps 5 for android. This will be the basis of my final year project. I have some questions before i start working on this.
Should I make it desktop or web based, or should I use the web to store some metadata and render the data in the desktop software?
For 3D display of buildings in a map area, is WPF enough or will I need knowledge of XNA and Direct X too?
Will this violate Google Maps TOS if I use Google Maps API? (I want to do something Google Maps does not provide in India) Is using Bing Maps a better option?
Is it feasible to read building elevations and rendering them using the above mentioned Maps APIs? Is it that the elevation data available through Google Maps API is only for the terrain and not for individual buildings?
I have three months to complete this project and have given details of the technologies I intend to work with.
Will I need in-depth knowledge of any more technologies for this?
Excuse me if I missed some detail. I am posting this from my cellphone using opera mobile. It's time we have an android client for stackoverflow.
1) That is entirely up to you. As you don't specify your target user then it is hard to say what the best way to deliver the application is. For example, if you want to be able to widely distribute it and have a high compatibility then perhaps a web-based application would be best. Conversley, if you require high performance and are targeting a specific os, chip-set, etc then a stand-alone application may be better.
2) Again, it is hard to say. WPF can certainly render 3d objects and may provide you with everything you require. If again you require more complex rendering you may also want to look at later versions of Direct3D, which can help a lot with things like HDR textures, Multi-threading, etc.
3) I am not a lawyer so I can't say for sure - even if I If I were it would still depend on the specifics of your implementation. That said, the bing maps section 2 (i) seems pretty good for you - Academic use seems pretty open as long as you make the application available publicly without restriction. The Google TOS seems more restrictive to me at least.
4) To me that would be a breech of the Google Maps/Earth TOS - The section on Restrictions on use seems pretty clear...But again, I am not a lawyer so I can't say for sure...
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.
Simple question, the answer may not be...
I'm going to be developing a web app (ASP.NET MVC) for a client. They have asked me for an opinion on whether to use Google Maps or Virtual Earth for providing a mapping solution.
Which would you go for and why? Or are there others you can recommend?
What else do you need to know?
Street view (or equivalent) won't be
necessary in the near future, but
one day it might.
The client wants to identify certain
mappable features, and beyond that
find these features when within a
specified distance.
What else should I be considering at a high level? Or my client?
Thank you in advance.
One of your major considerations needs to be licensing if this is for a commercial web site. You'll have to contact both Google and Microsoft for exact details and pricing, but there's plenty on the web that indicates it could cost you $10k to implement these solutions in production. They get you hooked on the rapid and easy development though!
My preference is for Google Maps, it just feels a bit slicker but I have developed some pretty good prototypes with the Virtual Earth SDK before.
I don't know if Microsoft are planning an equivalent to the StreetView feature so if that is on the requirements cards in the future then stick with Google.
Either of the technologies will allow you to search for geographic features in various ways - whether via region, street address or specific latitude + longitude. They also allow you to overlay your own images or draw lines, polygons etc.
Google Maps seems to have a wider user base (even though Microsoft were technically doing this stuff before Google got into it!), so you're likely to find more help out on the intarweb when implementing your solution than for Microsoft.
More info on Google Maps for Enterprise is located here:
http://www.google.com/enterprise/maps/map_info.html
You should be asking the client for a reasonably comprehensive list of requirements for the mapping solution. You've mentioned one - these "mappable features". Are there any others?
Once you've got the list you can then see which one provides the best fit and go with that.
If Street View is definitely on the horizon then you have to go with Google - or is it something that's just come up in conversation?
Having said that, for a little bit more effort you could write an abstraction layer that sits between your application and the mapping solution so that if the one you didn't choose provides a better fit in the future it would be easier to make the change. Though this does go against the Agile methodology (YAGNI).