1. 45
    1. 18

      Why is an app needed? The website works perfect on mobile.

      1. 8

        I’d hope that an app would (eventually) be able to support features not available as a website, such as APNS (push notifications) for messages and replies, for example.

        Edit: Also, the possibility to sync and browse offline.

          1. 3

            I’ve been thinking about pulling down the source and looking at adding at least push notifications to the web app. But then life etc.

          2. 2

            Good to know, as last I checked this was not available. I do see it is noted in the Push section that “The technology is still at a very early stage” — and I’ve not seen anyone try using it yet.

            1. 2

              I’ve not seen anyone try using it yet

              Really? Every damn website these days asks for push notifications permission! Even random news websites and blogs that really shouldn’t do that.

              1. 1

                Those aren’t the same notifications, I believe, are very different than what we are discussing - they don’t provide push notifications outside of the browser, like APNS.

                Edit: Yes, they call them “Push services” vs. “Notifications”. Two separate things. When I speak of notifications I mean the APNS “Push” type notifications.

                1. 1

                  Depends on how the browser implements them — mobile browsers do use APNS/GCM to deliver web push notifications. Desktop Safari and Edge probably do that kind of thing too. With desktop Firefox, sure, you need the browser to be running.

          3. 2

            Or, currently, Pushover

            1. 1

              I’ve been using Prowl for many many years and while I’ve thought of changing, I just haven’t found the need to just yet, and I’ve built way too much with Prowl.

              Also, there are other competing services - Pushbullet, Telegram bots, etc.

              Having a native app that integrates with your native notification system is convienent, especially for mobile.

              1. 1

                I mean — Lobsters supports Pushover specifically.

      2. 7

        Speed, less memory, security, better notifications, possibly better search, user-specific plugins, user-specific UI’s, parallelizing any of that on multicore/NUMA/clusters, and and so on. The usual reasons to replace a web interface with a native one.

        I’ll go ahead and mention a UI problem I have on Lobsters periodically: I can’t tell if a comment is actually being submitted or the site is doing nothing. There was no visual feedback. The screen just sat there for quite a while. If it was being slow, that results in duplicates I had to remove. I’d rather have an instant change in my UI, even if small, that tells me it’s actually sending the comment. Then, it will either show page or failure. Also, I’m not sure if this still happens or someone changed the code since I haven’t seen it in a while. I think alynpost’s hardware upgrade and caching knocked out the lag that was causing it. The point is a native app might allow such a UI change.

        1. 3

          I can’t tell if a comment is actually being submitted or the site is doing nothing. There was no visual feedback. The screen just sat there for quite a while. If it was being slow, that results in duplicates I had to remove.

          I have noticed at least once a duplicate comment from you, thank you for reporting on what that is like on your end.

          One cause of site lag or slowness is the OOMkiller grabs the Ruby/Unicorn worker that was servicing your request. This is not a normal operation: we add memory, reduce the queue size, or right-size the application when this starts happening. That said, we’re sitting at 7GB memory in-use and when I checked based on your comment here the OOMkiller did take out a worker in the past ~24 hours.

          This issue aside, your comment about UX feedback is solid. It’s not always the OOMkiller. If any of you have suggestions on collecting and summarizing timing data for requests in Ruby or have suggestions on intra-process performance metrics (like collectd), it’s plausibly time to get better data here: the last memory upgrade was less than two weeks ago.

          1. 3

            That’s interesting. Thanks. OOMkiller grabbing workers sounds like a way to get DOS’s or heisenbugs on incoming requests. Maybe heisenbugs over time, too, on stateful systems. Just noticing the bug let me deal with it, though. So, I post. Then, I wait a few seconds, use another tab for other content, or something. I check on it in 30s-1m. Keeps me from doing doubles. Last few are when I was on mobile in a hurry in weak-signal environment.

            Again, a native app could improve that use case esp if combined with custom, efficient relay at home. The app deliver it to relay. I know it’s sent to something that might attempt delivery, check within the wait period, repost if necessary, detect any duplicates, and delete them. Maybe it has my login credentials but my phone doesn’t. Various possibilities. I don’t know if it’s worth the time to devise such apps. I’ll probably just delete the duplicates. Relay for avoiding weak-signal issues just popped into my head as a possibility enabled with custom client that’s all or partly native.

          2. 3

            As an outsider to the Ruby world, I’m curious why you choose to use Unicorn. IIUC, Unicorn only runs one request at a time in each worker. That seems to me like it would waste a lot of memory. Is real-world Rails still not ready for multi-threaded servers? I know they exist, e.g. Puma.

            1. 4

              The decision to use Unicorn was made before my time. I’m happy to revisit it with anyone who’d find that an interesting problem.

            2. 2

              The workers are all forks, so the memory overhead is minimal thanks to copy-on-write.

              Unicorn is also able to use shared sockets to let the kernel map requests to workers without an extra queueing layer.

      3. 4

        I’ve personally always struggled with Lobste.rs on mobile. On my iPhone in portrait mode, I’ve never been able to long press the comment count on the right side, in order to pop up the menu that allows me to open up the comments in a new tab. Lobste.rs seems to ignore my long press. I can, of course, just tap it, but then I lose my place on the main page.

        As a result, I always have to use Lobste.rs in landscape mode. So I wouldn’t say the website works perfect on mobile…

        1. 3

          Last month an iOS user reported they had difficulty selecting the comment link at all. We confirmed the problem and got it fixed.

          Would you mind if I transcribed your comment here in to a ticket? If you haven’t tried in the last month it’s worth seeing if the above patch was sufficient. Otherwise we’ll confirm it and see what we can do.

          1. 4

            Thanks for your reply! I was able to confirm it still seems to be an issue. Long press does nothing until you release the long press; at that point, the Mobile Safari menu finally pops up, but the web page navigates into the comments (before I’ve selected how I want it to open).

            I created a ticket here:


            1. 3

              Interesting. Seems to work fine on Android. I wonder what the difference could be?

              1. 2

                Any browser on iOS uses the Safari engine, anything on Android does not.

                1. 2

                  Yes. I was wondering why it would only show up in WebKit.

      4. 3

        A “native” app can be more responsive than a website, so I’ll definitely going to check the app.

        1. 1

          I know that has defiantly been the case, especially animations can be choppy in browsers. There is another post on the front page right now that shows Mozilla’s Servo can now render things a whole lot faster without skipping frames or lag.

          Will be good to test things out and see what the state of animations on mobile are now but the lobsters website is pretty basic and is fully responsive.

      5. 3

        Although progressive web apps can and do work very well, the effort required to make a good one is significantly higher than it is to make an app. Even then, it won’t feel anywhere near native (performance-wise) because the amount of JavaScript needed to make it happen will make the app slow down.

        Also, the app has a dark theme.

      6. 1

        I can’t use Lobsters at work because of the rs TLD. I actually wish someone would just give it another URL so I could hit it

        1. 3

          Do you have a server or little board at home? You could set it up to proxy it using an IP address instead of a name. It just redirects packets from work to home to Lobsters back and forth.

        2. 2

          I have had a similar issue with config/color scheme generator websites being on .sexy domains. Just an example of how TLD level blocking is ridiculous.

        3. 1

          You could always use toe gopher mirror, unless the protocol is blocked.

        4. 1

          Do you know what product is being used to block the .rs ccTLD? Are you able to describe technically how the blocking is being accomplished?

          EDIT: When you’re next logged in at work, I’d appreciate it if you could get a screenshot or error message of the site being blocked and email it to me.

          1. 4

            This was discussed on that other link aggregation site earlier. Blue Coat was mentioned in that thread, and that works by stripping SSL locally before sending it onto the internet. Basically, that should be impossible to get around.

            Other web filters work by both redirecting DNS to a block page, or, if a custom DNS is set, it does a reverse DNS lookup for the server IP.

          2. 3

            I don’t know, but I’ll check Tuesday if I remember. I work at Capital One fwiw

      7. 1

        I’m not a big mobile or app user, so not directly answering your question, but one exciting thing about a lobste.rs app is that it exercises and possibly helps fix bugs in or develop the API.

    2. 14

      Please consider having it published on F-Droid!

      1. 5

        Working on it…

        Whatever F-Droid build tooling is in homebrew seems to be old, so I’m having some weird issues.

    3. 9

      What works

      • Front page stories, comments, the article itself.

      What doesn’t

      • Anything that uses your account (@talklittle is/was making OAuth Support at some point)
      • The recent page
      • User profiles

      I think I implemented everything the API has support for, and the interface is a bit lacking. WIP. Signed Android Binary Here: https://gitlab.com/nikhiljha/lobsters-app/tags

      For those new to flutter, the entire codebase is inside the lib folder (~300LOC) - everything else is autogenerated. The app is also compiled to native ARM code, so although the binary is somewhat large (due to flutter needing to have its entire library in there), the application is fast and uses very little battery.

      1. 8

        OAuth 2.0 support was stalled waiting for a bugfix/feature to be put into an official release of the Doorkeeper gem, which incidentally looks like it came out 9 days ago as version 5.0.0. Doorkeeper v5.0.0.rc1 changelog mentions the merged PR.

        However now the OAuth 2.0 branch is pretty far behind master, so work needs to be put in to bring it up to date, and also fix numerous style issues to satisfy Rubocop. Not sure if/when I’ll be able to do that; if anyone’s up to the task please feel free to fork and continue the work, or redo from scratch if you can do a better OAuth implementation.

        1. 6

          I got most of the OAuth work merged into the ActivityPub branch.

          1. 3

            Where is the ActivityPub branch? I don’t see it mentioned in the issue for ActivityPub.

            1. 3

              Currently living on my github account / laptop.

      2. 3

        I downloaded the signed APK and unpacked it so I could look at file sizes: Here are the highlights:

        • lib/armeabi-v7a/libflutter.so (6.2M)
        • assets/isolate_snapshot_instr (4.2M)
        • assets/isolate_snapshot_data (3.1M)
        • classes.dex (2.2M)
        • assets/flutter_shared/icudtl.dat (1.2M)

        When an Android app is written entirely in a JVM language, the whole thing can be optimized through ProGuard. But whole-program optimization is much harder, if it’s even possible, when there are three runtimes in the mix (Dalvik/ART, Dart, and C++), as there are here.

        For complex line-of-business apps, it’s probably worth it. But it saddens me to think that every little consumer app (e.g. the app for the musical Hamilton, one of Flutter’s showcase apps), that should probably be a website in the first place, could carry around its own copy of a heavy runtime like this.

      3. 2

        the binary is somewhat large (due to flutter needing to have its entire library in there)

        I briefly looked into using Scala for Android apps a while back and I remember there were a number of people who talked about tree shaking plugins in their build process (build tools that would check to see what functions are actually used and remove all the other unhandled paths). I never actually went down this path, so I’m not sure if/how well they worked, but maybe there’s something similar for flutter/dart to get file sizes under control?

        1. 2

          I personally don’t think it matters that much. The Android app is about 8MB, whereas an equivalent app in Java is about 1-2MB. I have another app I wrote in flutter that is significantly more complex, and it’s also 8MB.

          iOS is another story. The ipa I just built is 40MB for seemingly no reason, and I have no idea why.

          1. 1

            Oh that’s not bad at all. That’s actually pretty good considering all the 30~60MB Android apps I’ve seen for the simplest services.

            Hope you can figure out what’s up with that iOS build.

          2. 1

            Are you sure you were in release mode? I’ve made that mistake before.

            1. 1

              I did a flutter build ios - which I would assume is the same as flutter build apk, but for ios. I think it’s release mode, because it doesn’t show the DEBUG banner in the top right. The large file sizes aren’t just me though, it’s a problem with iOS as a whole, exacerbated by the fact that I also have to load the Flutter library.

      4. 1

        I’m a big flutter fan, how did you find it?

        1. 1

          I wrote an article about this. It’s hands-down the easiest framework I’ve ever used, even moreso than the native development frameworks (Kotlin + Android SDK/Swift + iOS SDK).

    4. 2

      Is this available via TestFlight?

      1. 5

        Unfortunately, Apple charges the $99/year even for TestFlight. This comment prompted me to look into HockeyApp, which looks like it lets me bypass the App Store entirely (neat.) Their SDK provides app updates and everything.

        If you’d like to get this via HockeyApp, message me your email.

    5. 1

      Nice. I was thinking about building this last week as an excuse to learn iOS dev. So now I need to find another excuse. :)

      1. 3

        Well don’t give up on it because of this. If you want to learn Swift/iOS Dev, why not make a “competing” app? There is no competition in OSS anyway.

        Alternatively, you could contribute to this project. It’s very simple (~300LOC), and it’s a native iOS app.

        1. 4

          A 300LOC app came out to be 40MB? Wow. This is one of the rare times I see someone puts in good effort to keep the app lean before the platform explodes that effort. Although not an iOS developer, do tell me the reason and fix when you figure it out. I’m sure I’ll run into people later wanting to trim apps.

          1. 2

            Its probably that way so apple can sell new phones when users run out of storage space.

          2. 2

            Even Swift/Obj-C iOS apps are enormous. The Facebook and Uber apps are both over 250MB, and updates for those apps are ~300MB. That said, I have seen iOS apps written in Swift as ““small”” as 30MB.

            Add on the Flutter library to that (~10MB) and you’re looking at a 40 MB app.