I’m wondering about battery drain with both LiveView Native and LiveView. Doesn’t a persistent connection necessitate keeping the radios on (or at least, to switch them on frequently)? My understanding was that it would result in significant battery drain but maybe that’s outdated.
Mobile devices also have other constraints that could make LiveView less suitable:
spotty internet connectivity in some places
I assume that without internet, a user could scroll within the current view but any button taps would be ignored.
bandwidth limits on data plans
LiveView sends only diffs of the UI. But this could still be significant if the app lets users browse through images and if those images are not cached.
Spotty: yes. Note that this is rarely well handled by native and web app anyway in my experience, so it may not be a big problem
That is… The same as every app? The handling of images and what format you use compared to your connection and bandwidth is not dependant on the framework you use?
… this [bandwidth] could still be significant if the app lets users browse through images and if those images are not cached.
That is… The same as every app?
I was thinking that specifically the “if those images are not cached” condition would be more likely to be true with LiveView Native than with a native app. I know that browsers cache previously-downloaded resources, but I don’t know whether the LiveView Native runtime caches previously-downloaded parts of UI.
Edit: Sorry, I just realized I was mentally comparing LiveView Native with browsers, not with native apps. I don’t actually know if normally-written mobile apps cache resources like browsers do.
On iOS at least you’d only be able to keep the connection open reliably when the app is foregrounded, most apps these days would probably make a bunch of network requests at that point anyway. Although it does optimise these by batching requests together and turning the radio on at once. I wonder how big of a difference it really makes, I guess it really depends on the app and how it’s used. I agree with the sibling comment, there are other reasons this model might not be ideal for mobile.
I liked the idea of LiveView already, so it’s cool to see this spinoff arrive.
In general I don’t buy the cross-platform app framework marketing pitch. I don’t think there is any slam dunk that saves you money for the same per-platform native feeling result—the widgets are not enough. But this one has some unique properties.
As I understand it, and please correct my mistakes, shared code all moves to the server. It removes the need to have both client side shared code and an application API server, nor figure out the odd data interface differences between your web UI and your app UI. Maybe the best part is not having to describe app-level API operations since they are uniformly done by the server as UI state changes and updates.
UI code also moves into the shared thing in some sense. But you still write it once per platform. For example, in the SwiftUI templates it looks like you’re basically writing SwiftUI with a markup syntax, so you can be fully specific and get native behavior, but for other platforms you do it again. Where I come from in the mobile dev business, UI takes the bulk of the work. That makes me think it would be slow to develop and test the fine details of UI with these templates compared to the preview canvas in each native IDE.
I also wonder whether views are completely server side dynamic and if so what that costs—SwiftUI is built to know view hierarchy possibilities statically. I’m not clear on whether templates would be sent in full for a first screen view, needing structural dynamism, and then minimally updated, or whether templates would be baked into the app build, limiting what the server could then ask it to display.
But when I think of all the simple changes I could make that wouldn’t need to go through app review, I feel lighter.
It’s similar to Hyperview and Strada, yeah. The architecture of LiveView is a little different than HTMX/Turbo, but LiveView Native fits in the same part of the ‘stack’ relatively.
Slight nitpick: Jetpack is actually the collection of first-party libraries Google provides for Android development, which would make liveview-native-compose a more accurate name for the Android port since it’s using Jetpack Compose.
Other than that, very exciting to see the progress! I’ve been messing around with Elixir on the side and being able to make Android apps with it will be fun to explore.
I’m wondering about battery drain with both LiveView Native and LiveView. Doesn’t a persistent connection necessitate keeping the radios on (or at least, to switch them on frequently)? My understanding was that it would result in significant battery drain but maybe that’s outdated.
Mobile devices also have other constraints that could make LiveView less suitable:
I was thinking that specifically the “if those images are not cached” condition would be more likely to be true with LiveView Native than with a native app. I know that browsers cache previously-downloaded resources, but I don’t know whether the LiveView Native runtime caches previously-downloaded parts of UI.
Edit: Sorry, I just realized I was mentally comparing LiveView Native with browsers, not with native apps. I don’t actually know if normally-written mobile apps cache resources like browsers do.
On iOS at least you’d only be able to keep the connection open reliably when the app is foregrounded, most apps these days would probably make a bunch of network requests at that point anyway. Although it does optimise these by batching requests together and turning the radio on at once. I wonder how big of a difference it really makes, I guess it really depends on the app and how it’s used. I agree with the sibling comment, there are other reasons this model might not be ideal for mobile.
LiveView got to be the reverse node.js - look ma, I’m a backend dev and I can make UIs now!
I liked the idea of LiveView already, so it’s cool to see this spinoff arrive.
In general I don’t buy the cross-platform app framework marketing pitch. I don’t think there is any slam dunk that saves you money for the same per-platform native feeling result—the widgets are not enough. But this one has some unique properties.
As I understand it, and please correct my mistakes, shared code all moves to the server. It removes the need to have both client side shared code and an application API server, nor figure out the odd data interface differences between your web UI and your app UI. Maybe the best part is not having to describe app-level API operations since they are uniformly done by the server as UI state changes and updates.
UI code also moves into the shared thing in some sense. But you still write it once per platform. For example, in the SwiftUI templates it looks like you’re basically writing SwiftUI with a markup syntax, so you can be fully specific and get native behavior, but for other platforms you do it again. Where I come from in the mobile dev business, UI takes the bulk of the work. That makes me think it would be slow to develop and test the fine details of UI with these templates compared to the preview canvas in each native IDE.
I also wonder whether views are completely server side dynamic and if so what that costs—SwiftUI is built to know view hierarchy possibilities statically. I’m not clear on whether templates would be sent in full for a first screen view, needing structural dynamism, and then minimally updated, or whether templates would be baked into the app build, limiting what the server could then ask it to display.
But when I think of all the simple changes I could make that wouldn’t need to go through app review, I feel lighter.
Seems similar to https://hyperview.org/, can anyone confirm?
Side note: I really like how right on the Hyperview homepage, they describe what use cases it isn’t good for.
It’s similar to Hyperview and Strada, yeah. The architecture of LiveView is a little different than HTMX/Turbo, but LiveView Native fits in the same part of the ‘stack’ relatively.
Slight nitpick: Jetpack is actually the collection of first-party libraries Google provides for Android development, which would make liveview-native-compose a more accurate name for the Android port since it’s using Jetpack Compose.
Other than that, very exciting to see the progress! I’ve been messing around with Elixir on the side and being able to make Android apps with it will be fun to explore.