Add Content to README.md

[wba2hi]

Our README.md right now is just a plain stub with no actual content. We should fill it with a motivation why this repository was created and short description of the requirements needed to get the app up and running.

[eriksven]

Having such a description on how to get started would be awesome. I just installed Android Studio, checked out this repository and started the app through Android Studio in an Emulator. But I was not able to connect to a KUKSA data broker which runs on the same host machine. Do you maybe have a hint what I could have forgotten? (The OS of the host machine is macOS)

[wba2hi]

@eriksven Thanks for your feedback, we will keep it in mind when updating the documentation!

w.r.t. can you please test using the host 10.0.2.2 when connecting from an emulator to your host computer? The 10.0.2.2 is the predefined host loopback defined by Android, see: https://developer.android.com/studio/run/emulator-networking

Edit: Please also note that running the mock service is required to correctly process the actuator events we send from inside the app (to simulate the interaction with the car). You can find the corresponding mock.py here

[eriksven]

@wba2hi Thank you for the two very good hints. I got the connection working with the host 10.0.2.2.

[wba2hi]

@eriksven I tried to add some documentation, it would be cool if you could take a look and add comments or highlight things which are missing from your point of view.

[eriksven]

Great, I will have a look.

[eriksven]

The PR looks good to me and I left some very minor hints.

From my point of view, it would be great to also have some kind of basic user guide of the App itself. But we could do this in an additional PR.

This would explain the different Views (Doors, Temperature, etc.) and which element in the UI is controlled by which VSS-signal. I was also considering to propose to have a full example where a user changes a signal in the Databroker through the Python Kuksa Client and then sees the result in the App. But the essential pieces to do this are already documented in the pages linked from the documentation. So there is the risk of needing to keep the same content in synch down with any future changes to the Databroker. WDYT?

[wba2hi]

The PR looks good to me and I left some very minor hints.

Thanks, adapted accordingly!

From my point of view, it would be great to also have some kind of basic user guide of the App itself. But we could do this in an additional PR.

This would explain the different Views (Doors, Temperature, etc.) and which element in the UI is controlled by which VSS-signal.

Since I'm pretty uncreative on how to describe the different views with more than one sentence I only added a block on which signals are used: https://github.com/eclipse-kuksa/kuksa-android-companion/pull/50/files#diff-86a7695eb7559a8d3b6914182edf3330d1ebb137bff7455cd342daf24d44ebb6R82-R127

We can create a follow-up ticket for explaining the different views in more detail maybe with the addition of screenshots and even a common terminology where to find which element (NavigationBar, ConnectionStatusBar, Settings, Reconnect button etc)

I was also considering to propose to have a full example where a user changes a signal in the Databroker through the Python Kuksa Client and then sees the result in the App. But the essential pieces to do this are already documented in the pages linked from the documentation. So there is the risk of needing to keep the same content in synch down with any future changes to the Databroker. WDYT?

I tried to not add redundant information from other repositories. If our interfaces change, we have to keep the information in synch. That's also the reason why I only refer to the original repositories to "set things up" instead of going through these steps in detail. But you are right, maybe it makes sense to at least mention the tools at hand, like adding a small comment about the KUKSA CLI and where to find it, so people know that there are alternate ways to change the data.

[eriksven]

I tried to not add redundant information from other repositories. If our interfaces change, we have to keep the information in synch. That's also the reason why I only refer to the original repositories to "set things up" instead of going through these steps in detail. But you are right, maybe it makes sense to at least mention the tools at hand, like adding a small comment about the KUKSA CLI and where to find it, so people know that there are alternate ways to change the data.

Makes sense to me and referencing the KUKSA CLI is a good addition. I will prepare a PR for that in the next days.