Best practices in developing whitelabel apps for Android OS, presented at EMEA AppForum 2017.

1. Write once, ship multiple
times
ŽELJKO PLESAC

2. Independent design & development agency
108 people in 3 offices
18 Android engineers

3. WHITE LABEL SYSTEMS

4. A white label product is a product or
service produced by one company
(the producer) that other companies
(the marketers) rebrand to make it
appear as if they had made it.
- WIKIPEDIA

6. Provides your brand with a refined product.
Outsourcing the development to a trusted thirty-party company.
Saving time and money.

7. Lack of control.
Lack of customisation.
Unified product vision.

8. HOW TO BUILD WHITE LABEL APPS?

10. NO.

11. Carefully
designing the
system.

12. PREREQUISITES

13. THOU SHALL NOT USE FAT CLIENTS.

14. Fat clients
• not customisable on the fly
• new app version for each new
feature
• prone to errors
• hard to maintain

15. MOST OF THE SYSTEMS FAIL ON THIS
POINT.

16. SYSTEM ARCHITECTURE

17. Flavours.
Modules.

18. FLAVOUR ARCHITECTURE

19. Main flavour.
Product flavours.

20. MAIN FLAVOUR
• default product
• used only for demo purposes
• contains shared code
• uses default set of resources
• can be customised by configuration file

21. FLAVOURS
• each flavour is an application
• holds product specific resources
• contains only product specific code
• should be as minimal as possible

22. ADVANTAGES
Easy to maintain and develop.
Easy to configure.
Resource and code sharing between main flavour and product flavour.

23. DISADVANTAGES
Customisation is extremely hard.
Exponential increase of files and resources.

24. MODULE ARCHITECTURE

25. Main module.
Product module.

26. MAIN MODULE
• set of core functionalities
• default resources
• can be configured by configuration file

27. PRODUCT MODULES
• each module is one app
• product specific code and resources

28. ADVANTAGES
Easy to customise.
Apps are isolated.
Business logic can be product specific.

29. DISADVANTAGES
Hard to maintain.
Losing focus.

30. CUSTOMIZE APP BEHAVIOUR

31. BUILD CONFIG FILE

32. Customise constant values between the apps.

33. productFlavors {
white {
dimension ‘product’
applicationId ‘com.infinum.white’
buildConfigField STRING, GOOGLE_ANALYTICS_ID, ‘”analyticsIdForWhite”’
buildConfigField STRING, API_URL, ‘”www.api.co/white/v1”’
manifestPlaceholders = [urlScheme: “white”]
}
blue {
dimension ‘product’
applicationId ‘com.infinum.blue’
buildConfigField STRING, GOOGLE_ANALYTICS_ID, ‘”analyticsIdForBlue”’
buildConfigField STRING, API_URL, ‘”www.api.co/blue/v1”’
manifestPlaceholders = [urlScheme: “blue”]
}
}

34. HostModule.setEndpoint(BuildConfig.API_URL);
AnalyticsModule.setGoogleAnalyticsId(BuildConfig.
GOOGLE_ANALYTICS_ID);

35. BONUS - CUSTOMISE RESOURCES

36. applicationVariants.all {
resValue XML_STRING, SEARCH_AUTHORITY, applicationId + '.providers.SearchSuggestionsProvider'
}

37. CONFIGURATION FILE

38. Locally cached or obtained from the API.
More flexible that BuildConfig file.
Descriptive method naming.

39. CUSTOMISE APPLICATION ON THE FLY
• enable/disable features
• data flow
• screen flow

40. public interface AppConfig {
boolean isSocialLoginEnabled();
List<MenuItem> getLoggedInUserNavigationMenu();
}

41. public class WhiteConfiguration implements AppConfig {
private static final List<MenuItem> LOGGED_IN_USER_NAVIGATION_MENU = Collections.unmodifiableList(Arrays.asList(
new MenuItem(R.drawable.ic_gamepad, R.string.home),
new MenuItem(R.drawable.ic_settings, R.string.settings),
new MenuItem(R.drawable.ic_settings, R.string.info)
));
@Override
public boolean isSocialLoginEnabled() {
return !BuildConfig.DEBUG || BuildConfig.APPLICATION_ID.endsWith(STAGING_APP_ID);
}
@Override
public List<MenuItem> getLoggedInUserNavigationMenu() {
return LOGGED_IN_USER_NAVIGATION_MENU;
}
}

42. DESCRIPTIVE METHODS
Method names should be descriptive and should not contain product names.
public interface AppConfig {
boolean isWhite();
boolean isBlue();
}

43. PROGRAM TO INTERFACES

44. INTERFACES
Extract functionalities.
Integrate with external dependencies.
Default or product specific implementation.

45. public interface ImageLoader {
void displayImage(ImageView imageView, @NonNull String imageUrl);
void displayImage(ImageView imageView, @NonNull File imageFile);
}

46. @Module
public class ProvidersModule {
@Provides
public ImageLoader provideImageLoader(ImageLoaderType type) {
switch(type){
case GLIDE:
return new GlideImageLoader();
default:
return new PicassoImageLoader();
}
}
provided with
configuration file

47. Include external dependencies only for specific product types.
whiteCompile 'com.github.bumptech.glide:glide:3.6.1'
blueCompile 'com.github.bumptech.glide:glide:3.5.0’

48. GROUP FUNCTIONALITIES IN
FEATURES

49. Features
Each functionality is a feature.
Can be enabled/disabled.
Can be customised.

50. Feature
Contains everything what’s needed
for their integration.
Opened or closed.

51. CUSTOMISATION EXAMPLES

52. Default resources + product specific resources.

53. Default resources + product specific resources.
Same key is needed.

54. Provide presenter implementation per product.

55. Provide presenter implementation per product.
DI has to be handled per product (no default option).

56. Default and product specific behaviour.

57. Default and product specific behaviour.
Interfaces, features and configuration.

58. WHAT?

59. Feature has a default navigation flow, but it has to be customised only for one
or two products.

60. public interface Navigation {
<T> void createTrip(FragmentActivity activity, int
createTripRequestCode, Map<String, T> params);
}

61. public interface NavigationBehaviour {
<T> void startCreateTripScreen(FragmentActivity activity, int createTripRequestCode, Map<String, T>
params);
}

62. public class NavigationManager implements Navigation {
private NavigationBehaviour navigationBehaviour;
public NavigationManager(NavigationBehaviour navigationBehaviour) {
this.navigationBehaviour = navigationBehaviour;
}
@Override
public <T> void createTrip(FragmentActivity activity, int createTripRequestCode, Map<String, T>
params) {
navigationBehaviour.startCreateTripScreen(activity, createTripRequestCode, params);
}
}

63. public class DefaultNavigationBehaviour implements NavigationBehaviour {
@Override
public <Parcelable> void startCreateTripScreen(FragmentActivity activity, int createTripRequestCode,
Map<String, Parcelable> params) {
Intent intent = CreateTripActivity.newIntent(activity, TripType.WALKING, recentStops);
activity.startActivityForResult(intent, createTripRequestCode);
}
}

64. public class BlueNavigationBehaviour implements NavigationBehaviour {
@Override
public <Parcelable> void startCreateTripScreen(FragmentActivity activity, int createTripRequestCode,
Map<String, Parcelable> params) {
Intent intent = GoogleMapsUtils.newIntent(activity, TripType.CAR, recentStops);
activity.startActivityForResult(intent, createTripRequestCode);
}
}

65. public class RedNavigationBehaviour implements NavigationBehaviour {
@Override
public <Parcelable> void startCreateTripScreen(FragmentActivity activity, int createTripRequestCode,
Map<String, Parcelable> params) {
Intent intent = ChromeCustomTabsUtils.newIntent(activity, TripType.CAR, recentStops);
activity.startActivityForResult(intent, createTripRequestCode);
}
}

66. CUSTOMIZE EVERYTHING?

68. When too much customisation is needed.
Different product vision.

69. FLAVOUR MODULE
STAND ALONE
APPLICATION

70. VERSIONING

71. SEMANTIC VERSIONING 2.0.0

72. PATCH UPDATES
Product specific.

73. MINOR UPDATES
Product or system specific.

74. MAJOR UPDATES
Always system specific.

75. APP UPDATES
Mechanism for forcing app updates - PrinceOfVersion.

76. ROUNDUP

77. Thin clients.
Architecture planning.
Offer limited customisation.
Leave the system.

78. Visit infinum.co or find us on social networks:
infinum.co infinumco infinumco infinum
Thank you!
ZELJKO.PLESAC@INFINUM.CO
@ZELJKOPLESAC