Summoning a Zombie App

Slides for the Speech with the same name at BetabeersGRX, 2015/07/08.

Transcript

1. << A real story about targeting our efforts >> Summoning a Zombie App Victor Olmo Gallegos Hernández Mobile developer
2. MyTricks Notebook. The beginnings ◦ 2012 - Side project ◦ Satisfying my own needs ◦ Learning native development (Android SDK)
3. About the App ◦ Personal notebook for Breakdance (bboying) ◦ Store your tricks by categories ◦ Add pictures, videos, text commentaries
4. About the App - Beginnings ◦ Standalone App (not published) ◦ Very good feedback from friends ◦ A whole lot of motivation ◦ Helping everybody would be a good idea ◦ … Google Play submission - late 2012
5. Google Play submission ◦ Really good feedback ◦ Lots of propositions (some of them reasonable, some not) ▪ Support for bboying music* ▪ an iOS version ▪ Cloud storage - “MyTricks everywhere” ▪ hoyga usted se puede acer millionaire con este projecto todo lo que nesesita es mi ayuda dejeme esplicarle porfabor ◦ After some early versions, App was looking much better and got more stable
6. … Some months L8r...
7. Marketshare ◦ Mostly Android 2 ◦ A few Android 4 devices ◦ 5 or 6 Android 3 tablets ◦ Entry-level devices ◦ no money
8. Scaling, next steps ◦ First implementations ◦ Credits ◦ Backup ◦ “Quote of the day” ◦ First social implementation - Calendar ◦ Didn’t want to depend on Internet ◦ Parse traffic limitation ( 1M requests / month! ) ◦ RULE: Altruist project - no money involved
9. First mistakes when becoming social ◦ Credits showing “visit FB site to appear here” ◦ Quote of the day saying “tweet us your quote of the day” ◦ Very low impact ◦ Direct messages to friends gave much more results
10. First mistakes when becoming social ◦ Credits showing “visit FB site to appear here” ◦ Quote of the day saying “tweet us your quote of the day” ◦ Very low impact ◦ Direct messages to friends gave much more results
11. First mistakes when becoming social ◦ Solution: Directly posting Messages on the App ◦ Big effort to eliminate internet dependency ◦ Big effort to save Parse requests ◦ Caching ◦ Access control ◦ Big effort on moderation / avoid trolling ◦ Prepairing the App for high usage rates ◦ “The QR anecdote”
12. Results ◦ Very few usage of the social features ◦ Very few social network activity ◦ App is being used as standalone ◦ Downloads increase, but… ◦ Active installs are frozen, or decreasing
13. … And so went 2014 ◦ Mass of standalone users ◦ Not knowing about each other (neither do I) ◦ App is not dead, but not as alive as I’d like - “Zombie”
14. … And so went 2014 ◦ Mass of standalone users ◦ Not knowing about each other (neither do I) ◦ App is not dead, but not as alive as I’d like - “Zombie”
16. First successful steps ◦ Successful social implementations (more interest in the App) ◦ Chat (Quotes with response) ◦ Bboying music!! (SoundCloud hack) ◦ Bboying Map!! ◦ Push support, accurate segmentation ◦ “News indicators” ◦ Started UI Redesign (strictly necessary?) ◦ Not worrying about traffic anymore
17. Results come, be patient... ◦ More installs ◦ Updates come slowly, but are coming
18. Good news ◦ Much more usage of the App! ◦ Good (and bad) feedback ◦ French translation!
19. First successful steps. Cool !! I’m breakin’ @ Syntagma Square using MyTricks
20. Some tips...
21. Keys that brought success Stay ~one year behind the latest (widespread marketshare) Don’t rush with the (big) changes Don’t marry the wrong person (libs) Your reputation costs more than 40$ DONE is better than PERFECT (Sometimes)
22. Keys that brought success Stay ~one year behind the latest (widespread marketshare) Don’t rush with the (big) changes Don’t marry the wrong person (libs) Your reputation costs more than 40$ Sometimes DONE is better than PERFECT
23. Stay ~one year behind the latest No Material UI (obviously) No Wearable support (2012-2013) No ActionBar support (see “don’t marry the wrong person”)
24. Keys that brought success Stay ~one year behind the latest (widespread marketshare) Don’t rush with the (big) changes Don’t marry the wrong person (libs) Your reputation costs more than 40$ Sometimes DONE is better than PERFECT
25. Don’t rush with the big changes ORM layer refactoring? DONE is better than PERFECT Camera pictures support - Duplicated impl. CLEAN, MVP, DI
26. Keys that brought success Stay ~one year behind the latest (widespread marketshare) Don’t rush with the (big) changes Don’t marry the wrong person (libs) Your reputation costs more than 40$ Sometimes DONE is better than PERFECT
27. Don’t marry the wrong person Handmade ORM layer (no external libs) • AndroidRecord • SugarORM • ORMLite • GreenDAO No usage of ActionBarSherlock (past) Soft ActionBarCompat integration dagger rules, but… dagger2 came l8r
28. Keys that brought success Stay ~one year behind the latest (widespread marketshare) Don’t rush with the (big) changes Don’t marry the wrong person (libs) Your reputation costs more than 40$ Sometimes DONE is better than PERFECT
29. Your reputation costs more than 40$ Reject agressive commercial campaigns Don’t try to sell rubbish Don’t bother your users with commercial stuff
30. App lifecycle tips is your App falling in ZOMBIE STATE?
31. App lifecycle tips I blow ya’ head off hey wassup with you wat u sayin bout me ?!?! At least try to get a DECENT ZOMBIE!
32. Keeping your App safe ◦ Adopt & follow naming conventions ◦ Always depend on abstractions, not concretions ◦ CLEAN your code - Separate responsibilities ◦ Cover everything with Tests
33. Keeping your App safe ◦ Adopt & follow naming conventions ◦ Always depend on abstractions, not concretions ◦ CLEAN your code - Separate responsibilities ◦ Cover everything with Tests
34. Naming conventions: Example Use case: Listing Customers CustomersActivity CustomersFragment activity_customers.xml fragment_customers.xml @+id/customers_list row_customer.xml @+id/customer_txt_title @+id/customer_img_thumbnail
35. Naming conventions: Important thing They bring execution-time errors to compilation time!! row_customer.xml @+id/txt_title row_event.xml @+id/txt_title findViewById(R.id.txt_title) row_customer.xml @+id/customer_txt_title row_event.xml @+id/event_txt_title findViewById(R.id.customer_txt_title) Danger. CHECK !! Safer
36. Keeping your App safe ◦ Adopt & follow naming conventions ◦ Always depend on abstractions, not concretions ◦ CLEAN your code - Separate responsibilities ◦ Cover everything with Tests
37. Always depend on abstractions CustomersActivity <<abstract>> GetCustomers + get(Listener) GetCustomersApiImpl GetCustomersDBImpl
38. Keeping your App safe ◦ Adopt & follow naming conventions ◦ Always depend on abstractions, not concretions ◦ CLEAN your code - Separate responsibilities ◦ Cover everything with Tests
39. CLEAN your code - separate resp. ◦ MVP, MVVM ◦ CustomViews ◦ Interactor Pattern ◦ DataSources ◦ Retrofit ◦ Gson, SimpleXML ◦ Pass dependencies on constructor ◦ Code smells ◦ RecyclerView ◦ Boundaries ◦ etc. @ voghDev
40. Keeping your App safe ◦ Adopt & follow naming conventions ◦ Always depend on abstractions, not concretions ◦ CLEAN your code - Separate responsibilities ◦ Cover everything with Tests … A very desirable TODO
41. TagCloud: Android miscellaneous Clean code SOLID Builder Pattern parcelabler WTF / min RxJava Material Design Renderers Lazy Parsing Model-View-Presenter DataBinding RecyclerView Dalton Pattern ViewModel Mocking Live Templates Boilerplate code ButterKnife Z-Vectoring Kitt Calls Bitmap recycling Mortar Flow PorterDuff GeoPoint Reflection CardView
42. TagCloud: Android miscellaneous Clean code SOLID Builder Pattern parcelabler WTF / min RxJava Material Design Renderers Lazy Parsing Model-View-Presenter DataBinding RecyclerView Dalton Pattern ViewModel Mocking Live Templates Boilerplate code ButterKnife Z-Vectoring Kitt Calls Bitmap recycling Mortar Flow PorterDuff GeoPoint Reflection CardView WTF ? ? wtf is dat sheet
43. And that’s all folks Q & A & T Questions & Answers & Trolling
44. And that’s all folks Q & A & T Questions & Answers & Trolling Una vaina looocaaaa....
45. And that’s all folks Q & A & T Questions & Answers & Trolling
46. Interesting… tell me more