Thread: Why Not a Flash Front End?

Originally Posted by ikon240

Correct me if I am wrong, but does QCar run on Mac, Windows and PC?

Why should it? The whole idea of multi-platform software is good for management presentation, where things like "common code base" sound better than "we will develop two different implementations". In reality, the extra work you have to put in just to implement some functions that are common to the native environment and frameworks is more or less equal to work you would need for a clean implementation of the application design for each platform.

Is it open source?

The parts, which seem to be the biggest problem for the others (like OBDII) are. Others (navigation engine) will be.

Is it free?

No, it is not. Why should it?

I would then make the analogy that a Flex/Flash front end (backed by Java) is like buying a Porche and putting a hybrid engine in that runs on any fuel source (and provides more torque than the stock engine):

Well, it does not provide more torque. And you need a lot of extra adapters and interfaces to actually make it work with the rest of the car :-)

Anyways, this collaboration is seeming more and more possible as we get into it. The hard part with GPS is still the maps.

Nonsense. For the USA, you can get very decent free vector maps. Even getting the maps from Navteq and TeleAtlas for reasonable prices is not that difficult. In my opinion, the biggest problem with navigation is that it requires a little knowledge of "real" programming, not just click + drag & drop in Interface builder. From my own experience, the single most difficult task when making a navigation app is to create a map format, that would not take up too much disk space and would provide quick access to the data - even smaller countries like the Netherlands contain hundreds of thousands of road elements and to work with this amount of data is no fun.

Jirka,
I did not mean to start a thread war! But to address a few of your questions...

The short answer:
I would like to see a front-end that runs on Windows, Mac and Linux because people who have car computers have either a Windows machine, a Mac machine or a Linux machine. it has the highest potential for ubiquity.

The long answer:
I tend to think TOO far into the future in terms of what I want software to do. For example, I would like to see front-end software that does everything today's software does, plus add functionality to share data between carpc users. This is not even feasible until there is a common front-end that is pervasive. I want to drive in a virtual convoy of sorts with other drivers who happen to also have the same front-end as I. At that point, one driver with a sweet setup, such as internet, radar, and tons of media, could stream services to other carpc users. How bad-*** would it be if I could get a radar service from another driver ahead of me - see the radar alerts he/she is getting on his V1, etc. Or say, I have 1500 Divx movies in my setup and someone else wants to browse and watch one, etc.

The whole idea of multi-platform software is good for software.

In reality, the extra work you have to put in just to implement some functions that are common to the native environment and frameworks is more or less equal to work you would need for a clean implementation of the application design for each platform.

Flash is flash, it is the same runtime on each type of machine. Java is the same. I guess on windows you can double-click a jar, where as on a linux machine you might have to break out the console. Rest assured its possible to code it once and run it anywhere.

The parts, which seem to be the biggest problem for the others (like OBDII) are. Others (navigation engine) will be.

Right on. I am in no way trying to dictate the open-ness of software that someone else wrote! Part open-source is better than none!

Is it free?

No, it is not. Why should it?

Umm, because I'd rather not pay for it? Is that a hard one to answer? Take a poll of the community: Given two equally functional front-ends, would you prefer to pay for it, or get it for free? How many copies of streetdeck are out there in the DIY'er community versus something like RR? If you are unsure of how the community would answer said poll, just look to the music industry from the post-napster era.

I would then make the analogy that a Flex/Flash front end (backed by Java) is like buying a Porche and putting a hybrid engine in that runs on any fuel source (and provides more torque than the stock engine):

Well, it does not provide more torque. And you need a lot of extra adapters and interfaces to actually make it work with the rest of the car :-)

I simply added the "more torque" comment so I could link to the John Goodwin autoblog article :-) He added a biofuel-turbine hybrid engine that produces more torque in the hummer than the stock engine. Best of all, it was built with all off-the-shelf GM parts. Count me in as against the Detroit bail-out, but alas I digress... . As for the extra interfaces and such... when building a carpc one HAS to buy an OBDII cable if they want OBD. One can buy a proprietary cable or one that works with some open-source piece of software. Same for XM... there is a USB powered PCR board XM tuner that works with a java application. Most people probably have factory XM modules or other proprietary hardware built for their headunit. If people had the choice, they could choose the open-source-friendly, least-proprietary hardware. Suffice to say, people have to buy some interface if they want the functionality. I don't think people would mind buy an extra cable here or there if they knew what they were getting in return.

Anyways, this collaboration is seeming more and more possible as we get into it. The hard part with GPS is still the maps.

Nonsense. For the USA, you can get very decent free vector maps. Even getting the maps from Navteq and TeleAtlas for reasonable prices is not that difficult. In my opinion, the biggest problem with navigation is that it requires a little knowledge of "real" programming, not just click + drag & drop in Interface builder. From my own experience, the single most difficult task when making a navigation app is to create a map format, that would not take up too much disk space and would provide quick access to the data - even smaller countries like the Netherlands contain hundreds of thousands of road elements and to work with this amount of data is no fun.

Ah great input! I will readily admit I know little about the mapping side of things at the moment... other than having done some google maps in Flex applications. I am a developer by trade, so I fear no coding! But I am lazy, so I'd like a good plan before I'd even attempt it. Maybe I can pick your brain on this going forward.


As always, I appreciate the discourse!

-ikon

Originally Posted by ikon240

Jirka,
I did not mean to start a thread war!

A (civilized) confrontation of ideas is the best way forward :-) But if the admin finds this inappropriate, he can move this to a more suitable place.

I would like to see a front-end that runs on Windows, Mac and Linux because people who have car computers have either a Windows machine, a Mac machine or a Linux machine. it has the highest potential for ubiquity.

Well, I believe the front end has to be so good, that the users will not care at all about what runs underneath. Since it is rather unlikely the user would use the standard desktop environment on a Car PC, we can afford this approach. I have no idea what version of Linux my DVD player and IP cameras at home run, but I am still very happy with them. How many normal users care (or even know) about what OS runs on the Apple TV?

This is not even feasible until there is a common front-end that is pervasive

Again I disagree. You do not need a common front-end. You need a good and simple-to-use API that allows everyone to use these services. Look at many providers of weather information on the web. Or Google Maps...

I want to drive in a virtual convoy of sorts with other drivers who happen to also have the same front-end as I.

No big deal. All you need is a server with a simple web service, that receives position updates and provides them back to clients. We have a simple demo, that is fully working, but does not have fancy configuration user interface etc. This module is on hold right now, because of issues with mobile internet connection (especially price - the function would be most handy when travelling abroad, but then the data prices are really high here in Europe). If you want the source code, you can have it. If the web service is still running (we have recently moved our servers), you can have access to it and play around...

At that point, one driver with a sweet setup, such as internet, radar, and tons of media, could stream services to other carpc users. How bad-*** would it be if I could get a radar service from another driver ahead of me - see the radar alerts he/she is getting on his V1, etc.

I do not want to sound too pesimistic, but what is the density of Car PC users? ;-) You are really looking very far into the future :-D The idea is great, but probably not feasible until Car PCs become as common as car radios are today. Which means adoption by the car manufacturers and probably some support and involvement of the cellular data service providers. BTW: how many people do use OnStar beyond the free period they get with the car purchase.

The whole idea of multi-platform software is good for software.

I agree, that it is good to have the same or similar application on more platforms. I just do not agree, that this should be a single implementation/binary, based on a single code base. I believe that only the design (!=GUI) of the application should be common to all the versions for different platforms. Look at what Google does with Sketchup - a great Mac application, a great Windows application. If you only use functions that are available and more or less the same on all platforms, you can't build an app with appropriate look&feel the users of that platform are used to. Same if you try to go around the OS and create your own frameworks for things, that the system can do easily for a native app.

Flash is flash, it is the same runtime on each type of machine. Java is the same. I guess on windows you can double-click a jar, where as on a linux machine you might have to break out the console. Rest assured its possible to code it once and run it anywhere.

Right and that is why you have to invent dubious techniques even for such a simple task as communication with a serial port or running another process on the same computer. Like it or not, Flash is a sandbox, which is and I think always be limited, when you compare it with the native environment of an operating system.

Umm, because I'd rather not pay for it? Is that a hard one to answer? Take a poll of the community: Given two equally functional front-ends, would you prefer to pay for it, or get it for free?

The EQUALLY FUNCTIONAL is the key phrase...

If people had the choice, they could choose the open-source-friendly, least-proprietary hardware.

Well, I bought an iPhone, not that Android handset... There is a difference between DYI part of the market and the general automotive market. For most people, functionality comes first (but like your line, this is just a personal opinion).

Ah great input! I will readily admit I know little about the mapping side of things at the moment... other than having done some google maps in Flex applications. I am a developer by trade, so I fear no coding! But I am lazy, so I'd like a good plan before I'd even attempt it. Maybe I can pick your brain on this going forward.

I can give you most of our navigation-related source code. However, I can't give you our original map data - but you should be able to download some examples from TeleAtlas developer site. However I am highly skeptic when it comes to implementation in Flash. You should be able to fix map drawing, but the route finding is really CPU-hungry and the file format, that is necessary for quick access to the road network data is really low-level (a memory-mapped file with spatially organized binary structure).

Do you have any idea when alchemy will be hitting flex?

It has already hit. Get the toolkit from the link provided above and have at it! It is supposed to compile c or c++ code into a SWC that you import into your flex application.

-ikon

Jirka,
Thanks for the input, you make several good points.

One thought I had on the streaming of services...

I want to drive in a virtual convoy of sorts with other drivers who happen to also have the same front-end as I.

No big deal. All you need is a server with a simple web service, that receives position updates and provides them back to clients.

As I imagine this feature, it would not be dependent on the internet at all. The "web server" would be your carpc. The "clients" would be other carpc's. The "internet" would be peer to peer connections via wifi. The software would have to be written with some auto-discovery client/server architecture I'd imagine. Again, this is how I imagine it, not sure its 100% possible.

I have seen several wifi utilities that will create virtual networks with a peer-to-peer implementation behind the scenes, etc. It might just be the case that one setup would require a router/AP in the car with an external antenna - for the sole purpose of letting other carpc users join your network and thus share services. It would be handy if said router/AP was also connected to the internet. How many times has someone had a laptop in your car and just wanted to surf the net or check email from their own machine.

Anyways, I am getting off subject. I guess the real reason I want a flex/flash front end is because I am a flex/flash programmer :-) That and I want complete control over the skinning process. I suppose one approach that might make us both happy is to simply have the GUI in Flash. There was one such project that I saw awhile ago that was a java back-end with a Flash front-end, don't think it went anywhere however (Velocity?). I need to check out QCar also, I followed it for awhile, but have not looked at it in at least 6 months. Does the OBD support work with Nissan engines? (I have a G35 and would love to switch to a Mac setup, but the mac software was lacking when I installed last summer).

Thanks for the input! I am sure I will pester you with questions as they present themselves.

I've used the cairngorm framework and more recently have been doing some work with the pureMVC framework for Flex. Flex also has great support for Modules and makes loading and unloading a dynamic set of modules (SWC's) as easy as any language I've seen or used.

I will keep this thread alive with updates and ideas. I will not be back to my fortress until Jan 4th, so it might be quiet till then.

Thanks all,
-ikon

Originally Posted by ikon240

As I imagine this feature, it would not be dependent on the internet at all. The "web server" would be your carpc. The "clients" would be other carpc's. The "internet" would be peer to peer connections via wifi.

The range is not sufficient. Our primary idea was that this would be used when you travel with friends for holiday etc. If you can keep a closed motorcade, you do not need to see the position of your friends on the map. It is when you get separated (traffic lights, accident, dense traffic) when you need this function most. Then wifi becomes tricky at least, especially in cities with a lot of em noise.

I agree peer-to-peer or some sort of car-based broadcast would be the best solution. We have experimented with wifi (built-in modules, external APs, USB modules) and external antennas and ham radios. Wifi is a dead end. Shortwave radios do work (some can even work together with handheld radios and exchange positions with them), but they are expensive (USD 700 and up for usable models) and subject of many legal regulations and restrictions. The only thing that works acceptably is exchanging the positions via internet and a central server - but then we have the issue of prices for data transmission.

If someone sees a way out of this, I am all ears.

Good to know...

I have merely thought about all this stuff for the last few years, while the likes of you have been doing it, so major props there!

Wonder if WiMAX will become viable? Damn it, if they would just put the NetShare app back in the iTunes store!

Any chance QCar could be made to leverage a Flash/Flex front end?

Maybe next Christmas!

-ikon

http://roadnav.sourceforge.net/doxyg...nav/index.html

Here might be a candidate for use with Alchemy. It is LibRoadNav, the main workhorse library behind RoadNav (suggested by BugByte). It is responsible for getting the map data from online sources (cached thereafter), as well as doing the routing functions. The Alchemy docs say the compiled AVM2 code runs 2-10 times slower than the native code... BugByte, how fast is the routing in RoadNav? Would this slow down be acceptable usability wise? Otheriwse, Jirka makes the point that routing is fairly CPU intense. This is why a Java app that does the heavy lifting (routing) and sends data back to Flex via Merapi would not slow down the front-end like this approach would. Still, might be worth a shot.

-ikon

One more issue - what about stability and user interface response? In QCar, we were first implementing all functions inside the main app using threads, but even so, there were issues with UI getting slow and frozen for a few seconds when there was some exception (this is rather common when communicating with serial devices or network if there is a problem with the connection). So in the end we kicked out the potentially problematic tasks into separate processes so the application itself is not affected if something goes wrong (the app can then kill and re-launch the processes as needed).

The routing is CPU-intensive, but quick access to the data is a much, much worse problem. You would typically use something like A* algorithm, which means you have to be able to retrieve list of edges, that start in any node you are processing. And this must be done extremely quickly.

Just in case someone considers using a relational database such as MySQL or FrontBase for this: it is easy, logical (the map attributes come as a set of related tables), but it is nowere close to the speed you need. These DBMSes are good for complex queries returning large rowsets, but not for thousands of primitive queries per second... Been there, done that :-D (or :-( ?)