Android implementation

[birkir]

Stumbled upon this implementation initially borrowed from Shopify.

https://github.com/jqn/AndroidAutoExample

If I were to port this over to our repository, would you like to rename this library to something more generic?

react-native-auto
react-native-car
react-native-vehicle

Or just stick to CarPlay

[gorbypark]

If this one repo was going to support both CarPlay and Android Auto, I'd vote for react-native-vehicle.

[tomdye]

agree re. react-native-vehicle

[DanielKuhn]

There's active development for android auto in doublesymmetry/react-native-track-player#2094
For anyone using react-native-track-player for audio playback this looks very promising.

[nicomontanari]

Hi @birkir, are there any updated about the Android Auto implementation?

[susonthapa]

I do have a repo for Android Auto. I worked on it a while back and I have implemented a couple of features. I started from Shopify's Android Auto.

I'm planning on creating a new repo that integrates both Android Auto and CarPlay. I'm thinking of rewriting the CarPlay implementation from scratch as Android Auto uses a declarative approach. I would definitely take inspiration from this repository.

If anyone is interested feel free to contribute. This is the link to the repository, it is currently empty 😂, I will integrate Android Auto.

[nicomontanari]

@susonthapa sorry for the basic question, but why not implement the Android part in this repository? Then you could change the name of the library and repository without starting another library from scratch

[susonthapa]

@susonthapa sorry for the basic question, but why not implement the Android part in this repository? Then you could change the name of the library and repository without starting another library from scratch

This is just my opinion so I don't expect everyone to agree with it. This library uses an imperative approach, and changing it to declarative would be a huge undertaking not to mention that it is written in Objective-C which I think is quite outdated.

After working on the Android Auto library and this library(more or less), I think the declarative approach is the way to go. Either way, I'm just sharing something I worked on.

[nixolas1]

Awesome stuff, @susonthapa ! Will definitely keep an eye on it, and maybe help out when we start CarPlay & Android Auto development :)
Especially if it has some Expo support

[birkir]

@susonthapa sorry for the basic question, but why not implement the Android part in this repository? Then you could change the name of the library and repository without starting another library from scratch

This is just my opinion so I don't expect everyone to agree with it. This library uses an imperative approach, and changing it to declarative would be a huge undertaking not to mention that it is written in Objective-C which I think is quite outdated.

After working on the Android Auto library and this library(more or less), I think the declarative approach is the way to go. Either way, I'm just sharing something I worked on.

I’m actively working on the platform integration for Android Auto. A significant part of this effort involves bridging the differences between CarPlay and Android Auto, creating common templates, configs, and types, which I’ll document in detail. Expect updates on this soon.

Regarding the debate on whether imperative API is a bad approach for template API proxy. It’s actually the primary reason I didn’t chose the reconciler route, I’ve done some fiber work in the past.

With AA it makes a little bit more sense, as the platform has few more cases like the map template. But I’d still stick with imperative and offer declarative react for free-form rendering. Heck, I think RN-carplay could easily be sugarcoated with a reconciler on top of the current API, if that's the verdict we want.

I don't think that Obective-C is necessary a bad thing, worse dx for the library mainteners but easier for users and I feel the same with Kotlin, is it a no brainer today or are there still compatability/conflict issues like it used to a year ago?

Great discussion 👍

[susonthapa]

Thanks for the info @birkir. I didn't know you were actively working on AA. Looking at the comments I thought AA won't be implemented anytime soon(my bad 🙂) so I took matters into my own hands.

I think I might have created confusion around the declarative and imperative approaches. The native library will still expose the imperative API, but the reconciler will expose a declarative API.

I'm not familiar with Objective-C so I don't know what limitations were there a year before. I find it very difficult to work with Objective-C(and even Swift, I'm originally an Android developer so maybe that's why 🤷‍♂️).

I don't want to create another implementation for the same thing, Do you have a branch or a repo where you are doing the work? I will be more than happy to contribute. I kinda have a deadline for adding AA support on one of the apps that I work on so I was just building what I can. In the meantime, I will still be messing around with my implementation.

[birkir]

After looking at your repo @susonthapa I am pretty sure I will start pointing the work towards your implementation, you seem have gotten the furthest in terms of building the parser. Just need to start using Kotlin, not a big deal.

I am currently jumping between these implementations - so my working branch is a hot mess atm 🔥

• https://github.com/Shopify/react-native-android-auto
• https://github.com/jqn/AndroidAutoExample
• https://github.com/susonthapa/react-native-android-auto

But what I can do is start a PR with changes that makes sense as a starting point.

1. Make Android example app working.
2. Support Android Auto in example app manifest
3. Add my documentation updates, which so far only covers ListTemplate and a bunch of other things.
4. No implementation at this point, because what I am unsure about is how to manage the react context (another entry point, registerComponent or something else). I'll just put a random screen up there.

#151

[susonthapa]

After looking at your repo @susonthapa I am pretty sure I will start pointing the work towards your implementation, you seem have gotten the furthest in terms of building the parser. Just need to start using Kotlin, not a big deal.

I am currently jumping between these implementations - so my working branch is a hot mess atm 🔥

• https://github.com/Shopify/react-native-android-auto
• https://github.com/jqn/AndroidAutoExample
• https://github.com/susonthapa/react-native-android-auto

But what I can do is start a PR with changes that makes sense as a starting point.

1. Make Android example app working.
2. Support Android Auto in example app manifest
3. Add my documentation updates, which so far only covers ListTemplate and a bunch of other things.
4. No implementation at this point, because what I am unsure about is how to manage the react context (another entry point, registerComponent or something else). I'll just put a random screen up there.

#151

I started with https://github.com/Shopify/react-native-android-auto and fixed a lot of issues there. I have also implemented the MapTemplate which was quite hard. Unlike CarPlay where you can access the Window and tell ReactNative to render there, AndroidAuto only exposes a SurfaceContainer. I had to resort to Virtual rendering but I got it to work. This is how it looks right now.

Kapture.2023-10-26.at.18.49.33.mp4

The Redbox is being rendered from React, we can render anything in there including a Map.

@birkir Let me know if you need any help with the implementation of Android Auto.

[birkir]

Awesome! Haven't tried to render a map or anything dynamic, but hope it will be smooth. I guess it is also how iOS CarPlay works behind the scenes.

Quick question,
https://github.com/susonthapa/react-native-android-auto/blob/main/android/src/main/java/com/reactnativeandroidauto/CarServiceSession.kt#L43-L65

Any concerns about doing it this way? Are we limited to any specific RN version or all good?