Live data from Hacker News

Open sourcing our Android and iOS apps

kickstarter.engineering

71–74 of 74 posts

Re: Open sourcing our Android and iOS apps

#71
post #64
post #30

Earlier quoted context omitted.

And actual tests for the Android app! It's a rarity, and especially annoying since the "sample" apps that Google provides pretends that testing doesn't exist.

Unit tests or integration tests? It may be better now, but android used to be a real pain to unit test, so much important functionality was baked into the Activity base class that was hard to substitute.

They seem to favour unit tests over integration tests, which is achieved by abstracting the layout logic away from Activities and into view models that can be unit tested with no fuss.

Re: Open sourcing our Android and iOS apps

#72
post #68
post #63

Earlier quoted context omitted.

But what other languages did the have experience with? If it was something similar like c#/c++/ruby/python then the time to learn java should not be significant.

When it comes to Android, Java by itself is the least of problems. It's the SDK and framework that are tricky, ridden with technical debt and often far from developer-friendly.

I was about to say this. In fact, you have to unlearn a lot of what works and is accepted in server side java when you move to Android. Learning the SDK and Android gotchas was by far the hardest part of my first Android app.

Re: Open sourcing our Android and iOS apps

#73
post #16

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…

When dealing with MVP on Android, how did you deal with dynamic view creation?

Right now we are working on a rearchitecture and are finding that creating dynamic views in the Activity/View requires business rules we are putting in Presenter. But the Presenter doesn't have context.

Re: Open sourcing our Android and iOS apps

#74
post #68
post #63

Earlier quoted context omitted.

But what other languages did the have experience with? If it was something similar like c#/c++/ruby/python then the time to learn java should not be significant.

When it comes to Android, Java by itself is the least of problems. It's the SDK and framework that are tricky, ridden with technical debt and often far from developer-friendly.

Yes Android is particularly complicated, but not to the point where 3 experienced developers building an app in 8 months is in any way remarkable.
Post reply on HN