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

51–60 of 74 posts

Re: Open sourcing our Android and iOS apps

#51

Post by BoorishBears »

skewart wrote: post #48
jpetitto wrote: post #47

Earlier quoted context omitted.

I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app. Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless. The general style of t…

Just curious, why should activities only be treated as entry points to the app? What are the downsides of the only-use-fragments-if-you-need-to approach?

For one, the backstack story for Fragments is a lot more sane than whole "Task" concept for activities (The backstack for fragments is a list of fragments you can manipulate and debug very easily).

Re: Open sourcing our Android and iOS apps

#52

Post by Plaastix »

unsoundInput wrote: post #50
jpetitto wrote: post #47

Earlier quoted context omitted.

I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app. Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless. The general style of t…

I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fra…

I agree with you as well. It makes deep linking easier since you don't need to recreate an entire fragment backstack.

Re: Open sourcing our Android and iOS apps

#53

Post by jpetitto »

skewart wrote: post #48
jpetitto wrote: post #47

Earlier quoted context omitted.

I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app. Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless. The general style of t…

Just curious, why should activities only be treated as entry points to the app? What are the downsides of the only-use-fragments-if-you-need-to approach?

Fragments are one option. Another is just to use regular Views. There are libraries to help you with this such as Conductor.

As for Activities, they are usually overkill for most screens. They don't allow for seamless transitions between screens and prevent sharing UI components across screens (e.g. a Toolbar). Fragments and/or regular views have the added flexibility of being able to use more than one at a time and allows for easy re-use and view composition.

Like I said in my previous comment, the only really good reason to create additional Activities is to provide additional entry points into your app. Otherwise Fragments or Views will suffice and provide greater flexibility and improve the UX in many cases.

Re: Open sourcing our Android and iOS apps

#54

Post by bigiain »

IgorPartola wrote: post #7
wmichelin wrote: post #6

Earlier quoted context omitted.

If your code is bad, then there's risk of making security vulnerabilities more visible. Not that that's a good reason to avoid open sourcing, but it's a reason.

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

If widely used and critically important open source projects like OpenSSL can have latent security bugs lying in them for years (Heartbleed?) - I don't think it's practical to assume "the open source community" will security-audit and send pull requests for your "open sourced" product app.

If you want your code security audited, pay a reputable firm to conduct an audit. Throwing it up on Github and thinking "the good guys" will spend time looking and contact you for free when they discover problems is misguided at best.

Re: Open sourcing our Android and iOS apps

#55

Post by jpetitto »

unsoundInput wrote: post #50
jpetitto wrote: post #47

Earlier quoted context omitted.

I'm actually surprised they're relying on Activities for the views in the app. I'm not familiar with how the app works, but this is typically an out-dated approach. Activities should really only be treated as entry points into your app. Also, not a huge deal for an app, but the package structure is organized by layers, not features. Makes Java's non-private access modifiers essentially useless. The general style of t…

I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fra…

I'm not a fan of Fragments when it comes to navigation either, but there are other solutions as well (see Conductor). But there are limitations to using a new Activity for each screen, which I mention in my other comment below. They really only make sense for specific features in an app that require a specific entry point. Things like external intents (other apps, push notifications, etc...) or deep linking, as another user mentioned. They may be useful for Google Instant Apps too depending on how it ends up working.

Re: Open sourcing our Android and iOS apps

#56

Post by unsoundInput »

jpetitto wrote: post #55
unsoundInput wrote: post #50

Earlier quoted context omitted.

I disagree with you regarding Activities. For apps they do most of the screen management the developer needs just fine, especially if they are backed by a strong view and data model. If you download the App you can actually really quickly make out where they leverage the single Fragment (switch the project category via the drawer) and it makes sense there; but I think the same App build with a single Activity and Fra…

I'm not a fan of Fragments when it comes to navigation either, but there are other solutions as well (see Conductor). But there are limitations to using a new Activity for each screen, which I mention in my other comment below. They really only make sense for specific features in an app that require a specific entry point. Things like external intents (other apps, push notifications, etc...) or deep linking, as anoth…

Fully agreed that there are limitations, but I still think calling it an out-dated approach is unfair.

I don't see a simple, low on boilerplate, one-size-fits-all solution for reusable and separated components on Android at the moment. I love that the community didn't settle with just Activities or just Fragments and is actively trying new stuff (after all, if you look at React or Vue or even freaking backbone.marionette, the web is in a much better spot right now regarding UI composition), but right now the right solutions always seems to take the path of least resistance and use whatever mix of pattern that gets you to your goal as easily as possible.

Re: Open sourcing our Android and iOS apps

#58

Post by brianwawok »

V-2 wrote: post #19
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…

> 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

It's impressive that it took almost 3 person years to ship a 1.0 of a basic app?

Re: Open sourcing our Android and iOS apps

#59

Post by wapz »

120bits wrote: post #41

I'm not a mobile app developer by profession. But I always wanted to start learning and developing real world apps. The problem I always ran into the tutorials and demos, that they are mostly limited(i.e not close to solving real world problems). I think browsing their code, will give me a good start. And I would know how it's done right! Thank You!

Truthfully, I think you're better off with the tutorials and demos. Good ones will split up how to achieve what you need to achieve. Diving into a huge app like this will be confusing to figure out how everything is working. If you are already familiar with Android/iOS, then I think looking at these bigger projects can really piece everything together (but you wouldn't start with say rxjava and rxlifecycle on your own before understanding Android).

Re: Open sourcing our Android and iOS apps

#60

Post by alexashka »

iOS Project does not build - Xcode 8.2... There is a guard statement with no else clause, that's the first error I got. I didn't bother looking further because... a guard without an else could never compile, so what am I looking at?

I'm getting flashbacks from my last workplace where people merged in code that didn't compile and then went 'oh really? let me fix that real quick'...

Code wouldn't compile in master but the codebase... everything had to be clever. We can't just have a model, a network request to fetch/update for it, a view controller and view cells. A few storyboards and of course no bloody tests - it's a phone app.

No, we need protocols everywhere we can fit them, third party libraries - ones that haven't been out a few years (Reactive whatever), a third party library to make a basic GET request (Alamofire looking at you), a CSS styling library, a JSON to Model library, list goes on.

What we don't need is folder structure that lets you know this is the initial VC, the two folders beneath it are the 2 possible places you can go, the sub-folders in there are the places you can go from that VC and on and on.

Let's just dump all VCs in one folder, all cells in another. Nevermind that in 90% of the cases, that one cell is only ever used in that one tableview - no need to group those together.

I don't know - maybe it's just me - I'd rather I download a zip, open the project, click that triangle and it runs - this thing makes me jump through hoops, and it still doesn't work... And nothing makes sense, unless you go learn reactive cocoa - based on the amount of files/code, a clear waste of time.

Post reply on HN