Mobile App Showcase: Tuenti

Tuenti has one of the most popular Spanish mobile apps with millions of monthly active users. Want to know how it was built?

Transcript

1. Mobile App Showcase
2. Who are we? @luisrecuenco Luis Recuenco iOS Voice Team Eduardo González @ieduardogf iOS Core Team
3. 1. A little bit of history ! 2. Process & release workflow ! 3. Testing ! 4. Libraries and architecture
4. A little bit of history
5. Tuenti 1.0 • 21 January, 2010. • No API at the beginning. It was created along the way. • Only one dev.
7. Tuenti 2.0 • 13 April, 2011, a year later. • Big feature: push notifications. • As Tuenti 1.0, almost no help from design. • Again, only one dev. Created in his free time.
11. Tuenti 2.X • Comms & social iterations. • Too much work for one person… • Mobile team started to grow. • Three people in september 2011 Dani Miguel Luis
12. Change of strategy
13. Messenger • Started development in december, 2011. • Focused on communication with a slight social layer. • Objective: communications tool
14. Meanwhile… Tuenti app was frozen
15. Not even adapted to the iPhone 5!
16. It never was…
18. • Change of direction: giving back some importance to social. • Claim: The easiest way to share experiences with the people that matter right now. • October 2012: Messenger hit the app store. • Rebranding: Tuenti Social Messenger | Tuenti Classic
20. 3.5
21. Problems • Tuenti brand is “strong”. Difficult to be considered a messenger. • 1.0 quite incomplete. • Mobile Team getting bigger. • Not Mobile First first yet.
22. Dani Miguel Luis Sergio Víctor Edu
23. Sharing Comms Core
24. Almost 1 year later…
25. Fully mobile first philosophy
26. Sharing Cloud Phone Core Growth Tent Comms
27. 12 developers!
28. 1 app!!!
31. 30 developers
32. New Mobile • One Core Team: support • Product teams: • Sharing (MAD) • Comms (MAD) • Cloud Phone (MAD) • Growth (BCN) • Tent (BCN)
33. Change of strategy
34. Yes, another one
35. Two forces…
37. Social
39. Telco 2.0
40. Users
42. Customers
44. • Core Team • Voice • Messaging • Account • Social • Onboarding (BCN) • Acquisition (BCN)
45. Process & release workflow
46. Plan—>Develop—>Distribute
47. Plan—>Develop—>Distribute
48. AGILE Scrum
49. Stop starting, Start finishing
50. 2 weeks sprint
51. Plan Jira
52. Plan • Support for manage SCRUM boards • Create a user story / bug / task • Every commit needs a ticket (hook on repository) • Estimate. Visualize remaining time • Assign directly to developer in charge of the feature
55. Plan—>Develop—>Distribute
56. Version control GIT
58. Development Process Flow • Develop features • commit and push code to repository • create unit/acceptant test. Run them!!! • Fix things. • Meetings!! • More and more code
59. No matter who. No matter what. No matter when. Short term. Long term. Any term. Writing good code is ALWAYS faster than writing bad code.! ROBERT MARTIN (@UNCLEBOB)
60. Code Reviews FishEye & Crucible
61. Code Reviews • Ensure developers follow coding standards • At least 2 developers must “pass” the review to be able to close it. • “It’s nothing personal” • Be proactive with your comments.
63. Continuous Integration Jenkins
64. Continuous Integration • Jenkins / 2 mac minis • Jobs for server and client • Jobs create on command line • tu-jenkins create-dev (unit) • tu-jenkins create-nightly (full regresion) • tu-jenkins pre-integrate <ticket-number> • Unit test every push / instant feedback for the developer • Every night unit and acceptant test execute • Email every morning to the branch owner.
65. Branch Integration Process • Feature is code complete • Tested and QA approved • All the API dependencies are working in live • Translations added and reviewed by QA/PM • Unit and acceptant test!! • Has latest integration merged (with blue ball)
67. Flow (Jira+Jenkins+SCM)
68. Plan—>Build—>Distribute
69. Distribution HockeyApp
70. Use your app!
71. Distribution • Rake hotapps (everything automated) • Clean, checkstyle, archive & upload to Hockeyapp • Distribute betas internally in an easy way • Also used for collect crash reports, find bugs • Previously we had Crashlytics • Rake appstore
72. Go to market
73. Release Process Flow • We have enough to go live (Product Team) • We take latest stable (blue ball) changeset from integration and create a new Release Candidate branch • QA team makes a regression • 3 days, if something is discovered, release cancelled • Send to Apple!! • Merge back to master, integration and TAG
74. Release Process Flow
76. 1 week…
77. –Edsger W. Dijkstra “Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence”
78. Testing
79. How many of you test your code?
80. Unit + Acceptant Tests
81. Unit Tets • Mocking: OCMockito ! • Assertions: OCHamcrest
82. Jon Reid
83. http://qualitycoding.org/
87. Acceptant Tests • Before: Frank + cucumber ! • Now: KIF
88. Frank + cucumber
89. # coding: utf-8 # Author:: David Pastor (mailto:dpastor@tuenti.com) ! Feature: Login Screen ! Background: Given I launch the app And in the start screen I go to the login ! # Regular login ! @QAke(1982) Scenario: Verified new messenger user logs in and skips sync process Given a user: "myself" exists with verified: true When in the login screen I do login skipping synchronization with "myself" Then in the conversations screen I check that is the current screen
90. class LoginScreen < Base ! element :incorrect_credentials_label, "view:'UILabel' marked:'Oops! Make sure your…’” element :login_button, "view:'UIButton' marked:'Log In'" element :forgot_password_button, "view:'UIButton' marked:'UITextFieldForgotButton'" ! def navigation_bar @navigation_bar ||= NavigationBar.new(:title => "Log In") do |bar| bar.add_element :join, "view:'UIButton' marked:'Join Tuenti'" end end ! def email_text_field TextField.new("view:'TMPaddingTextField' index:0", :placeholder => "Email") end ! def password_text_field TextField.new("view:'TMPaddingTextField' index:1", :placeholder => "Password") end
91. def check_that_is_the_current_screen navigation_bar.check_displayed end def submit_credentials(email, password) fill_the_credentials(email, password) login_button.touch end
92. Problems • Very slow… • We didn’t like cucumber. • We wanted something in Objective-C if possible, not ruby.
93. KIF
94. #import "TMKIFScreen.h" ! @interface TMLoginKIFScreen : TMKIFScreen ! // Convenience - (void)loginWithEmail:(NSString *)email password:(NSString *)password; ! // Login button - (void)tapOnTheLoginButton; - (void)checkLoginButtonEnabled:(BOOL)expectedEnabled; ! // Email text field - (void)typeIntoEmailTextField:(NSString *)string; - (void)clearEmailTextField; ! @end
95. - (void)loginWithEmail:(NSString *)email password:(NSString *)password { [self typeIntoEmailTextField:email]; [self typeIntoPasswordTextField:password]; [self tapOnTheLoginButton]; }
96. - (void)typeIntoEmailTextField:(NSString *)string { [self.actor enterText:string intoViewWithAccessibilityLabel:kEmailTextFieldAccessibilityLabel]; } - (void)typeIntoPasswordTextField:(NSString *)string { [self.actor enterText:string intoViewWithAccessibilityLabel:kPasswordTextFieldAccessibilityLabel]; }
97. - (void)checkForIncorrectCredentialsErrorFeedback { [self.actor waitForViewWithAccessibilityLabel:kIncorrectCredentialsFeed backAccessibilityLabel]; }
98. Dependency Injection
99. sharedInstance is “bad”
100. Typhoon
101. When we didn’t test…
102. @interface TMGetEventInfoOperation : TMServiceOperation ! @end @implementation TMGetEventInfoOperation ! - (void)doMain { ... NSArray *unknowns = [[TMUserParser parser] parseUsers:unknownsFromJSON]; ! [[TMUserStorage sharedStorage] addAsUnknowns:unknowns]; ... } ! @end
103. Now that we do test…
104. @interface TMGetEventInfoOperation : TMServiceOperation @property (nonatomic, strong) TMUserParser *userParser; @property (nonatomic, strong) TMUserStorage *userStorage; @end @implementation TMGetEventInfoOperation ! - (void)doMain { ... NSArray *unknowns = [self.userParser parseUsers:unknownsFromJSON]; ! [self.userStorage addAsUnknowns:unknowns]; ... } ! @end
108. Not so clean headers Mock dependencies
110. Libraries & architecture
111. Libraries
113. Not yet
114. git submodules
116. • XMPPFramework • Reachability • Mixpanel • Cordova • HockeySDK • TheAmazingAudioEngine • Typhoon • KIF • libextobjc
117. libextobjc
118. __weak typeof(self) wself = self; __strong typeof(wself) sself = wself;
119. @weakify(self) @strongify(self)
120. @weakify(self); self.albumKVOToken = [self.album addObserverForKeyPath:@“photoMoments” block:^(id obj, NSDictionary *change) { [self doWhatever]; }];
121. @weakify(self); self.albumKVOToken = [self.album addObserverForKeyPath:@“photoMoments” block:^(id obj, NSDictionary *change) { @strongify(self); [self doWhatever]; }];
122. @weakify(self); self.albumKVOToken = [self.album addObserverForKeyPath:@“photoMoments” block:^(id obj, NSDictionary *change) { @strongify(self); dispatch_async(dispatch_get_main_queue(), ^{ [self doWhatever]; }) }];
123. MULTITHREADING IS EVIL
124. WE LOVE FIRING NSOPERATIONS
125. 300 THREADS!
126. @synthesizeAssociation(CLASS, PROPERTY)
128. KVO & NSNotifications
129. @interface NSObject (TUKVODoneRight)
130. self.commentKVOToken = [comment addObserverForKeyPath:@keypath(comment.state) block:^(id obj, NSDictionary *change) { // Comment state just changed }]; @property (nonatomic, copy) NSString *commentKVOToken;
131. - (void)dealloc { [_comment removeObserverForKeyPath:@keypath(state) token:_commentKVOToken]; }
133. THObserversAndBinders https://github.com/th-in-gs/THObserversAndBinders
134. self.commentObserver = [THObserver observerForObject:comment keyPath:@keypath(comment.state) block:^{ // Comment state just changed ! }]; @property (nonatomic, strong) THObserver *commentObserver;
135. No hacky swizzling to unsubscribe!
136. LRNotificationObserver https://github.com/luisrecuenco/LRNotificationObserver/
137. Networking
139. We love Mattt
     
140. NSHipster
141. We also love reinventing the wheel
142. Tuenti API Client
143. NSOperationQueue based Aware of network changes to handle concurrency Cancellation, ops dependencies
144. NSInteger const kWiFiMaxOperationCount = 6; NSInteger const kWWANMaxOperationCount = 2; NSInteger const kWiFiMaxUploadOperationCount = 2; NSInteger const kWWANMaxUploadOperationCount = 1;
145. Persistence
146. Core Data
147. Mogenerator
148. Saving plists is fine
149. Architecture
151. http://cleancoders.com/
152. Massive View Controller
154. MVP
155. MVVM
156. Reactive Cocoa
159. Storages
161. Just intelligent arrays
162. Multicast delegate
163. @protocol TMAlbumStorageDelegate <NSObject> ! @optional - (void)albumStorage:(TMAlbumStorage *)albumStorage didUpdateAlbumsForUser:(TMUser *)user withAlbums:(NSArray *)albums; ! - (void)albumStorage:(TMAlbumStorage *)albumStorage didUpdateAlbumWithId:(NSString *)albumId; ! @end
164. @interface TMAlbumStorage : NSObject ! - (void)addAlbum:(TMAlbum *)album; - (void)removeAlbum:(TMAlbum *)album; ! - (NSArray *)albumsForUser:(TMUser *)user; ! - (void)addDelegate:(id<TMAlbumStorageDelegate>)delegate delegateQueue:(dispatch_queue_t)delegateQueue; ! - (void)removeDelegate:(id<TMAlbumStorageDelegate>)delegate delegateQueue:(dispatch_queue_t)delegateQueue; ! - (void)removeDelegate:(id<TMAlbumStorageDelegate>)delegate; ! @end
165. GCDMulticastDelegate<TMAlbumStorageDelegate> *multicastDelegate
166. Networking Service Layer
168. Dictionary with ongoing operations Operations must have a id<NSCopying> token Listen to isFinished keypath via KVO to remove operation from dictionary
169. - (id<TMServiceOperation>)getAlbumInfoForAlbumId:(NSString *)albumId user:(TMUser *)user { return [self cachedOperationWithFallback: [self.getAlbumInfoOperationProvider operationWithAlbumId:albumId user:user]]; }
170. - (void)doMain { TURequestOperation *getAlbumInfoOp = [self.requestOperationProvider operationWithName:kGetAlbumInfoOperationName]; [getAlbumInfoOp addValue:self.albumId forArgument:kAlbumIdParameterName]; getAlbumInfoOp.successBlock = ^(TURequestOperation *operation, NSDictionary *response) { TMAlbumParser *parser = [[TMAlbumParser alloc] init]; TMAlbum *album = [parser parseAlbumForUser:self.user withDictionary:response[kAlbumResponseKey]]; [[TMAlbumStorage sharedStorage] updateAlbumsForUser:self.user withAlbums:@[album]]; self.album = [[TMAlbumStorage sharedStorage] albumForId:album.albumId user:self.user]; }; getAlbumInfoOp.failureBlock = ^(TURequestOperation *operation, NSDictionary *response, NSError *error) { }; [self startRequest:[getAlbumInfoOp asRequest]]; }
171. Cell architecture
176. TMFeedItemCellControllerFactory Introspection of model object isKindOfClass, double dispatch, polymorphism
177. <TMFeedItemCellControlling> creates cell handle tap on cells height of cell
178. TMFeedItemCellController injected handlers/interactors invoked when events in the cell forwarded to the controller
179. Cell Controllers are reusable Handlers are reusable
180. Tuenti Image Client
181. Two level cache (mem + disk)
185. @interface UIImageView (TMNetImagePresenter) ! - (void)tm_presentImageFromURL:(NSURL *)imageURL; ! @end
186. - (void)tm_presentImageFromURL:(NSURL *)imageURL { TMNetImagePresenter *presenter = [TMNetImagePresenter netImagePresenterWithURL:imageURL]; self.imagePresenter = presenter; [presenter presentImage]; }
187. - (void)presentImage { [self cancelOperation]; ! CGSize size = self.imageView.frame.size; ! UIImage *image = [TUNetImageProvider imageFromURL:self.imageURL size:size]; if (image) { // Image in memcache. [self updateViewWithImage:image]; } else { [self updateViewWithImage:self.defaultImage]; self.operation = [TUNetImageProvider obtainImageFromURL:self.imageURL size:size delegate:self]; } }
188. LRImageManager https://github.com/luisrecuenco/LRImageManager
189. QUESTIONS?
190. We are hiring! talent@tuenti.com