This the first ‘Mobile forum’ event I’ve seen in New york. Invite only and held at the facebook office at Astor place. The format was based around small groups brainstorming and open discussion, then group facilitators would present key points to all attendees.
here are the top take aways I had:
You should try out Slack for internal communications
I heard Slack recommended throughout discussion. Especially its search functions. I actually haven’t had the chance to use it, but am now very keen.
Train web developers into native
Mobile teams need more developers than the market can handle, and web is becoming a secondary platform to native. Etsy spoke about having dedicated roles for training into the native space. Identify developers who are keen to make the transition and give them full support.
Build a testing culture, but tread lightly
The tools are still in infacy to support native TDD, and they probably will never get to a level when testing can be fully embraced. Culture spawned from the web world (where testing is simpler) have transitoned and can adversely impact delivery if taken at full speed.
Modularise code bases into libraries
Modular code is a given, but splitting your app into libraries takes an extra level of foresight. The tools are not great, and you will incur overhead costs, but some time in the future you will need to draw a line in the sand and split your architecture out.
Force yourself to have 1-on-1’s
Giving and receiving feedback is not natural, but without it teams and the individuals will have trouble growing. The 1-on-1 gives a unique opportunity to get a certain level of honesty. It keeps you accountable and gets feelings out in the open. Especially important in remote teams, but I would recommend regular 1-on-1’s in all dev teams.
Pull based API schemas
Facebook’s mobile app pulls lots of data, and with large teams and large data needs they experienced overfetching (too much data coming back, makes managing responses sluggish) and underfetching (where the API data does not match the needs of the client so additional round trips are needed). As far as I understood it, A pull based API means that:
- You have only 1 endpoint
- The client specifies an entity schema and gets back a token. e.g:
- The token is then stored on the client, and used to request the exact data it needs for all future requests
- The API never deletes fields, or has relaxed deprecation
- The API only sends back what is requested. This addresses over/under fetching problems
- A GET request may look like:
1 2 3
At Meetup this problem existed as well. We were requesting additional fields all the time. Scaling the schema identifiers may cause problems but overall i like this approach
Really liked the peer-to-peer discussions. I was having conversations about identical problems others had faced and insights into their unique solutions. I’d like to see some more controversial, ‘out of the box’ topics next time. And maybe splitting platform specific discussions to their respective audience (I was not too interested in Android JVM issues presentation).