mmmrrr
Brainstorming on a mobile companion library for LiveView
Hey everybody. I’m currently working on the reimplementation of an app and we’re using phoenix coupled with Turbo and Stimulus. The only reason we didn’t went with LiveView is turbo-ios which is a fantastic library for a native iOS client: it’s very lightweight (the whole “framework” is only around 3000 LOC) and allows you to build hybrid apps fast.
The idea of this companion library (it also exists for android, too) is to have native navigation and web content. The UX is really great, since turbo will cache a lot and hence navigation feels instant in many cases. For the most part it feels like a native app. You can also simply mix in native views easily (for example maps, code scanner, login screen, or whatever makes sense for your application).
The downside to all this is: while the programming model, of only having to send stateless html pages over the wire, seems very simple at first, it gets really, really hairy after a while. Breaking the application down is done via turbo-frames which you can update in place through “turbo-streams” (which we feed through phoenix channels). You also have to always pick the correct http verb when sending data so that turbo will react the way you intended - which is not always as easy as it sounds.
Enough praise/rant, I’d like to build something like turbo-ios/turbo-android but for LiveView. I think the main features would need to be:
- Native navigation patterns (one web view that gets reused and rendered inside a native navigation stack)
- Patching native components through LV
- “caching” already visited pages (i. e. display screenshots/cached html of the last visit even when offline)
I could have started by simply forking turbo-ios but I don’t know enough about the internals of LiveView to decide if this is something that is feasible at all or if there are currently some properties preventing my envisioned use cases.
Also I’d like to learn about prior art in this space (for example, I know about elixir-desktop which is very, very interesting, but not what I’m after).
Most Liked
AstonJ
This sounds really cool and I was going to suggest you look at Elixir Desktop.. but looks like you’re already aware of it
Any reason in particular why it’s not what you’re after? Would your project just be for iOS/Android?
Either way good luck, I’m sure a lot of people will be interested in seeing what you come up with ![]()
mmmrrr
Yes! elixir-desktop is just the opposite of what I’m after: it is an app running on the users device rendering all UI elements with web technologies.
What I want to achieve instead is a wrapper using platform native, navigational UI elements and displaying content and cross platform UI elements generated by a central server. (Like described here for Turbo: Basecamp 3 for iOS: Hybrid Architecture - Signal v. Noise)
And this also answers the second question:
Probably, since I don’t have use for anything else currently, but in the end it would be possible to write such a wrapper for any platform that can display a web view. The main problem will be to define the api making the communication between LV and the “native” components feasible.
yukster
FWIW, there are some folks working on a library to bring LiveView to JSON objects: GitHub - Miserlou/live_json: LiveJSON - LiveView for JSON · GitHub. Theoretically this would allow your native app to benefit from the dynamic data updates pushed by the server.
Last Post!
mmmrrr
turbo-ios is very much imperative and not reactive at all. So you simply have an API/bridge where you communicate between the web and the native part and other than that you basically have two separate applications.
So my initial idea was to do something similar: simply render hidden components that have a native counterpart and then parse the needed info out of the dom to update the native components. But in order to do that I’d need to hook into the live view lifecycle to know when an update is done. (Thinking about it, this could also be done via LiveJSON, as @yukster suggested)
I also think it is extremely important for such a companion framework to be as simple as possible.
Thanks for all the input ![]()
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









