Mobile Developers Talks: Delve Mobile
Download as PPTX, PDF1 like536 views
The document details the development process and technical aspects of 'Office Delve,' a mobile application for Office 365, led by a team that initially started with two developers and has grown to include several Android and iOS developers. It discusses the use of various technologies such as dependency injection, design patterns, and testing strategies while highlighting tools like Dagger and Mockito for development and testing purposes. Additionally, it reflects on feedback and analytics from users, learning from cross-platform design challenges and user engagement metrics.
Mobile Developers Talks: Delve Mobile
- 1. Office Delve – for Office 365 Konstantin Loginov
- 2. About me • 7 years in Mobile development: Windows Mobile webOS Windows Phone 7/8 iOS (native/Xamarin) Android Current Position: Software Engineer in Microsoft LinkedIn / email
- 3. Office Delve • “Flipboard for Office365” © • Code name: Oslo • Tangled creation story
- 4. Steps towards Delve Mobile
- 5. Steps towards Delve Mobile • Started as a team of two • Android first • Pivoted multiple times & created various MVPs • Application as an engagement driver for the whole service
- 6. Development
- 7. Working process • Non-formal Scrum, 2-weeks-long sprint • Bi-weekly releases • Team Foundation Server 2013 for task tracking • Slack for team collaboration (love it!) • GIT as revision control system • Android studio (latest Canary build) as an IDE • Internal tool for bug-tracking and code reviews • OneNote as a knowledge base • Today: 4 Android devs & 3.5 iOS devs
- 8. We love opensource • Dagger (dependency injection) • ButterKnife (view injection) • EventBus • Retrofit • OkHttp • Picasso • Esty StaggeredGridView • Compatibility libs Upcoming: Mortar & Flow. (As others, we Square ) • Mockito (Testing) • AssertJ (Testing)
- 9. Design patterns we use • Dependency injection • Publish–subscribe pattern • Data Access Object
- 11. Dependency Injection - Dagger class DataProvider { DataSource dataSource = new DelveApi(); } class DataProvider { @Inject DataSource dataSource; } 11 class DataProvider { private DataSource dataSource; @Inject DataProvider(DataSource dataSource) { this.dataSource = dataSource; } }
- 12. Dependency Injection - Dagger • Standard javax.inject annotations (JSR-30) • Need to declare “modules” for compile-time validation and code generation • Specifies “provider” methods • @Singleton annotation • Lists supported classes (which in turn generates code) • Supports override • Inject mocks in tests • Substituting back-ends is a one-line change
- 13. Dependency Injection - Dagger 2 • Just released • No reflection, no ObjectGraph/Injector, @Component interface • We’re planning to switch to it soon
- 14. Publish–subscribe pattern - EventBus • We use greenrobot/EventBus • Performs well with Activities, Fragments, and background threads • Decouples event senders and receivers • Avoids complex and error-prone dependencies and life cycle issues
- 15. Activity (hosts fragments) Data Access Layer (Subscriber) Fragment A Fragment B Data Subscriber Error Subscriber ERROR Navigation Event Subscriber Data Subscriber Open Fragment A
- 16. Data Access Object • DAO is an object that provides an abstract interface to the database. By mapping application calls to the persistence layer, DAO provides specific data operations without exposing details of the database. User User getById(String userId) List<User> queryMatch(String q, int l, int o) SqlLocalStorageUserDao User getById(String userId) { /* Getting data from SQLite */ } List<User> queryMatch(String q,int l,int o) { /* Getting data from SQLite */ } UserDaoImpl DataProvider Layer …. localStorage.getUser(userId); …. UserDao userDao; User getUser(String userId) { return userDao.getUserById(userId); } String userId;
- 25. Pinterest-style navigation model • V1 Pros: • Gestures between tabs • Easy to implement Cons: • 3 «heavy» pages in ViewPager • No Tab-switching-buttons in Profile/Document pages
- 29. Pinterest-style navigation model • V2 Pros: • Still easy to implement • Pretty effective • Tab-buttons everywhere Cons: • No gestures • Not keeping state of not-selected tab-fragments
- 34. Pinterest-style navigation model • V3 (current) Pros: • Should be familiar for instagram users Cons: • Ugly in implementation • Breaking OS design-guidelines
- 35. Pinterest-style navigation model – Going forward • V4 (future) Yeah! We like changes in Navigation model • Side nav as the way of switching between pivots • Material design
- 36. Testing
- 37. Testing • Manual testing • Alpha & Beta programs • Unit tests (Test Coverage 75+%) Mockito AssertJ • Monkey testing ( adb shell monkey -p com.microsoft.delvemobile -v 10000 ) • Memory profiling
- 38. Mockito • Mocks made easy • Don’t “expect” before the fact; query object afterwards • Simple to use • Stages of a test • Setup (as necessary) • Test • Verification 38
- 39. Mockito: Verify Interactions // mock creation List mockedList = mock(List.class); // using mock object; observe that it didn't throw any // "unexpected interaction exception" exception mockedList.add("one"); mockedList.clear(); // selective & explicit verification verify(mockedList).add("one"); verify(mockedList).clear(); 39
- 40. Mockito: Verify Interactions 2 verify(mockedList, times(2)).add("one"); verify(mockedList, atLeastOnce()).add("one"); verify(mockedList, never()).clear(); 40
- 41. Mockito: Stub Method Calls // you can mock concrete classes, not only interfaces LinkedList mockedList = mock(LinkedList.class); // stubbing; before the actual execution when(mockedList.get(0)).thenReturn("first"); // the following prints "first" System.out.println(mockedList.get(0)); // the following prints "null" because get(999) was not stubbed System.out.println(mockedList.get(999)); 41
- 42. Mockito: Advanced Features • Spy: Partial stubbing of real object through proxy • Mocking by annotation • Argument matching 42
- 43. AssertJ: Readable Asserts Regular JUnit assertEquals( View.GONE, view.getVisibility()); AssertJ Android assertThat(view).isGone(); 43 public static final int GONE = 0x00000008;
- 44. AssertJ: Readable Assert Chaining Regular JUnit assertEquals(View.VISIBLE, layout.getVisibility()); assertEquals(VERTICAL, layout.getOrientation()); assertEquals(4, layout.getChildCount()); assertEquals(SHOW_DIVIDERS_MIDDLE, layout.getShowDividers()); AssertJ Android assertThat(layout) .isVisible() .isVertical() .hasChildCount(4) .hasShowDividers( SHOW_DIVIDERS_MIDDLE); 44
- 45. Analytics & Crashalitics We use (on both platforms): • Crittercism (http://www.crittercism.com/) • MixPanel (https://mixpanel.com/) • AppFigures (https://appfigures.com/) Data reviewed daily
- 46. Crittercism • Automated Crash logging • Automated network request logging • Breadcrumbs • Handled exceptions logging • Alarms & lifetime dashboard • latency • error rate • request volume
- 47. Crittercism: cases • Delve Mobile crashed 44 times (14-26 April) • Our crash rate: • Average crash rate:
- 48. Crittercism: our crashes • Most popular crash (50+% of total number):• Breadcrumbs we got:
- 49. MixPanel • Funnels • User-events • Measure user’s retention & engagement
- 50. Feedback we got Feedback we got through feedback-form: • Disabling notifications feature-request • Empty documents feed issues
- 51. Things we learn • Cross-platform design does not work • Square rocks • Majority of our users are using Android 5.0+ • Learn about your users before start: majority of our users are using iOS (~1:3) • Fragments are bad • Crittercism is amazing