Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open sourcing our Android and iOS apps

kickstarter.engineering

Post reply on HN
Print view View original

11–20 of 74 posts

Re: Open sourcing our Android and iOS apps

#11

Post by fareesh »

unsoundInput wrote: post #8

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real world app for learning and comparison. The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments w…

Was thinking about this the other day, now in the context of this release it comes to mind again - it would be kinda cool if it was a common practice for tutorial folks to make a repo where they forked the entire thing and placed comments all over which were links to videos that broke down those sections in an easy to understand way.

Re: Open sourcing our Android and iOS apps

#13

Post by IgorPartola »

Alupis wrote: post #10
IgorPartola wrote: post #7

Earlier quoted context omitted.

Which is also a good reason to open your code and let those that know better help you fix it.

> Which is also a good reason to open your code and let those that know better help you fix it. This is a fantastic mentality, but unfortunately doesn't really play out in reality. I'm a huge Open Source fanboy, but we need to be "real". How many people are really going to read every line of every open source program? Very-few-to-none is the real answer. Massively popular software gets eyeballs, but few others do. Mo…

How many of the people that do review your code would exploit it vs reporting it to you? Combine it with a bounty program, and chances are you will get useful feedback at a fraction of the cost of a full on audit.

Re: Open sourcing our Android and iOS apps

#14

Post by Alupis »

IgorPartola wrote: post #13
Alupis wrote: post #10

Earlier quoted context omitted.

> Which is also a good reason to open your code and let those that know better help you fix it. This is a fantastic mentality, but unfortunately doesn't really play out in reality. I'm a huge Open Source fanboy, but we need to be "real". How many people are really going to read every line of every open source program? Very-few-to-none is the real answer. Massively popular software gets eyeballs, but few others do. Mo…

How many of the people that do review your code would exploit it vs reporting it to you? Combine it with a bounty program, and chances are you will get useful feedback at a fraction of the cost of a full on audit.

I agree with the sentiment of your post, however I believe it is based on an ideal world, which we don't live in.

> How many of the people that do review your code would exploit it vs reporting it to you

By nature, attackers would be reviewing your code as well.

> Combine it with a bounty program

The overwhelming majority of Open Source software was created-by and is curated-by a single person who makes negative profit by working on the software for free in their spare time. Even some of the most popular projects are still total losses for their curators. You're not going to get bug bounty programs here.

For example, take a look at Crosstool-ng[1] (a popular project used to build cross-compilers for various architectures). Companies and individuals are all using this project to build cross-compilers that they trust to build other software with. A bug in Crosstool-ng could propagate into bugs in the compiled software it produces. Bryan Hundven does most of the heavy lifting on this project by himself, and as far as I know, he's paid nothing for it. You're not going to get a bug bounty program here either.

Heck, it's doubtful even a project as large as the Linux Kernel would be able to afford an ongoing bug bounty program. They're trying with the Linux Foundation and the Core Infrastructure program, but how many years before did it have none of that?

Essentially, these programs only work for commercially-backed software, which is only a small sliver of open source software.

[1] https://github.com/crosstool-ng/crosstool-ng

Re: Open sourcing our Android and iOS apps

#15

Post by dblock »

For anyone reading their post, we're so humbled by Kickstarter mentioning the tiny Artsy for having inspired some of this work. If you're interested in the open-source by default conversation and need some ammo to bring this to your team, start at http://code.dblock.org/2015/02/09/becoming-open-source-by-de...

Re: Open sourcing our Android and iOS apps

#16

Post by V-2 »

unsoundInput wrote: post #8

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real world app for learning and comparison. The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments w…

Yeah, they sort of rolled out their own MVVM implementation, based on RxJava and RxLifecycle.

On Android MVVM is more difficult than MVP in my opinion (the most popular choice, not counting spaghetti projects), mostly because the platform doesn't provide the "glue" needed to bind viewmodels to the UI layer. At first glance it looks like they did it without overengineering, which is another trap as far as these matters go.

Clearly a work of very good experts

Re: Open sourcing our Android and iOS apps

#18

Post by Plaastix »

V-2 wrote: post #16
unsoundInput wrote: post #8

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real world app for learning and comparison. The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments w…

Yeah, they sort of rolled out their own MVVM implementation, based on RxJava and RxLifecycle. On Android MVVM is more difficult than MVP in my opinion (the most popular choice, not counting spaghetti projects), mostly because the platform doesn't provide the "glue" needed to bind viewmodels to the UI layer. At first glance it looks like they did it without overengineering, which is another trap as far as these matter…

That "glue" can be Android's Databinding library. I've used it to bind ViewModel data to views. Works really well.

Re: Open sourcing our Android and iOS apps

#19

Post by V-2 »

V-2 wrote: post #16
unsoundInput wrote: post #8

Kudos to them. Compared to the web it's rather cumbersome to poke into packaged and released mobile apps, so I really appreciate access to the source of a real world app for learning and comparison. The Android codebase looks very modern and well structured. I think it makes great use of many of the goodies (gradle, rxjava, retrofit, dagger, android support lib, ...) and learnings (bring your own MV*; use Fragments w…

Yeah, they sort of rolled out their own MVVM implementation, based on RxJava and RxLifecycle. On Android MVVM is more difficult than MVP in my opinion (the most popular choice, not counting spaghetti projects), mostly because the platform doesn't provide the "glue" needed to bind viewmodels to the UI layer. At first glance it looks like they did it without overengineering, which is another trap as far as these matter…

> In less than eight months, four engineers who had never written production Java code, let alone production Android code, shipped a 1.0.

Wow. That's pretty impressive

Re: Open sourcing our Android and iOS apps

#20

Post by V-2 »

Plaastix wrote: post #18
V-2 wrote: post #16

Earlier quoted context omitted.

Yeah, they sort of rolled out their own MVVM implementation, based on RxJava and RxLifecycle. On Android MVVM is more difficult than MVP in my opinion (the most popular choice, not counting spaghetti projects), mostly because the platform doesn't provide the "glue" needed to bind viewmodels to the UI layer. At first glance it looks like they did it without overengineering, which is another trap as far as these matter…

That "glue" can be Android's Databinding library. I've used it to bind ViewModel data to views. Works really well.

I'm aware of it, but last I checked it didn't seem production-ready and lacked features. I believe they updated it at some point, but other than some talk at Google IO not much came out of it - even the docs didn't reflect it back then. Perhaps it's up to the task now, I admit I'm not looking it up regularly.
Post reply on HN