Does anybody know what is the timeline of the LiveView native project? Whether there will be something we can use to build iOS/Android app out this year or it’s more like 2024?
There was an update posted a few days ago and it looks like there are opportunities to get involved, too: https://dockyard.com/blog/2023/01/17/liveview-native-yearly-update
3 Likes
Sorry I don’t monitor Elixir Forum very often but I wanted to get back to you.
I just recorded an Elixir Roundtable on LiveView Native progress but that episode probably won’t be out until early March. The tldr; is that we’re about 50% complete on the SwiftUI views. Progress in the past few weeks has accelerated as we took a few steps back after ElixirConf to extract out common LiveView code into a Rust lib we call LiveView Native Core. I made this call so that we’re not maintaining a new implementation of the LiveView client and Phoenix Channels code across every client. Now we have a single place to absorb and correct to changes upstream in LiveView itself.
The Jetpack Compose client (Android) should see a set of major PRs merge this week (pending review) at which time that engineer is going to pause on the Jetpack client and move over to help accelerate the SwiftUI client.
We unfortunately have limited resources at DockYard and I decided that getting the SwiftUI client done faster is a higher priority. This also allows the Jetpack engineer to see how we’ve been building the SwiftUI client and better align the architecture of the Jetpack client when he moves back to that client. I anticipate that will happen sometime in April or early May. The good news is that Jetpack is considerably less complex than SwiftUI to implement. So I am hoping that while we’re losing a lot of calendar time we’ll make it back up in the aggregate as there is simply less work to do for that client.
14 Likes
Does anyone have some example code that uses forms with Native LiveView? I made good progress getting an IOS app to connect to my liveview and I want to progress it further. Basically I would like to know how I could implement a login form using SwiftUI to my phoenix app. I cant find any code example of how forms are handled in this scenario, if anyone has something that could get me pointed in the right direction I would be appreciated.
Sorry about not responding earlier as I don’t watch ElixirForum. But we have a repo for this: GitHub - liveview-native/liveview-native-live-form
1 Like
Related conf…
1 Like
Excellent, this is just what I was hoping for. Next up, trying to figure how to do manage auth in a liveview native IOS app
It’s on the roadmap but we intend to add a key/value store to LiveView Native Core with a similar API to LocalStorage. We should be able to use events to store and retrieve from the client store from the server over the LV connection. While it isn’t spec’d out yet I image we can have different categories of store where what we push into one particular store is something that is always included in the initial connection so auth can be made easier.
1 Like
I havent had the time to look at this but my initial sense was that I would have to figure out a way to submit a separate login form in swift to a phoenix auth endpoint, store the resulting cookie somewhere and then use that with the liveview interactions. In regular web based scenario that was fine because of the nicely generated auth forms and plugs. I have seen recently that login can be implemented entirely over the liveview/socket, is it possible for me to login using just the nativelive view over the socket? For people used to webdev (and not IOS/swift) a solution like getting/setting LocalStorage would be convienent for lots of settings and whatnot. I feel like the less Swift/IOS I have to learn the better but of course it cant be avoided completly. That said, the thing that really interests me here is that once logged in is sorted, I feel like liveview native can do so much without having to write swift code.
Thanks again for your follow up
We do respect the cookie in the web socket but we aren’t really making use of it right now other than properly forming the LV websocket connection so storing within the cookie wouldn’t be possible from the server. But LvieView Native is just another SwiftUI view and I guess if you are OK writing Swift you can implement that solution.
This particular use case is very common and one we definitely need to optimize for. We’re aware of it and once we get through the work on getting Core aligned with upstream LiveView to feature parity adding the localStore I think will be the best long-term solution
3 Likes
