![]() ![]() LiveView has mechanisms in place to seamlessly restore the connection if it goes out, but a poor cellular signal or a weak internet connection can lead to a lackluster user experience.Īnother drawback is that LiveView requires a different mindset for a developer to work effectively in its paradigm. In fact, the main downside is actually tied to LiveView’s greatest strength because the server is responsible for rendering everything, the client needs to maintain an active internet connection. The Cons of Phoenix LiveViewĮvery superhero has their kryptonite, and LiveView is no exception. ![]() What would take KBs to transfer with traditional methods will now only take a few bytes. Instead of wasting bandwidth on rendering the same page over and over again, LiveView keeps all the static elements in place and just sends the changes: the data itself. Even if the network connection occasionally drops, it’s no big deal Phoenix LiveView will automatically reconnect when the network connection is reestablished. However, for farmers to be able to use these insights, they need to be able to access that data while they’re out in the field-and we certainly can’t expect a high throughput network. Our devices can collect data about growing conditions that can inform smarter decision-making. If bandwidth is a concern, LiveView is an optimal solution because it makes our data transfers as small as possible. The benefits of LiveView come into even clearer focus when we start to consider constrained networks like LTE. This provides a smooth user experience that requires minimal effort. With LiveView, we can tell that app to subscribe to that same smart_fishtank1/temp topic, so whenever the broker receives a message from the device, it will automatically forward it along to the front-end. Now let’s say you own that aquarium, and you open the mobile app to check the water temperature. So, for example, a smart thermometer will take readings and publish the data to an MQTT broker like AWS IoT Core over a topic such as smart_fishtank1/temp. This includes sensor data from the devices themselves, user data coming from the front-end, and back-end data that lives in the cloud. Once the server receives this information, it knows to ignore any messages coming from the specified devices. For instance, on an IoT dashboard, a client can tell the server to silence notifications from specific devices. Plus, since we have a two-way connection, the client can also send information back to the server. That way, instead of resending the entire page, we only have to send a fraction of it. As a result, LiveView only sends the minimum amount of data that’s needed to update the client with the new information. The client then holds all the static information in a browser cache, while the server keeps track of any changes and sends them to the client as diff messages.Įssentially, this means that the server updates the front-end as data changes, and it informs the client of those changes-and only those changes. The LiveView client then opens an active connection back to the server, which creates a two-way connection between them. When a client requests information from a server, LiveView begins by rendering the initial page and sending it to the user’s web browser. Phoenix LiveView may not hold a monopoly on this pattern, but it does provide a simple programming model to enable it. When we combine this with the built-in concurrency of Elixir processes and the robust publish/subscribe (pub/sub) messaging of the general Phoenix Framework, we can tie this all together to generate robust, real-time dashboards. Since the server controls what’s rendered, we can program server-side events to trigger updates on our web pages. ![]() In LiveView, the server is responsible for everything. Written in Elixir and maintained as an open source project on GitHub, LiveView enables developers to easily build web front-ends with streaming, real-time data without having to worry about client-side complexities. That’s one reason we’re keeping a close eye on the Phoenix LiveView framework, a new paradigm for web development. As far as we’re concerned, this simply isn’t acceptable, especially after a customer shells out $500 for a smart device. For instance, when our founder, Ben Wald, recently reviewed the Molekule Air Mini+, he was impressed by the quality of the device itself, but the poorly programmed mobile application (pictured below) left much to be desired and left him frustrated.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |