Hacker News new | past | comments | ask | show | jobs | submit login

Thanks.

Not related to Flutter but Google in general: I recently hit a hard-to-reproduce bug with Jetpack's LiveData for which there's already an open issue created by a third-party developer. I don't recall but it had been open since 2018 with no updates whatsoever from Google engineers on its progress.

And therein lies a frustrating problem for engineers not working at Google but using Google tech. There is simply no alternate universe where a third-party team gets the level of access the way you described the Google Pay team did.

Of course, it helps that the stakeholders are in the same company, but my point is, shouldn't there be a Flutter Foundation where every developer can feel at home on equal footing with other Googlers? Flutter is so promising, and yet, at the same time, I don't want to end up being slave to its complexities with no way out as a third-party small development shop.

Despite that, I'm 99% porting my cross-platform app to Flutter after strong reviews from other developers I know.




I can't speak for Jetpack, but as far as Flutter goes: Flutter is open source, we do all our work in the open. File a bug; we look at all our incoming bugs and there are members of the Flutter team (volunteers as well as people from Nevercode and Google) who try to reproduce each issue. We don't always have the bandwidth to fix everything, but last year we fixed roughly as many bugs as were filed, so the odds are pretty good. (And of course you're welcome to try to fix the bug yourself, we accept PRs from anyone, not just Googlers. See our contributor guide on GitHub.)

We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.


We are using Flutter at our company and it's far from a black box if you get stuck.

For example, try going to a TextField widget and use go-to-definition view the source source code. You can go very far down the go-to-definition hole. Even to the point where you can see where the blinking cursor is being rendered.

For several "blockers" we did have, we were able to copy/paste the Flutter implementations, rename them, and modify them to fit our own needs.


Android development is like that; you hit a framework bug, you'll expect it will never get fixed. Just find a workaround and accept it's what it is.


At least with iOS you know it will take three years for something to come out of beta but then it's pretty solid. It's just Xcode that never gets fixed.


Hmm, LiveData is pretty straightforward class, over the years I think I memorized its implementation. I'm curious what's the issue is?


The bug is, on ocassion, while executing a query, LiveData would hit EACCESS trying to open the table (?): https://issuetracker.google.com/issues/170228126

It had to do with their Invalidation tracker (a table, I believe, which is a living log of ordered updates that need to be delivered to observers).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: