A modern Android app looks good on phones various sizes, often also a tablet version is required. But good tablet version is more than just a bigger screen, it might have completely different flows. Now Android TV starts, another entry into the same app code. How does this affect an app? What is with Android Wear? What code can and should be reused? How can an app be prepared for another screen? Whats a good architecture for this? Which patterns work, which patterns we know are outdated for the new multi screen world of Android?

1. Developer survival
in a multi-screen world
Danny Preussler
Groupon
dpreussler@groupon.com @PreusslerBerlin

2. 45 17Millions
downloads
Millions
active users
+

3. So you want to go multiscreen?

4. So you want to go multiscreen?
• Phone (already lots of screen sizes)
• Tablet
• TV
• Wearables
• Car
• eReader
• Netbooks

5. The multi-apks Zombie
•Product view: different apps
•Developer view: all the same
•Remember tablet apps?
That approach failed
Zombie pilot statue by Gage Skidmore, CC by 2.0; flickr.com/photos/gageskidmore/8800037473

6. One apk to rule them all!
OneRingtorulethemallbyidreamlikecrazy,flickr.com/photos/purple-lover/13583362554

7. The Library-Zombie
• Remember the jar-hell?
• Unneeded Overhead
• Versioning problem
• Prevents continuous
refactoring
Zombie statue by PROGage Skidmore, flickr.com/photos/gageskidmore/7283588922

8. App logic
Multi-Screen-World
• Just another entry point
TV
Phone
Tablet

9. Remember? The shiny new world of
Honeycomb
• Fragments to the rescue?

10. Remember? The shiny new world of
Honeycomb
• Left-detail complex to implement
• UX was bad
• multi columns discouraged since Material FAILED
Fragments still important
building block

11. Let‘s talk layouts

12. •Remember the buckets?
Small, medium, large
 Deprecated
since 2.3!
 It‘s the new
iOS way ;)
Fire Buckets by Steve Greer; flickr.com/photos/steviegreer/2919157836/

13. • Don‘t think sizes think sizes and resolutions!
• ..the amount of space your layout needs:
• Available screen width/height
• Smallest width
• TV not so different, has own bucket
combine them!

14. Dos and Don‘ts

15. DONT
•...Design for fix screens
•Do: Define space to grow and move

16. DONT
•...code it!
•DO: use dimen and integer xml files instead of
checking for orientation
public boolean isPortrait() {
return configuration.orientation ==
Configuration.ORIENTATION_PORTRAIT;
}

17. DONT
• Bye bye activity cast pattern
• Has tight coupling even for interfaces = bad
@Override
public void onAttach(Activity activity) {
super.onAttach(activity);
this.parent = (NiceInterface)activity;
}

18. DO
•Remember Android basics:
Every activity stands on it‘s own!
•DONT estimate outside states!

19. DO: Dependencies goes into one direction
https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

20. DO: Dependencies goes into one direction
• clean architecture, dependencies in one direction
App logic
TV
Phone
Tablet

21. DONT
•...Have logic in your fragments or activities
•Extract!
•Build components!

22. DONT
•...create objects
•Inject!

23. DONT
•...repeat yourself
•Replace all findViewById,
setClicklistener..
with butterknife or similar!

24. DO:
@Inject(R.layout.about_fragment)
public class AboutFragment {
@Inject DeviceInfo deviceInfo;
@Inject Configuration configuration;
@Bind(R.id.about_text) TextView aboutView;
@OnClick(R.id.close)
public void onClose() {...
}

25. DONT
•... Keep states
•State = complexity

26. DO
•Each state a fragment even loading

27. DONT
• ...put code for specific screen sizes
in multiscreen Activity/fragment
• DO: keep it clean, Separation

28. DONT
• ...do something like:
TabletActivity extends PhoneActivity
• Tends to be flaky
• Extract base classes
TabletActivity extends BaseActivity
PhoneActivity extends BaseActivity
• BUT....

29. DONT
•...do base activities!
•Inheritence is tightest coupling possible
•Get‘s messy, lots of layers
•breaks for TV
•Remember Composition over Inheritence

30. DONT
• ...Hardcode navigation in activities and fragments
• DO: abstract it!
public class PromotionsTileFragment extends Fragment {
DashboardInteractor interactor;
...
public void onNextButton() {
interactor.moveToNextScreen();
}
}

31. DONT
• ...Write code like if(isTablet())
• Do: Try code-kata: program without if
• Do: Move to XML as much as possible

32. DO
• Inject dependencies
• Put the bad „if“ as early as possible:
@Provides
DashboardInteractor provideStatInteractor() {
if (isTabletLayout()) {
return new DashboardTabletInteractor();
} else {
return new DashboardPhoneInteractor();
}
}
public class PromotionsTileFragment extends Fragment {
@Inject DashboardInteractor interactor;
...
}

33. DO
• Move all device specific code into components or custom views
• Example: tablet specific toolbar setup code should go into a
TabletToolbar
• ALWAYS have one activities with
• different layouts
• single layout with differences in other xml values
• different injected components
• Careful: differnet styles need to break this rule, avoid!

34. DO
•Use for fragments
and activities
• Viewholder
= opposite of binding‘s
viewmodel
public class CardViewHolder {
@InjectView(R.id.card_border) View
borderView;
@InjectView(R.id.ok) ImageButton okButton;
view holder outside of lists

35. DONT
• ... Repeat yourself
• also valid for XML
Include/merge layouts
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
style="@style/Match">
<include layout="@layout/fullscreen_progress"/>
</RelativeLayout>

36. DONT
• ... Repeat yourself
• also valid for XML
Use styles
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
style="@style/Match">
<include layout="@layout/fullscreen_progress"/>
</RelativeLayout>

37. DONT
• ...Do only the common denominator
• Remember iOS vs android push notifications
Common denominator apps did not have quick
actions = really bad UX

38. DONT
• ...Do only the common denominator
• Use WearableExtender for example more quick
actions

39. DO
•ViewBinding
•Move UI logic to XML

40. DO
• DO: Develop against smaller sizes
• Use watch size in preview
• Use phone for tablet views
• Think squared

41. DO
• Try the new PercentageLayout,
it helps on multiscreen

42. DO
•Write unit tests!

43. Crossroads:SuccessorFailurebyChrisPotter;CCb2.0flickr.com/photos/86530412@N02/8226451812/

44. THANK YOU
Danny Preussler
@preusslerberlin
dpreussler@groupon.com