jpetitto

When business meets software...

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.

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.

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 the source code is solid though. I wouldn't be upset if I had to work in this code base on a daily basis.

Not LA though!

I would say most of it IS appropriate. A lot of the advice is good for Java development in general, regardless of platform. Enums are one area that is hotly debated in the Android community, but there is no consensus on it.

Generally, I would say follow the advice in Effective Java, but be aware of some potential performance issues and how you can avoid/fix them if need be.

Edit: I noticed there is a chapter on serialization. This can be ignored by Android developers in favor of Parcelable.

Deconstructing Functional Programming by Gilad Bracha:

https://www.infoq.com/presentations/functional-pros-cons

I live and work in Pasadena with a metro stop across the street from my apartment.

Your commute was definitely a tough one! A big issue I've noticed is that a lot of people work in west LA, but the housing prices are so high that most can't afford to live there. This also leads to much higher traffic for commuting in that direction.

I moved to Los Angeles about four months ago and was surprised how little I drive. Uber and Lyft are insanely cheap here when using the pool/line options. I've taken 10 mile trips for $4! The metro is great too if you live near a line.

Certain parts of the city are easier without a car than others. A lot of it comes down to how far you live from work too. I walk to work everyday (10 minutes) and there's a plethora of stores in my area to walk to and shop at.

I'm about to sell my car and I'm not sure if I'll be getting another anytime soon.

Any of the popular Square libraries are great examples, https://github.com/square.

Retrofit is truly an amazing library. With little more than an interface declaration, you are able to make network calls and have the the requests/responses automatically (de)serialized into POJOs. You can even consume responses as an RxJava Observable type. Retrofit 2 in particular is incredibly modular; you can swap out different data converters and HTTP clients, for instance.

This is modern Java development at its best. I know as an Android developer I'm indebted to all the great work that Jake and the other engineers at Square have done in the open source space.

"Programming Languages" - https://www.coursera.org/course/proglang

"Compilers" - https://www.coursera.org/course/compilers

Isn't Square attempting to move into this space?

I've implemented this toy compiler (minus JIT) in Java, following the tutorial on the LLVM website (which uses C). After browsing through the Haskell code, it is incredible how much more suitable a statically-typed, functional language is for compiler development when compared to an imperative language like Java. The code is much more terse and most importantly, readable.