Preventing Analytics and Ads from polluting your codebase

The need for monetization is an unavoidable fact in today's mobile industry. Key to achieving that is the need for user behaviour analytics and, in many cases, in-app native advertising. More often than not though, these needs end up producing spaghetti code that is mixed in with business logic code that hinders maintenance and feature development.

In this talk, I'll be presenting techniques for dealing with such, peripheral to your code, requirements. We'll investigate ways to isolate code related to Analytics and Ads, from your business logic and also touch, briefly, on strategies for testing such concerns separately from the main feature requirements.

Transcript

1. 10-12 September 2015 droidcon Greece Thessaloniki
2. Preventing Analytics and Ads from polluting your codebase Lightweight android lifecycle annotations Savvas Dalkitsis Senior software engineer at Shazam @geeky_android
3. Analytics
4. Ads
5. AOP
6. Look at all the pretty diamonds
7. http://shazam.github.io/android-aspects/ android-aspects
8. DEMO
9. •  Use cautiously •  Only for pure cross cutting concerns •  Don’t be afraid to move aspects back to business logic if over time it becomes apparent that it belongs there •  For uber-cross-cutting concerns (like global session management) you can use Application.registerActivityCallbacks Conclusions AOP is very powerful but very dangerous. “If all you have is a hammer, everything looks like a nail”
10. •  Pageviews •  Ads •  Implicit userevent parameters (screen name plus more) •  FAB •  HierarchyViewer aspect for debugging •  more to come… How do we use this @Shazam?
11. Butterknife Aspects: https://github.com/savvasdalkitsis/butterknife-aspects Demo repo: https://github.com/savvasdalkitsis/android-aspects-example Examples
12. Savvas Dalkitsis Senior software engineer / Shazam @geeky_android Thank you! droidcon Greece Thessaloniki