Tobias Dürschmid, Matthias Trapp, Jürgen Döllner
Hasso Plattner Institute, University of Potsdam
Potsdam, Germany
Towards Architectural Styles for Android
App Software Product Lines
Case Study
• Image Stylization App SPL with six apps (>60 KLOC)
• Amount of reuse >90%
2Towards Architectural Styles for Android App Software Product Lines
Challenges for Android App SPLs
• No general reuse model for features
Fragments have to have a UI
• Inflexibility of feature models
Static preference entries
• Inapplicability of classical SPL techniques
Lack of tool support for AOP in Android
3Towards Architectural Styles for Android App Software Product Lines
Activity Extensions
• Problem: No general reuse model for activities
• Solution: Modularize concerns in reusable classes
with unique interface
4Towards Architectural Styles for Android App Software Product Lines
Activity Connectors
5Towards Architectural Styles for Android App Software Product Lines
• Problem: Provide custom workflow for each apps
• Solution: Create an activity state machine
Each app refines the activity state machine
SenderActivity × TransitionEvent → TargetIntent
Dynamic Preference Entries
6Towards Architectural Styles for Android App Software Product Lines
• Problem: In Android, user-visible settings are
statically defined in an XML file
• Solution:
– Define a class Preference Record managing preferences
(load / save / reset / set value)
– A Factory creates them conveniently
Separated Behavior Description
7Towards Architectural Styles for Android App Software Product Lines
• Problem: Common domain
but different use cases per
app
• Solution: inject the behavior
and the content of the
concrete apps by separately
defining it using a high-level
configuration language.
Feature Model using Android Resources
8Towards Architectural Styles for Android App Software Product Lines
• Problem: How to apply feature models to Android
apps?
• Solution:
– Define a configuration file in the Android
resources of the core asset module.
– Override the value in sub modules
Conclusions
9Towards Architectural Styles for Android App Software Product Lines
• Simplify developing Android app SPLs
• Tailor apps to different target groups
• High amount of reuse
Contact
10Towards Architectural Styles for Android App Software Product Lines
• Tobias Dürschmid
tobias.duerschmid@student.hpi.de
• Matthias Trapp
matthias.trapp@hpi.de
• Jürgen Döllner
juergen.doellner@hpi.de
http://www.4dndvis.de
https://hpi.de/doellner/index.html
https://www.youtube.com/user/HPICGS
This work was funded by the Federal Ministry of
Education and Research (BMBF), Germany within the
InnoProfile Transfer research group "4DnD-Vis".

Towards Architectural Styles for Android App Software Product Lines

  • 1.
    Tobias Dürschmid, MatthiasTrapp, Jürgen Döllner Hasso Plattner Institute, University of Potsdam Potsdam, Germany Towards Architectural Styles for Android App Software Product Lines
  • 2.
    Case Study • ImageStylization App SPL with six apps (>60 KLOC) • Amount of reuse >90% 2Towards Architectural Styles for Android App Software Product Lines
  • 3.
    Challenges for AndroidApp SPLs • No general reuse model for features Fragments have to have a UI • Inflexibility of feature models Static preference entries • Inapplicability of classical SPL techniques Lack of tool support for AOP in Android 3Towards Architectural Styles for Android App Software Product Lines
  • 4.
    Activity Extensions • Problem:No general reuse model for activities • Solution: Modularize concerns in reusable classes with unique interface 4Towards Architectural Styles for Android App Software Product Lines
  • 5.
    Activity Connectors 5Towards ArchitecturalStyles for Android App Software Product Lines • Problem: Provide custom workflow for each apps • Solution: Create an activity state machine Each app refines the activity state machine SenderActivity × TransitionEvent → TargetIntent
  • 6.
    Dynamic Preference Entries 6TowardsArchitectural Styles for Android App Software Product Lines • Problem: In Android, user-visible settings are statically defined in an XML file • Solution: – Define a class Preference Record managing preferences (load / save / reset / set value) – A Factory creates them conveniently
  • 7.
    Separated Behavior Description 7TowardsArchitectural Styles for Android App Software Product Lines • Problem: Common domain but different use cases per app • Solution: inject the behavior and the content of the concrete apps by separately defining it using a high-level configuration language.
  • 8.
    Feature Model usingAndroid Resources 8Towards Architectural Styles for Android App Software Product Lines • Problem: How to apply feature models to Android apps? • Solution: – Define a configuration file in the Android resources of the core asset module. – Override the value in sub modules
  • 9.
    Conclusions 9Towards Architectural Stylesfor Android App Software Product Lines • Simplify developing Android app SPLs • Tailor apps to different target groups • High amount of reuse
  • 10.
    Contact 10Towards Architectural Stylesfor Android App Software Product Lines • Tobias Dürschmid tobias.duerschmid@student.hpi.de • Matthias Trapp matthias.trapp@hpi.de • Jürgen Döllner juergen.doellner@hpi.de http://www.4dndvis.de https://hpi.de/doellner/index.html https://www.youtube.com/user/HPICGS This work was funded by the Federal Ministry of Education and Research (BMBF), Germany within the InnoProfile Transfer research group "4DnD-Vis".

Editor's Notes

  • #4 Patterns are reusable not their implementation Design Pattern können als Workarounds für von der Sprache unbeachtete Modularisierung betrachtet werden.