|
|
|
|
 |
A.W.E.S.O.M. - O
 |
|
So 'Hungry' & 'Coffee' are to be merely repackaged feeds of Yelp. Yelp is starting to be the dominate player in this arena. For someone like myself, who owns two coffeehouses, features like this will drive business towards the best reviewed places.
Fortunately mine are well reviewed but as this feature becomes prevalent over the coming years it will really start to impact retail sales restaurants and coffee establishments -both good and bad.
|
JeffX
 |
|
A.W.E.S.O.M. - O wrote:
So 'Hungry' & 'Coffee' are to be merely repackaged feeds of Yelp. Yelp is starting to be the dominate player in this arena. For someone like myself, who owns two coffeehouses, features like this will drive business towards the best reviewed places.
Fortunately mine are well reviewed but as this feature becomes prevalent over the coming years it will really start to impact retail sales restaurants and coffee establishments -both good and bad.
|
I was hoping this system wouldn't be such a "walled garden" spoon fed environment. I asked if the systme would integrate with the navi for basic searches and the answer was "Hungry" and "Coffee" are integrated into the navi.
I would like to be able to have a siri/google plain english sort of search function - "where is the nearest sporting goods store?" or "route me to the Georgia Dome"
|
xBeastx
 |
|
Jeff wrote:
A.W.E.S.O.M. - O wrote:
So 'Hungry' & 'Coffee' are to be merely repackaged feeds of Yelp. Yelp is starting to be the dominate player in this arena. For someone like myself, who owns two coffeehouses, features like this will drive business towards the best reviewed places.
Fortunately mine are well reviewed but as this feature becomes prevalent over the coming years it will really start to impact retail sales restaurants and coffee establishments -both good and bad.
|
I would like to be able to have a siri/google plain english sort of search function - "where is the nearest sporting goods store?" or "route me to the Georgia Dome"
|
I would also like a Siri-type speech recognition system. Apple should team up with Honda and create a universal multimedia infotainment system. Maybe call it CarOS or iNav or something. I think the software in Honda's lineup is too separated. You have the "full" i-MID system on the Civic and CR-V, while the Pilot and Odyssey have just a screen with no steering wheel controls. Hopefully Honda plans to slowly add the "full" system to their lineup. It would be great if they add in the HondaLink for the MMC of the CR-V.
|
A.W.E.S.O.M. - O
 |
|
I've read Apple's plans are to lean on Yelp! heavily too in it's new native maps app ... all in bid to destroy Google search.
What's interesting is they are leveraging Yelp! not really for reviews (which was kind of why it was created) but rather as a white pages - in effect business listings. This will circumvent Google altogether when Siri queries. No need for Google Maps - or Search - that is Apple objective. Yelp is one of the linchpins in the endeavor.
|
TonyEX
 |
|
A.W.E.S.O.M. - O wrote:
I've read Apple's plans are to lean on Yelp! heavily too in it's new native maps app ... all in bid to destroy Google search.
What's interesting is they are leveraging Yelp! not really for reviews (which was kind of why it was created) but rather as a white pages - in effect business listings. This will circumvent Google altogether when Siri queries. No need for Google Maps - or Search - that is Apple objective. Yelp is one of the linchpins in the endeavor.
|
That's an idiotic approach.
Open standards is the way to go.
Just think, Android is now the dominant OS in the smart phone domain for a very good reason: It has a standard open OS, a standard set of open APIs and standard open hardware interfaces.
With open standards, all you have to do to create an interface between the car (or other gadget ) to Android is
(1) Write your own host firmware (the part that stays forever and invariant in your car's NAVI)
(2) Write your own Android target application (that gets installed by your clients into their smart phones over your website)
(2a) The target application could be a simple bridge that translates some other Android application so that it can communicate with your own in car host firmware... simple, brilliant!
(3) Build the connection around the USB or Bluetooth or 802.11 whatever drivers...
(4) If you want, you can even create a USB based mechanism where you can allow your dealers or customer to update the host firmware as time goes by.
The Apple way is more driven by close standards (both hardware and software) and their own marketing decisions, which bore no advantage to the manufacturers of gadgets that want to build an Apple interface..
If you don't believe me look at how expensive iPod digital docks are... this is because Apple charges and arm and a leg for the info and the license. Android, OTOH, is relatively free and only limited by how fast Google can port the already existing Linux drivers into it.
It's only a matter of time before the developers of in car firmware systems -the host- realize that they need to disengage themselves from the tyranny of the target developers and just write their own, which with open standards is a slam dunk.
Done that way, the host developers take control over the interface and ensure long term support... new OS update? no problem, just update the target app and put it out there on your web site, let the customers load it into their new phone.
At that point, Apple will be hosed. In essence it's pissing into the wind, hoping to be the 900 lb gorilla when in reality it no longer is. Google has changed all of that.
PS- Actually, if you are very smart, you use Linux to build your in car host firmware as well.. NOT Microsoft...
|
atomiclightbulb
 |
|
TonyE wrote:
Just think, Android is now the dominant OS in the smart phone domain for a very good reason: It has a standard open OS, a standard set of open APIs and standard open hardware interfaces.
Done that way, the host developers take control over the interface and ensure long term support... new OS update? no problem, just update the target app and put it out there on your web site, let the customers load it into their new phone.
...
At that point, Apple will be hosed. In essence it's pissing into the wind, hoping to be the 900 lb gorilla when in reality it no longer is. Google has changed all of that.
PS- Actually, if you are very smart, you use Linux to build your in car host firmware as well.. NOT Microsoft... |
What prevents car manufacturers from programming their own iOS apps to do exactly what you propose for the Android platform?
Is the iOS platform really that much more closed than Android? There are numerous third party apps for iPhones and iPads. I really don't think it would be difficult for a developer (or automaker) to build an iOS app that can interface with the firmware in a vehicle's telematics system.
I took a look at https://developer.apple.com/devcenter/ios/index.action
It looks comparable to the Android site:
http://developer.android.com/index.html
At any rate, iPhones are too popular to ignore. Android may be more prevalent due to sheer number of devices and lower cost, but iPhones are coveted.
|
atomiclightbulb
 |
|
In full disclosure, I am a member of the Android camp. However, I am painfully aware that Android's openness and dominance has a cost.
Without going into a whole lot of technical detail, the sheer variety of Android OS builds from each phone/device manufacturer can make getting an app right, or mostly right, on as many devices as possible can be a real pain in the rear.
Every device maker is free to tinker with Google's releases. So a Honeycomb or Jelly Bean build from Samsung may behave differently from a release by LG or Motorola or other handset maker. The differences are often subtle, but they can cause apps to break or behave less than optimally. Complicating matters are the multitude of OS updates (or lack thereof) that can occur. Some phones get OTA updates, others do not, for reasons that are usually unknown other than to the manufacturer. Apps can unexpectedly break when people upgrade their firmware. Android is a fantastic platform to tinker with, but again, that comes with costs.
|
TonyEX
 |
|
atomiclightbulb wrote:
In full disclosure, I am a member of the Android camp. However, I am painfully aware that Android's openness and dominance has a cost.
Without going into a whole lot of technical detail, the sheer variety of Android OS builds from each phone/device manufacturer can make getting an app right, or mostly right, on as many devices as possible can be a real pain in the rear.
Every device maker is free to tinker with Google's releases. So a Honeycomb or Jelly Bean build from Samsung may behave differently from a release by LG or Motorola or other handset maker. The differences are often subtle, but they can cause apps to break or behave less than optimally. Complicating matters are the multitude of OS updates (or lack thereof) that can occur. Some phones get OTA updates, others do not, for reasons that are usually unknown other than to the manufacturer. Apps can unexpectedly break when people upgrade their firmware. Android is a fantastic platform to tinker with, but again, that comes with costs.
|
The trick is that the car manufacturer's Android application should be a BRIDGE... something that interfaces existing applications in the smart phone to some remote host application running in the car via some standard interface driver.
The car manufacturer hence provides no content providing application, only a connection and possible translation to the host software running in the car.
That way, the GUI is never involved and the BRIDGE software is used by the more invariant -and untouched- parts of the firmware.. in essence, it's tied to the OS.
|
atomiclightbulb
 |
|
TonyE wrote:
The trick is that the car manufacturer's Android application should be a BRIDGE... something that interfaces existing applications in the smart phone to some remote host application running in the car via some standard interface driver.
The car manufacturer hence provides no content providing application, only a connection and possible translation to the host software running in the car.
That way, the GUI is never involved and the BRIDGE software is used by the more invariant -and untouched- parts of the firmware.. in essence, it's tied to the OS. |
I understand what you are saying, but that doesn't change the fact that Android's fragmentation makes app compatibility a problem.
Different OS builds can break an Android service if the developer isn't careful. If the software bridge is incompatible (or becomes incompatible when the mobile device firmware is upgraded at some point), the device will not interface with the car.
One other thing I have thought about is user interface. Most Android phones use touch-sensitive LCD of some variation, usually in the neighborhood of 3-4" diagonal. The interfaces ("Activity" is the technical term Google uses) are generally designed for these displays.
Say a mobile phone is "bridged" to a vehicle's telematics system. The app runs on the phone. User input from the car is passed from the telematics system to the "bridge" software on the phone, which in turn relays those inputs to the app running on the phone. App data is passed in reverse to the telematics system via the bridge, and displayed on the car's interface. There still has to be some kind of user interface in the car's telematics system, and that system may have different ways of inputting and displaying data.
For example, a driver may use a combination of steering wheel controls and a center-stack knob/controller. This kind of input hardware does not translate well from an interface that was designed for touch-screen input. An app designed for a 3.5" touch LCD may not work so well when bridged into a hardware interface that depends on an 8" non-touch LCD and steering wheel controls.
Even if all of the App's background computation stays on the phone, and the car is only responsible for Interface, there is still a need for the app developer to create an interface that works with the hardware on a car.
|
|
|
| |
|
| Thread Page - [1] |
|  |
|