[Ovmsdev] Cross Platform Unified App

[Sébastien Darveau]

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/ ) 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 at webb-johnson.net <mailto:mark at 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:

1.	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.

2.	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.

3.	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.

4.	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).

5.	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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com> 
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200624/2931b7d4/attachment.htm>