<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello, <div class=""><br class=""></div><div class="">Here is my 2 cents on this.</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- 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 ( <a href="https://automapper.org/" class="">https://automapper.org/</a> ) to map entities to DTO objects before sending back the response. </div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Sebastien Darveau</div><div class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 15, 2020, at 3:00 AM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">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.<br class=""><br class=""></li><li class="">Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.<br class=""><br class=""></li><li class="">The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">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.</li></ul></div><div class=""><br class=""></div><div class="">So, my proposal is:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">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.<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">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).<br class=""><br class=""></li><li class="">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.</li></ol></div><div class=""><br class=""></div><div class="">I am happy to build the framework for this, but would much prefer others to come on board to assist.</div><div class=""><br class=""></div><div class="">Any thoughts or suggestion are most welcome.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div></div>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>