(((I have decades of real-time and GUI development experience, but am relatively new to Android.)))
Freelancers: Budget is just for best initial feedback.
I will be hiring out the development of an Android automotive app for use in race cars. In essence, it replaces the dash. So it needs responsive and nice looking automotive style gauges in the GUI, and it needs an architecture that can properly handle the real-time data coming in via USB.
I'm asking on this forum for suggestions of:
1) open source tools and platforms that can make app development faster and more robust, and
2) methods and techniques to further assist.
Be aware that this app MUST run on the following hardware: Teclast P80H. Android 7.0. Security Patch Level January 5, 2018. Kernel version 3.18.35. Build number V1.04_20180201. CPU Modem MT8163. CPU Kernel number 4. 1GB Ram. 8GB Flash.
============== PHASE 1 - DESIGN ==============
MILESTONE 1: 75$USD
1) Location two or more UI gauge drawing toolkits. Please provide me with links pointing to each toolkit overview as well as to example gauges drawn by each toolkit. Note that we want attractive looking gauges. I'll send you some examples of acceptable and unacceptable gauges. We will probably have to go back and forth on this a little. The toolkits should have the ability for us to replace the background image. (This seems like it *must* be possible, since we should have the source code.)
2) Write or draw a VERY, VERY SIMPLE design for the communication between the low level data layer of the software and the high level UI graphics layer. The data layer will be either my existing USB software, or a data simulator that YOU will be writing. The high UI graphics layer will be using the UI gauge drawing toolkit. We will surely have to go back and forth on this a little. For now, however, I'm really just interested in the TECHNIQUE, not the details. So this might be a single written paragraph. Note that this design must cope with the possibility that new data arrives faster than it can be drawn. So in order to prevent the display from developing a lag or delay between real-time data and display, it will be necessary to sometimes drop data. For example, the RPM might change from 5000 to 5010 to 5020, but because it's changing too fast, the display might only show 5000 then 5020.
MILESTONE 2: 75$USD
3) With choices made above, please write AND draw a DETAILED design for the communication between data layer and UI graphics layer. This will include a definition of the protocol and the timing, including how decisions are made about dropping data. I will want this to end up in Microsoft Visio. If you can originate the drawing in Visio, then great, please do so. Otherwise, note that I will be reproducing your drawing in Visio and so you do NOT have to make your own drawing "perfect".
4) Explain how you'll create the data simulator. To begin with, it should use a 1ms timebase and produce 5 channels as follows:
4.1) RPM channel varies back and forth between 3000 and 7000 rpm, 10ms/sample, 10rpm change per sample.
4.2) Four Exhaust Gas Temperature (EGT) channels varies back and forth between 1000 and 1400 degF (degrees Fahrenheit, I can't type a 'degree' symbol here). The [change per sample]/[sample rate] for the four channels should be 1:[10degF]/[99ms], 2:[5degF]/[49ms], 3:[2degF]/[19ms], 4:[1degF]/[11ms].
I have intentionally made the timing so that the arrival time of values from each sensor will get all mixed up.