0

We are starting a total new Branch at our firm. I am usually developing database interfaces or internal server/client applications/tools for our company, but I never had to do something with hardware.

Szenario

My Boss want to sell a device, which has a touch-screen to set up the many, many features. However, the configuration of the device can be very time consuming. He wants to give a software free for a good customer and for a litte charge to "small" customers. The customer should only be able to use the software, if he registers at our system, so that he can't copy the software without a notice by us.

Requirements

The device has a build in USB cable. If you plug it in your computer it opens a new COM serial port. The software has the following requirements:

  • Configurating different presents for the device
  • Reading and writing the presets to the device
  • Software will refuse to start, if the user has no registration at our server
  • The user can store his presets at our server and share it with other customers
  • One preset, copied over and over to multiple devices

My boss has seen similar system (he said something about logitech harmony remote controls) and it is now on me, to create the architecture.

Server Side: The server is not that kind of problem. We have enough different machines to suite any kind of favour (IIS, LAMPP, Apache/Tomcat etc.) I could take MSSQL or MySQL DBase to store the data, thats not the problem.

Client Side: This is the tricky part for me. I never did something with hardware. My boss suggested I should use Silverlight. I claimed that I want to do it with a native application. But what is the best combination?

  • Total Client-Side (C++, C# or Java are the languages I could write)
  • Mixed Structure #1 Silverlight + Native "Driver" Application
  • Mixed Structure #2 Java-Applet + Native "Driver" Application
  • Browser Only - Silverlight or Java-Applet?
  • Any other suggest

The device is for a special customer group who's getting personal trained with any purchase so security risks like unsafe code or dangerous browser plugins are no negative selling argument.

I did some research about COM Serial Port connection with Silverlight and P/Invoke but I don't want to start without a discussion what would be the best way.

Ello
  • 144
  • 1
  • 4
  • Slightly off topic but knowing that the config tool cost extra would be enough of a reason for me to buy from your competitor. You're never going to sell enough copies to make a profit or even offset development costs, why even bother trying to set it up as a product? – Sean McSomething Sep 24 '13 at 18:24

3 Answers3

2

Definitely stay away from Java applets and Silverlight. Both are tricky for users, error-prone, and their future is uncertain at best.

The only tricky part is the client.

For client, I'd take a well-supported cross-platform language. Unfortunately, you can't be sure that a runtime for such a language is readily available on a client machine. So bring it with you.

I'd take Ruby, Javascript (node.js), or Python. Either has a relatively compact runtime, and either allows to create an self-contained standalone app from your program. Accessing COM port should not be hard from any of them. Accessing your server, even easier.

Your client app will likely require a GUI. I'd go for a web UI: start a local web server, stop caring about cross-platform GUI toolkits and the like.

I'd build a version of a client for each major OS type (Windows, OSX, Linux) without much (if any) code modifications, and would distribute it with the device.

The server part is not tricky; use whatever technology you like. For the client-server protocol I'd use REST over HTTP(S); it has the fewest problems with any kinds of network setup, firewalls, etc. It also has excellent tools for troubleshooting.

Another tricky part is server-side authorization. It'd be best if your device had an unique ID, because your program would be much easier to crack than a hardware device.

I don't see why this is needed, though. It's the device that brings you profit. You can't sell more of your support software unless you sell more devices, and the support software is useless without a device. I'd just give the software away. Your software is not unlike a driver. See, graphics cards manufacturers allow to download their huge and sophisticated drivers for free, and feel fine. So will you.

9000
  • 24,162
  • 4
  • 51
  • 79
  • Thank you for your respond. I don't understand the whole "do not allow to copy" part either, but my boss want it that way. You gave me some points I need to think about which could help me in creating the architecture. – Ello Jun 12 '13 at 07:51
0

If the device doesn't have a network interface of its own, then there are three machines to consider for the use-cases where the device needs to access your server. The three machines are your server, the device and the computer from the customer that the device is connected to. The customer's computer must be considered, because it must act as a go-between in the data transfer between the sever and the device.

For the server side, it does not really matter what kind of technology you use, as long as there is a defined protocol for communicating with the device and your technology stack can handle that protocol.

For the device, you should use a technology that can run entirely on the device itself, as that allows some use-cases to be executed stand-alone.

For the customer's computer, you can use either a native or a browser-based solution, but for both you should consider which OS-es, respectively browsers are likely to be used by the customers and if you can support them all. For a native solution it might mean you would have to support several versions at the same time. Also, a browser-based solution might be considered more user-friendly.

Bart van Ingen Schenau
  • 71,712
  • 20
  • 110
  • 179
  • Thank you, yes browser based would be a much more benefit and a whole easier to maintain. But I am not familiar with the technical restrictions if accessing hardware over browser rendered software. I really don't want to use applets (Java / Silverlight) but I surely want to do it browser based if it doable without restrictions. – Ello Jun 12 '13 at 07:54
  • @Ello: I am not sure either about the restrictions in a browser-based solution, as I have never actually created one. – Bart van Ingen Schenau Jun 12 '13 at 08:00
0

I have done plenty of serial comms work over the years, and writing a native application is the way to go. It allows you to properly install the application and ensure it has sufficient OS privileges to access the COM port, rather than praying that the user's web browser is configured to even prompt the user to allow access.

You do need to consider some error conditions, such as the device being removed whilst you are in the serial comms code, but this is a viable route.

Question for you though, Why sell the devices un-configured and expect the customer to configure them, which means that they will generate lots of support questions when the process goes less than smoothly.

Why not preconfigure before you ship the device? There are bound to be things that you can do internally to simplify the configuration process when you are able to control the installation environment.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36