Support input element (Issue #726)

[TAKeanice]

This adds the widget type Input

[TAKeanice]

Date input types not working yet, because the alertview layout breaks when adding it. Also, numbers are rounded, but that could well be is due to rounding in the backend. Otherwise works like a charm.

[TAKeanice]

I now added the date and time picker directly to the cell. They show strange behaviour because they often reset when changing the date though.

[timbms]

LGTM
@digitaldan : Can you please have a look.

[mherwege]

First of all, I very much appreciate you are implementing this for ios. I introduced the functionality in sitemaps and implemented it in BasicUI and the Android app. I use an Android phone and an iPad, so always wanted this available as well.
I however don’t have a clue about development for Apple, I don’t own any Apple devices but an iPad. So I am of little help in reviewing the specific development. I am willing to test if there is a test version but would need instructions how to do it.

I noticed this comment:

They show strange behaviour because they often reset when changing the date though.

Any idea why it resets? Could it be partial updated info is sent, and comes back from SSE events, and updates it again while still editing? Or is it an issue with the DatePicker?

[TAKeanice]

Any idea why it resets? Could it be partial updated info is sent, and comes back from SSE events, and updates it again while still editing? Or is it an issue with the DatePicker?

I found some peace to review the issue of resetting values. Turns out, the date that I get with my particular test setup (item of type DateTime, corresponding sitemap input element with hint "Date") gives me a date formatted like "yyyy-MM-dd HH:mm:ss". I am sending an iso-formatted date so I expected the same back, and if I am sending the "yyyy-MM-dd HH:mm:ss" format it is not accepted by OpenHab... But anyway, it´s working now.

[TAKeanice]

By the way, interestingly, in the OpenHab items overview the date is shown in UTC and iso-formatted:

and in the item detail view it is formatted like I get it in the app plus in my local time (Germany):

[TAKeanice]

@mherwege for testing a feature branch on your local device you´d need a mac to compile the app, xcode, and (at least I had to do that) adapt some app group and -identifier settings to allow using your personal (unpaid) apple developer account to deploy it to your device. You could probably use all available simulators, too. Automatic upload of TestFlight versions by the developers for every feature branch would probably be too risky, since everyone could open a merge request with any content they want. Also, they would need a mac or pay for some service that provides a mac as build server to be able to compile those versions.

[TAKeanice]

I got the difference now: One is the widget label value and the other one the item state. Which is the better one to use? The latter is formatted in the same way that I must use for sending events, which seems a sensible choice...

[timbms]

@TAKeanice thanks a lot for this valuable contribution. @mherwege I will make a TestFlight release available when @TAKeanice is ready

[TAKeanice]

when @TAKeanice is ready

I am ;) Implemented the last change and tested it yesterday. Date changes work smooth like butter now