I did look into Xamarin forms, and tried to create some simple apps. I like it, but it is just too proprietary for my taste (and I am scared MS will shut it down, or restrict it in some way). I would prefer some open source approach. The documentation is however very good, and platform is stable, but examples not very helpful. I do like the way it allows a common UI (with forms), but still permits customisation on a per-platform basis. The framework app I tried to create in react-native is simply this: Tabs Vehicle (web view) Status (web view) Location (native map) Messages (chat ui) Settings (just a simple form based screen) Drawer style menu pulled in from the left, with arbritrary content Support for light/dark theme (autoswitched to the Operating System selection would be best) Support for Android and iOS If that is simple in Xamarin, and you have time, it would be useful to generate that template app in Xamarin (forms) so we can compare the two. Regarding the API, I want this App to be protocol-agnostic. Internally, it has a virtual vehicle with a set of metrics, messaging system, and set of commands that can be issued. Then we can implement the actual protocols and directly support things like Tesla’s API, Carwings, etc, as well as OVMS. This also makes it very simple to migrate from protocol v2 to v3 (or our http api). Regards, Mark
On 24 Jun 2020, at 9:10 PM, Sébastien Darveau <sebastien.darveau@synnoetic.com> wrote:
Hello,
Here is my 2 cents on this.
- Have you also looked into Xamarin.Forms? It is the equivalent display templated approach used by Xamarin for Multiplatform UI. It uses data binding to instantly reflect model changes and it is quite flexible. It usually goes with the MVVM (Model-View ViewModel) design pattern. I have a year of experience with it and I can help to start the project.
- I can’t really talk about vehicle-server protocols but for app-server communication, I would favour a well designed REST api. As for the low level protocol, I used to have a separate project containing only DTO objects that is shared by server and client as a submodule. This is the interface. Server uses Automapper ( https://automapper.org/ <https://automapper.org/> ) to map entities to DTO objects before sending back the response.
Regards, Sebastien Darveau
On Jun 15, 2020, at 3:00 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
As you may know, I’ve been working for some time on the design of a cross platform unified App for OVMS. Here are my thoughts.
I think our approach of the ‘virtual vehicle’, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.
Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.
The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).
I like the idea of providing a ’templated’ approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.
By leveraging the ‘virtual vehicle’ model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ‘virtual vehicle’. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.
So, my proposal is:
We develop a single universal App, coded in a ‘free’ open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.
The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.
The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.
The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).
I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.
I am happy to build the framework for this, but would much prefer others to come on board to assist.
Any thoughts or suggestion are most welcome.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev