At the risk of repeating myself, VCDS-Mobile does most "non-invasive" diagnostics without needed a cloud connection, and of course, there's the ultimate back-up is to use the HEX-NET as an interface for the original VCDS program running on a PC.
All of our dongle interfaces have been "fully SW defined" devices for 12 years now, and they regularly get firmware updates.
Because Bluetooth works so well on everything, right?
I can assure you that the code in VCDS-Mobile is anything but bloated. It's amazing what you can do when you have true, native access to the
all of the hardware you're running on, and you're not at the mercy of the whims of someone else's OS.
There's a huge difference between "Cross platform" and "Platform native", and you're now mixing the two.
In the end, I understand that it's impossible to please all the people all the time. What I did 14 years ago is make the product that I thought was right for the times, and that was a "Platform Native" 32-bit Windows product, because that was by far the dominant computing platform. Of course there were people that complained that it didn't run on their old, obsolete Windows 3.1 (or even DOS) laptops, and there were people that complained it didn't run on various other niche platforms. What we've done now is to make the product that I believe is right for these times, and can be used on ALL modern computing platforms. If it's not right for you, well, OK, I guess you won't buy one. I can accept that.
-Uwe-
Your code is not bloated because it is clearly *NOT* platform independent - it is locked to the HexNet hardware. All you have done is decouple the display. . . Good for performance in the device, not so good for interactive display response. (And one of the reasons that the product I work with didn't consider going that way . . . . it just plain didn't work for us, we require a far more realtime gui response . . . ).
The dongles are SW defined, but more at a firmware level. I think, realistically, that the frequency of update (and corresponding risk of sw upgrade failure) will be lower than for HexNet, but that remains to be seen over time.
RE Bluetooth, I have yet to have a device fail me - headset, OBD device, or dive computer (yeah, it's an oddity . .. ). I am not a heavy user, but for me it's been 100%. I suspect that the bulk of issues, once again, are companies trying to circumvent the standards, and do proprietary things . . . . and shoddily written Windows driver code by idiots right out of school . . (but hey, they work CHEAP!!!!). The bottom line is don't blame the protocol/standard for bad implementations!
And I am working on the definitions of 'cross platform' and 'platform independent' that I see as a senior engineer with global scope in a Fortune 100 (maybe 50) technology company, so I think my definitions are 100% on point. (I choose to not name my employer, since it is not relevant, but if anyone wants to know, ask and I'll consider "outing" myself
).
Different markets, but my users will *NOT* tolerate single platform tools, so we accommodate. Your either do, or tolerate being forced to a platform due to the unique nature and high value of your product. And likely your volume is low enough to not warrant anything else based on volume. I just take exception to folks that claim technology reasons to not support alternate/superior platforms - that dog won't hunt! The issue is almost always $$$ and the lack of desire, funding, or justification to do so - not technology.
What you have done is not a bad approach, and the main thing that chaps me is the connectivity requirement. You say it can do most things standalone, or go grab the Win box (that this is designed to eliminate the need for . , ? ? ). The first case is like an adjustable wrench that can do any size but 1/2". . .seemingly unimportant until it fails you - and the second purely hypocritical, and continues to display your naive belief that everyone has a Win box . . . Since one of the main goals was to eliminate that requirement.
Oh, and pick a standards defined OS (which Windows clearly is not!) and you don't have much in the way of issues moving forward. Choose a propritary/predatory vendor who has vested interest in making everyone keep $pending for upgrades by deliberately breaking thing, and you get what you asked for. I note that in the high end IT marketplace, very few devices these days are not based on an open-source standards based OS under the covers . . . simple because it's more stable, faster, cheaper, and far, far, more supportable . . .
And does this imply that you are 'ground up' in HexNet and wrote 100% of the code in it - no embedded OS or other drivers or tools? If not, I would argue that you have the same issue, but get to control the timing - IE you users won't be upgrading without figuring out if things work or not, and then blaming you for thier bad judgement! You get to evolve the platform when *YOU* want to, which is definitely a good thing, much like selling a standalone tool, either handheld, or locked down task specific PC based.
Since you have all the VCDS intelligence decoupled from the display platform, have you considered adding a display and making a standalone device?
And lastly, thank you for taking the time to have this discussion! As you likely know, I do own your wired product, and it's already paid for itself!
- Tim