The document discusses various Android anti-patterns including premature optimization, unnecessary use of reactive programming, and null pointer issues. It emphasizes better coding practices like using enums for clarity, avoiding needless complexities, and understanding when to apply reactive methods versus simpler solutions. Additional anti-patterns mentioned include superstitious coding and tester driven development, along with references for further reading.

1. Android
antipatterns
mobile guild
#cododajnia
Bartosz Kosarzycki
@bkosarzycki

2. Anti-pattern
a common response to a recurring problem that is usually
ineffective [and] usually counter-productive.

4. Premature optimisation

5. Donald Knuth
Author of “The Art of Computer Programming”
Sir Tony Hoare
Quick Sort, Null-reference,
Hoare logic

6. Donald Knuth:
For those who don't work to strict memory or CPU cycle limits,
PrematureOptimization is an AntiPattern, since there is only cost and no
benefit. For those who do, it is often confused with poor coding, or with
misguided attempts at writing optimal code.
Quotes original author is still questioned.
“We should forget about small efficiencies, say about
97% of the time”

7. LET’S REMOVE ALL ENUMS!

8. WHY?

9. Enums have obvious benefits:
- make the code more self-documenting
- the compiler can assign default values to
enumerator automatically
- prevents the programmer from writing illogical
code - e.g. multiplying enums?
- IDEs, type checking, correctness etc.

10. Change it to
integers?
public class View {
public static final int VISIBLE = 0x00000000;
public static final int INVISIBLE = 0x00000004;
public static final int GONE = 0x00000008;
}

11. https://developer.android.com/reference/android/support/annotation/IntDef.html
@IntDef would be
a better idea...
@IntDef({NAVIGATION_MODE_STANDARD,
NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS})

12. Which leaves us
with...
public class View {
public static final int VISIBLE = 0x00000000;
public static final int INVISIBLE = 0x00000004;
public static final int GONE = 0x00000008;
@IntDef({VISIBLE, INVISIBLE, GONE})
@Retention(RetentionPolicy.SOURCE)
public @interface Visibility {}
}

13. PROGUARD
DOES IT
FOR US!

14. -keep public enum
android-how-to-keep-enum-from-proguard [link]
proguard-wont-keep-a-class-members-enums [link]
Proguard config
#keep enum classes
-keep public enum com.intive.nearbyplaces.model.ApiProviderType** {
**[] $VALUES;
public *;
}
You can also keep the enums...

17. Silver-bullet

18. LET’S DO EVERYTHING REACTIVE

19. If you don’t need it - don’t use it!
Library Method count
Butterknife 119
Retrofit2 402
Realm 2343
com.google.android 9651
Glide 2364
Kotlin 5090
RxJava + RxBinding + RxPref + RxLoc +
RxTuples
5319 + 758 + 90 + 176 + 137 = 6480
Hawk 121
RxJava is heavy on android
*without proguard

20. Use reactive:
- Constant flow of data
- “Instant” search cases
Debounce(), throttleFirst()
- Reflecting settings in UI ?
It’s NOT only RxJava
Maybe Android bindings are enough?

21. Don’t use reactive:
- button clicks
@Click is probably more concise
- Simple “lookups” from db
Category category = Category.forId(263);
- Large, expensive, cached objects

23. Duplication

24. RxJava
Duplication of reactive approaches
EventBus

25. EventBus
Don’t use a separate
library - both approaches
are reactive!

26. /**
* Rx-style Event bus. Each event type implements its own subscription methods.
*/
public class RxEventBus {
private static RxEventBus instance;
private PublishSubject<Location> mGpsLocationEvents = PublishSubject.create();
public static RxEventBus instanceOf() {
if (instance == null) {
instance = new RxEventBus();
}
return instance;
}
/**
* Pass events of LOCATION type down to event listeners.
*/
public void newLocationEvent(Location location) {
mGpsLocationEvents.onNext(location);
}
/**
* Subscribe to this LOCATION type Observable. On event Action will be called.
*/
public Observable<Location> getLocationEvents() {
return mGpsLocationEvents;
}
}

28. Nullpointer hell

29. @NonNull
Java is not null-safe

30. @NonNull
How can we overcome
this?

31. @NonNull
- We could use a higher order language like
Kotlin/Scala/Dart
- Optional<Type>
- Annotations @NonNull @Nullable

32. @NonNull
funtion add(@NonNull Square s1, @NonNull Square s2) {
}

33. @NonNull
funtion add(@NonNull Square s1, @NonNull Square s2) {
}
TEDIOUS!

34. @NonNull
Let’s assume parameters
and return values are
NonNull by default

35. @NonNull
file: package-info.java
@ParametersAreNonnullByDefault
@ReturnValuesAreNonnullByDefault
package com.intive.nearbyplaces;
Gradle tasks for generating these files:
download, download

36. Antipatterns summary
- Premature optimization
- Silver bullet
- Duplication
- Nullpointer hell

37. Other Antipatterns
Superstitious coding
Coding to handle error conditions which are already known to be impossible.
Reinventing the square wheel/ Not Invented Here (NIH)
Failing to adopt an existing solution and instead adopting a custom solution which performs much
worse than the existing one
Tester Driven Development
Removing the determination of requirements and letting the testers (or the QA team) drive what they think the software should be
through the testing (or QA) process.
Lava flow
Retaining undesirable (redundant or low-quality) code because removing it is too expensive

38. Links
- Premature optimization is the root of all evil - Donald Knuth link
- The antipattern catalogue Donald Knuth - link
- The price of enums Android Developers - link
- AntiPatterns: Refactoring Software, Architectures, and Projects in
Crisis link
- When not to use reactive - link
- NonNull gradle task generator - link, link

39. Thank you!
QUESTIONS
Bartosz Kosarzycki
@bkosarzycki