[Ovmsdev] NL: iOS app - Add Cabin Temp and HVAC state

Mark Webb-Johnson mark at webb-johnson.net
Wed Jun 24 10:22:25 HKT 2020

Those two metrics are available in v2 protocol:

Both in doors5, as part of the “D” message

So, the iOS App should have them delivered. But the iOS App doesn’t handle anything beyond doors3 in the “D” message at the moment. That would not be too hard to add, but you’d be unlikely to get the change 100% without an ability to test. Displaying on the screen itself is probably not too hard. Apple has some new requirements for App Store submission, including requiring support for apple sign on, that I am not sure if we now meet (so getting this approved maybe a hassle). If someone makes the change, I will try to get it through.

Unified App

I have been concentrating on the unified app recently, rather than trying to extend the iOS specific App. But it is hard going, and a real struggle. I’ve got forty years of programming experience, but am very new to these unified frameworks.

Compared to the native app frameworks, these unified app frameworks are a mess. Poor documentation. Breaking changes on every version upgrade. Outdated example code. Unmaintained libraries. The open source ones are like perl - 10 libraries to do variants of the same thing and no idea which one is the best. The majority simply don’t work on the latest version of the framework. I like Xamarin (which doesn’t suffer front too many of these problems), but it is just too proprietary for my taste (and I am scared MS will shut it down, or restrict it in some way). We use Monaca (phone gap based) at work, but it is just too restrictive and too ‘webby'.

I have decided to try to implement the App in react-native, which seems to be the most up-to-date and modern of the open source frameworks. It is certainly fast, but the breaking changes in each new versions are a nightmare for those new to the framework (like me). Any example code / library more than a few months old just doesn’t work properly. The nice thing about this framework is that so long as we stick to pure javascript, we can self-publish a development version of the App, and load it remotely from the ‘expo’ client that runs on Android and iOS phones and tables. It is incredibly quick to iterate through changes, without all the code signing crap, App Store approvals and delays. We would still use the app stores to publish final versions. For example, my current first couple of evenings very basic attempt at building using this framework is here:

https://exp.host/@markwj/Open-Vehicle-React-App <https://exp.host/@markwj/Open-Vehicle-React-App>

Install the expo client, point the camera at that QR code, and the App will be downloaded and run locally. Some comments:

Status tab is for vehicle overall status. This is a web view, and will be loaded dynamically (with callbacks to be able to retrieve metrics, issue commands) for per-vehicle-type and per-customer customisation.

Vehicle tab is for vehicle environment status. Same as the status tab, this is a web view.

Location tab is a map.

Messages tab are chat style messages for talking to the car.

Settings tab will change in this app, and will be for settings of that particular select car.

The above tabs may change (in particular, I am not sure about status and vehicle tabs - perhaps we need just one, and then have some customisable way of having multiple screens per car type. I don’t like that it is fix to two screens. So I am thinking maybe just one screen, with tabs along the top, or swipe, to switch between pages.

Swipe left for the menu drawer. This is where the list of your vehicles will be, as well as menu options (create new vehicle, etc).

The basic ideas behind this are unchanged, as I outlined before. Vehicle API agnostic, central metrics store, user customisable display, etc.

I'm working in the open on this, committing as I go along. So dozens/hundreds of little commits, often correcting each other. It is a prototype, that I am using to just test each of the technologies we need (e.g. can the web view retrieve metrics from the app), can we support websocket connections to OVMS v2 servers, etc. I have no idea if it can become a production App, but so far it seems that it can.

If anybody wants to jump onboard and help, that would be most appreciated. Especially if you have javascript or react experience. Likewise, if anybody wants to try this in another framework, that is also possible. At this point, I am simply not sure what is the best approach.

Regards, Mark.

> On 23 Jun 2020, at 6:45 PM, Jaunius Kapkan <jaunius at gmx.com> wrote:
> Hi,
> Can someone guide on the best approach here. I have no access to MAC so it would be more of a trial and error approach.  Current view:
> <0dddcf99-4faa-4b3a-a523-da98780ce30d.jpg>
> Metrics:
> <f370a907-df44-4b55-bf0a-b7eb11ef1382.jpg>
> Or are we close to the unified app for both iOS and Android and I should wait?
> Regards,
> Regards,
> Jaunius Kapkan [Sent from cellphone]
> _______________________________________________
> OvmsDev mailing list
> 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/f9eefcad/attachment.htm>

More information about the OvmsDev mailing list