hidro

Similar concept but with Gherkin syntax: https://github.com/hidroh/cucumber-api

It's the 1st version of on-screen navigation so for sure there are rooms for improvement. I think of it as a D-pad, as in games, when you make selection with D-pad, down means selecting below item. I can make a toggle option to reverse scroll direction though.

Yeah that's one way to go. Probably I'll use Algolia for users that prefer up front loading. It's slower than official API but would do the job.

Got it thanks!

I already did some optimization to load 1 extra page of comments in advance, which I believe should improve the experience. I also tried the same trick for stories but got some janky issues that I need to figure out first.

Swipe down the button should go to next same level comment, or if none it goes to the next one, which is the 1st child.

User-related content support is quite limited at the moment as I need to crawl HN web for that.

I have something similar in mind but haven't get started yet. It can be done via HN API, but it can only be done at regular interval (polling), as I don't use Firebase but raw web API.

I already have similar request in my backlog. This is gonna be tricky, because I don't have all comments up front as they are loaded on demand (even for saved comments - loaded on demand from cache).

1. I can't sync vote status so it's only a best effort at the moment to let you vote. Of course after the 1st vote is recorded subsequent votes will not count. This for sure can be improved.

2. Sure. I added vibration because I tend to mis-swipe so I added vibration to give me some feedback. But I understand not all users may like it.

It's stored under your device's accounts, which you can manage via Settings -> Accounts. The same way Google apps work.

Thanks! Would be helpful if you can share your device info so I can try to reproduce that issue. If you still keep the app around you can just send an in-app feedback and it will automatically include such info. Or you can reply here. Or if you can email me, my email should be available on Play Store listing.

Sorry you don't find it useful :(

No downvote is a known issue, partly because I can't test it, so I'm not confident I'll deliver a reliable feature.

I agree that upvote should be more visible. Currently it's available as an option tucked in popup menu, as well as via swipe gesture, which is not very discoverable.

3rd one is a feature called 'deep link' which is quite common in Android. It should remember your choice if you choose 'Remember my choice'. I don't know what went wrong here as it is a platform feature and out of my control :(

Thanks for checking it out anyway.

Disable card view (which is the default for new installations) + choose smaller text size would achieve more or less the same. I have already gone thru few iterations of compacting the UI and I'm afraid I can't squeeze it anymore :(

No, I have to chain requests, using cookies.

You're correct. Saved/bookmarked stories have been there way before HN has favorite. I'm thinking of syncing these two, but it's not very straightforward without API support.

I have made releases available to download here, effectively same as F-Droid, but easier for me to publish: https://github.com/hidroh/materialistic/releases

Thanks! I have incorporated the idea of on-screen navigation button and grouping setting options. What else you think I should consider from Relay?

Single story refresh is a nice idea. I just added it to my backlog. Thanks!

It's because stories/comments are loaded on demand. If you never scroll to it it won't be loaded. It was designed this way partly due to how HN API works, which doesn't provide all data up front.

Alternatively app can aggressively load everything up front, which is slow; or paginate content. To me it tends to feel faster when u have progressive UI change (empty card then fill it) than abrupt change (completely empty then all items appear), so I decided not to paginate.

It supports Konami code as well :)

I'm aware of the issue and trying to find a way to mitigate it.

It's already on my list, just didn't have time to do it yet.

I plan to implement downvoting but I'm not sure of the logic involved (I don't have enough karma to test it myself). Probably I'll add it to a beta channel and let users help test it.

Performance can be laggy and is something I'm trying to improve.

When I created it material design was a hot thing, so I just randomly came up with that name. Now it's not relevant anymore but I keep the name to avoid confusion for existing users.

Remind me of a (sort of) similar story of how Iranians consume online content https://news.ycombinator.com/item?id=11552423, though for a different reason.

I like how Scrum promotes transparency and trains each individual to become self-managed (or at least getting better at it). But it often feels like it's being hyped up, with many people getting obsessed over its practices/rituals.

Estimating work is a nice idea, but using 'story points' for it just feels like a bad API decision - I have never seen a new Scrum team member (including me) getting it at 1st try.

And maybe it's just me, but having a full time, dedicated Scrum Master, who serves solely as a facilitator (without having any actual role in product delivery) is a nightmare, especially for teams that are used to Scrum practices.

As a mobile developer, I do appreciate WebView. Using it in the right place for the right situation works great, and proves to be a much cheaper solution than any other things.

But I would disagree with using it as the main building block for an app. There are many gray area I'm not sure if WebView can handle well enough, e.g. offline mode, screen orientation change/state restoration, first time rendering without delay etc.

Rails is built on top of Ruby language, designed to be opinionated, following MVC. You like it, you use it. You don't like it, try another framework.

Using the same analogy, Android is build on top of Java language, is 'opinionated': instead of designing with Model, View, Controller components, it's designed with 'unusual' components (as in not following any classic architectures) e.g. Activity, Service, ContentProvider. You like it, you use it. You don't like it, unfortunately you still have to use it. The real issue here is a lot of developers depend on Android framework, and many of them seem to struggle with the way it's structured, with no direct replacement (not taking into account hybrid frameworks here).

The way I see it, architecture is an opinionated topic. Sure classic architectures like MVC, MVP, MVVC are proven ones, but they serve as a guideline at most. There is no right or wrong if you follow this and not follow that. You are not happy with any of them, you make your own architecture/pattern. Hell it's opinionated, you are allowed to have an opinion here! If you think MVC or some other pattern is the right way to go, then the author has the right to think her design is the right way. It just keeps going on.

I have a full time software engineer job, and I work on a side project which is a HN Android app.

If your side project is a freelance one, you're probably in for a tough time, due to external pressure.

If your side project is a hobby one, my advice is to start small, and plan subsequent iterations small as well, so you can usually finish in say within a weekend. Anything bigger will make you feel overwhelmed. Also be prepared to sacrifice some personal time for your project, it's a hobby anyway.

I'm assuming that your side project has little in common with your main job, otherwise there is no fun in doing it. If that's the case, I find it especially useful if the side project can, in a way, contribute to the main project. E.g. you experiment things you want to learn with side project, and apply it into your main project some time in the future. This way you have a good cycle and motivation to keep innovating/experimenting. Making your code/project public so others can use/contribute is also a good motivation to keep it up.

Hacker News Android app: https://github.com/hidroh/materialistic

API testing with Cucumber: https://github.com/hidroh/cucumber-api

I strongly prefer this approach, as long as the project is interesting enough to attract engineers, and allows you to assert the aspects you want to see in them. The coding project we give to candidates is to implement an open source Hacker News client. If it were me I won't mind doing one and put it on my portfolio (which I did), regardless of whether I pass the interview.