This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-03
Channels
- # announcements (55)
- # babashka (14)
- # beginners (49)
- # biff (9)
- # calva (73)
- # cider (14)
- # clerk (8)
- # clj-kondo (6)
- # clojure (92)
- # clojure-dev (4)
- # clojure-europe (18)
- # clojure-norway (62)
- # clojure-uk (5)
- # clojuredesign-podcast (4)
- # clojurescript (34)
- # cursive (40)
- # data-science (4)
- # datomic (5)
- # dev-tooling (1)
- # eastwood (6)
- # emacs (107)
- # figwheel-main (9)
- # fulcro (13)
- # gratitude (9)
- # hyperfiddle (5)
- # introduce-yourself (2)
- # off-topic (45)
- # overtone (23)
- # portal (5)
- # releases (3)
- # shadow-cljs (6)
- # specter (1)
- # squint (32)
- # timbre (4)
- # vscode (2)
Before I go down a dead end, I have web worker questions. What I need is a fairly simple app that collects some data from me and sends it to a RESTful service. I need it to cache the data when the service is not available. Initially I thought about going down the React-native path, but then I thought maybe a SPA could handle that with a clever web worker. Or maybe with web storage. How feasible is that with cljs? How well do SPAs stick around in the browser when offline?
You seem to be mixing a few concepts together. Both RN and web workers have nothing to do with offline capabilities of apps or SPAs. If you need something that must work on mobile then AFAIK you'd be much better off with RN since then you'd have much more control over the lifecycle of the app.
Oh, and CLJS is also orthogonal here. If you can do something with JS, you can do it with CLJS.
I don't know much of what JS is capable of, which is why I'm lost. I figured a SPA would be simpler to write. But if RN is the way to go, then I guess I better start climbing that hill!
By itself, an SPA won't help you in any way. To make the data truly persistent on mobile, you'd have to use IndexedDB (local storage isn't suitable because it can be cleared by your browser when you don't really want it to). But that won't make your app stick in the browser if your mobile device decides to clean up active tasks. You can make web pages available offline at least on desktop, and maybe it's possible on mobile, but that's another extra thing you'd have to learn and do - otherwise, you'd be greeted with "Network unavailable" at some point, even though the data itself would still be stored. With RN, it's just a regular app. It will always be available even if there's no network. The data can be saved with regular file system access (albeit, with some permission shenanigans since mobile platforms usually have extra checks).
Using RN to make a native app does then leave you needing to worry about distribution though, right?
and on iOS that means getting a developer account and satisfying the app store?
AFAIK, there are ways to install iPhone apps without the app store and without jailbreaking it.
not really. you can do all this without a service worker or native app, it all just depends on what your app actually needs to do
I'm trying to collect data to feed into a Heedy server. It's health/mood related data. I need to be able to capture it reliably on my phone, even when I can't reach the server. If I drop that last requirement a web page would be simple enough to get the job done.
writing a function that saves that data into indexeddb or similar when the request fails is trivial
service worker only adds the capability to do something while you are not actively using the website
if its fine it syncs are delayed until you use the website again then everything is fine
This approach won't work in the following scenario: • The network is up • You open the web app • The network is down • You lock your phone and get on with your day • The mobile OS decides that it's time to evict some memory users and tells the browser to reduce its memory usage, the browser unloads all the web pages without closing the tabs • You unlock the phone • You're immediately greeted with that tab being open but saying "Network unavailable"
if that is a scenario you will frequently encounter a service worker will help. I think its a bit exaggerated, since you can always write data to "storage" first and remove it when successfully synced
if you are one of those people with 500 open tabs the os eviction thing might be common. I don't see it that often personally.
Specifically for iOS, safari web clips are pretty good for this type of stuff: • https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/ConfiguringWebApplications/ConfiguringWebApplications.html#//apple_ref/doc/uid/TP40002051-CH3-SW3 • https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/Client-SideStorage/Client-SideStorage.html#//apple_ref/doc/uid/TP40002051-CH4-SW1
You can create a web page and save an icon to your home screen that looks like a regular app. The web clip gets some amount of permanent storage and can work offline.
It's a bit difficult to search for info (the name "web clip" has been reused by a dozen totally different things), but they really do hit a sweet spot.
> I'm trying to collect data to feed into a Heedy server. It's health/mood related data. I need to be able to capture it reliably on my phone, even when I can't reach the server. For continuous capture, you would need an actual app or something that can plug into iOS's health APIs. If you're just inputting data every once in a while via a simple UI, then the webclip route might be a good fit.
This is all on Android for me. I don't see something similar there. And thankfully I don't need continuous capture.
I think Thomas is right and a simple cljs web app with a service worker for the offline/tab-evicted thing, plus write to IndexDb to persist between syncs. If you're on Android with Chrome specifically there is also a super cool thing you can do running a periodic task in the background to sync, which will work even if the page tab is closed: https://developer.mozilla.org/en-US/docs/Web/API/Web_Periodic_Background_Synchronization_API#browser_compatibility
I think fears of data loss are overblown unless you're doing something strange, or on Safari (where I think there is a 7 day limit to data storage for non-homescreen'd PWAs).
oh neat, didn't know about that API. so many cool things in browsers nowadays, that I wouldn't even consider anything else unless real hardware/OS access is needed
localForage is a library that makes it super simple to persist things (including Blob
s) to IndexDb: https://localforage.github.io/localForage/
Basically you can treat it like a very large key value store.
(because you can put Blob
s into this key value store you can also put File
s like uploaded images, audio and the like).
I was doing some research on storage amounts and cache eviction and there's a great deal of detail here. Only Safari proactively evicts data if there has been no user interaction in the last 7 days. https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria
Wow! Thanks for all of that. So it looks like it's possible. I suppose trying a bit of both approaches is a good idea, to see how far I get with each. I do kind of like the idea of being able to drop some static HTML and JS on my webserver.
One more thing on this - it's also possible to "upgrade" a web app to a native app quite easily using Capacitor. I have done this myself with ClojureScript web apps, turning them into native apps (I used Cordova which is a percursor to Capacitor but basically the same idea). It's extraordinarly easy to try - only takes a few inutes to get a native app working from your www/build folder. Once you have a native app you can do things like persist datastructures to disk manually whilst still keeping most of the app as web tech. This is my preferred method when a native app is absolutely required because of some feature the web platform doesn't support.