Formerly known as the mdevcon, the Amsterdam conference related to mobile development - now called AppDevCon - took place on March, 17th. We had the chance to attend this edition in the Pathe Arena. Here is summary of what we have learned and our thoughts concerning some talks.

MVP - Lean

The power of small (opening keynote), by Cesare Rocchi

The speaker praised the smallness. In three aspects.

• First, small market: consider attacking a niche, there is no big companies and less competition. You have a faster access to the decision makers (CEO etc.)
• Second, small team: there is less inertia, less meetings, no process (which is more pleasant), less distance between the employees and the customers.
• Third, small launch: make soft launch with a reduced amount of people and testers, for instance: Buffer started with only Twitter support announced on a landing page. Later, they added a pricing page. And so on.

The smaller the product the easiest it’s discoverable by the consumer. Less features leads to simple and effective marketing. Finally, Cesare suggested to "add nenuphar” before your product to increase the conversion rate. For example, a free RSS feed validator to make the customer discover the paying solution of your RSS-related product.

To sum up, the talk was mainly about lean startup and in our opinion the audience (mainly composed by developers) was already convinced about the topic. Those who need to be evangelised about a such approach are the decision makers who were not in the room.

Craftsmanship practices - not so basic

Many conferences were related to basic software craftsmanship practices. At least three of them were about core practices.

Hidden mysteries behind big mobile codebases, by Fernando Cejas

In this talk, Fernando puts the light on how to deal with big team maintaining a single codebase. SoundClound Android team has grown from 5 to 21 people in around 9 months. This led to find answers to some uprising questions related to such a team growth:

• can we add a new functionality fast?
• Is our codebase prepared to scale?
• Is it hard to maintain?
• What about technical debt?
• How to keep it healthy and safe?
• Is it easy to onboard new people?

Thus, they define a new way of working like putting in place some release train with a dedicated release captain. When the train is leaving, all ready features are shipped with it. The train is always leaving on time. Unready features are postponed to next release train. The release captain is changing every new release train.

Another role they put in place is the test sherif, in charge to avoid flaky tests (those automated tests that do not pass every time). This role is also changing every week.

Fernand puts emphasis on their practice of constant refactoring and boy scout rule. To handle the technical debt, they put in place a technical debt radar, showing each piece of code to refactor in perspective to their complexity and pain.

In our opinion, this talk did not show any new or magical trick to deal with large codebase but it gives a good reminder of the constant evolution of software, reminding the audience of software craftsmanship practices related to legacy code.

Getting clean keeping lean, by Joe Birch

Joe Birch works on the Android app for Buffer. When he arrived on the project the technical debt was important. There was no unit test, a lot of coupled concepts.

He mentioned the fact that in the beginning the knowledge of the big picture is easy but as the code base grows the onboarding is more complex.

On android when the logic is in activities/fragments it is really difficult to test, to maintain and there is a lot of code duplication.

For the 1st refactoring, they chose to move to MVP (Model-View-Presenter). It led to a first split between presentation layer and business logic but there was still no tests and the presentation was coupled with data sources.

During the 2nd refactoring they tried to implement a clean architecture inspired pattern. It offered a clear separation of concerns and it was framework agnostic. Then they could easily test all their business logic. Joe ended his talk by mentioning some cons: a clean archi could be overkill for some task, you need time to get used to, and the conversion of models between the different layers can be painful.

In our opinion, clean archi is not a goal. It is a way of building very maintainable applications when the code base becomes big. You may not need it for a simple application. A good approach when you design your architecture is to make it emerge and not to anticipate it too soon.

Test driving Swift to the max, by Phil Nash from JetBrains

Test Driven Development was clearly the centre of attention in this talk, showing the audience how to use Swift playground and Phil's open-source library to speed up the Red-Green-Refactor cycle. The swordfish library lets one developer to write tests in playground, adding a simple `required()` method in front of the expression he expects. It then gives a nice output in the emoji form showing if the required expression is fulfilled or not.

In practice this gives the following lines of code.

Even if Phil warns about his library maturity (`This is just a proof-of-concept - not recommended for serious work - and subject to change.`), this talk was interesting because of the reactions it aroused. The audience asked many questions, more on the pros & cons of TDD than on how it can be practically a tool for everyone in its own project.

Our analysis is that the mobile developers' community is quite far from software craftsmanship practices and that's a pity as those are very powerful tools to ensure good quality software. This type of talks, that may sound a bit basic to craftsmen developers as we are in OCTO, is very useful to pursue software craftsmanship evangelism.

Practical technical talks

Mixins over Inheritance, by Olivier Halligon

In this Swift based talk, Olivier Halligon used Sci-Fi universe to illustrate the limits of inheritance to describe behavior or property of objects. Then he came to a very nice feature of Swift 3: protocol extensions. Using it efficiently, he showed how this solves the issue of Sci-Fi characters representation. He has also highlighted that protocol extension is not a silver bullet and cannot solve all the problems. Finally, the speaker demonstrated how to use few protocol extensions to move from the stringy COCOA API when dequeuing cell in tableview and collection view to a very convenient and simple API. Check his new library https://github.com/AliSoftware/Reusable that contains all this abstraction code.

Smartphone security, by Jan-Felix Schmakeit and Daniel Zucker

Security might be underestimated by developers and product owners who prefer to focus their work on delivering features to end-users. But this is a very important part of application development as once a threat appears it is too late. After a good explanation of what is security in the software field by Jan-Felix Schmakeit, Daniel Zucker showed many Android sample codes related to security best practices. All the presented code was accompanied with clear and useful explanations on the kind of protections it gives to your application.

Library development, by Zan Markan

The motivation for developing librairies is mainly the ability to share code between apps easily. A thing Zan told us is that the developer experience in context of using a library is similar to a user experience. It means that the API should be cared for as we would care for a GUI for the end users. And as developers are lazy people we should keep that in mind when designing libraries API.

Few advices about designing an API:

• entry point: should be extensible (constructors, builders, factories)
• methods & models: be careful with naming, respect platform conventions
• rx: make it optional, not default style
• dsl: could be a good idea if the library deals with specific concepts
• errors should be nice

Make a sample with your lib, it facilitates the API design and when you release it you have a documentation out of the box for "free".

About tracking & analysis: use "dogfooding" to understand the usage or if there is a network call you could add a header to track it. Talk to your users, they are the best source of information.

When it comes to shipping it, use semantic versioning. To release the library choose between a public or private repository depending on the context.

Finally, the documentation: provide a quick start, if possible a sample app. Generate API doc with the language doc tools. Create a wiki pages for everything else. The tests suites could also be a good documentation if your library is open source.

Sharing code between web and native apps, by Sebastian Witalec

The baseline of this talk was "you know angular (2) now you know mobile"

Sebastian works for the company who created native script. He mentioned some statistics about website and mobile apps audience: a user spends 18x more time on a mobile app while there is twice more people on a website. The retention is better for a mobile app thanks to a richer experience but there is a larger audience on the web thanks to smaller friction. Then the debate is not the web versus the mobile but how the users decide to consume the service you provide.

Sebastian then introduced the angular support for web and mobile app development. Since angular (2) is platform agnostic you don't have to care about the final user interface primarily. You just have to develop the core and then address the device where your audience will be. The speaker reminded us that mobile ui and web ui are two different things and should be designed with different approaches. Technically, on the mobile part the markup is "binded" to native UI component with a 100% access to iOS (Javascript Core) and Android (V8) APIs thanks to Meta Generating Process (MGP). MGP is done at the build time and provides zero day support for every native library since it generates the bridges between native code and native script.

Sebastian ended his talk with a demo of a color picker which has two implementations (one for iOS and one for Android), some animations running on the GPU, a shared navigation router between web and mobile.

Our opinion about this technology is that it could be interesting for a Proof Of Concept but the lack of testing for instance (no example given) could be a real problem.

IoT related talks

Integrating Android ecosystem into all the connected (or potentially connected) devices of a house is a now an important concern of the Android developer team. It started with Google Cast which let developers the possibility to transform the user devices into a remote control. Now it continues with the area of the internet of things and notably with the recent Android Things framework introduced during the last Google I/O.

We attended three conferences related to connected devices. These where mostly introductions to the possibilities and limitations of internet of things. The conferences might be trivial for people used to work with IoT devices but these problematics are quite new for us, mobile developer, who are accustomed to work on a "consistent" smartphone ecosystem.

Things to remember when you build your robot army, by Nir Dobovizki

This talk was a general presentation of some DOs and DONTs to keep in mind when we design IoT experiences. The advices were illustrated of pictures extracted from the quite funny twitter account @internetofshit.

Here are the four main points we retain from this conference:

• Design for battery failure. We should keep in mind that devices, even if they are connected to the grid power, can be disconnected at any time. For instance, how a connected lock should behave when there is no power? Keep the door opened or closed?
• Design for intermittent internet connection. You can never be sure that your device will have a full time internet connection, even if the device is wired. You must make sure that the device is prepared to such intermittent connectivity and that it will not damage your user experience.
• Handle software updates gracefully. Firmware and software update, even if they are particularly important, should happen at the appropriate moment or it may lead to user frustration.
• Security should be a major concern for you. IoT is particularly appropriate for use case where insuring privacy is crucial: in house camera, sensors or other objects collecting private data. Therefore, you have to make sure that you treat security questions very seriously.

Make your app for TV by integrating with New Google Cast SDK by Sonia Sharma

This talk was a presentation of the new way of integrating the Google Cast SDK thanks to its version 3, released in last June.

The speaker started with a sum up of what is Google Cast (a *communication protocol*) and the role played by the different devices (the smartphone is the remote, the Chromecast/Google Home is the receiver which will play the media)

The takeaways of this conference are the followings:

• Adding Google Cast integration to your app is quite easy if the media you want to play on the TV is "simple" i.e. a pure media stream with no DRM
• All the Google Cast UI assets (casting icon, notification & tutorial) are provided by the the Google Cast SDK
• There are three levels of customization of the receiver app (displayed on TV)
• No customization: the interface is the one used by default.
• Style customization: a css is provided to theme the receiver app
• Full customization: it is possible to give a full webpage to have a more advanced receiver app customization.

Our opinion concerning this presentation is that it shown well how easy it is to integrate this SDK. Meanwhile the usecases remain too narrow: casting an app on a TV makes sense for a small spectrum of the application we are used to develop.

It’s About Time (Closing keynote), by Daniel Steinberg

This talk was by far the best although the more complicated to summarize. At first, Daniel Steinberg used simple square representation to model all our to-do tasks during a week. He also used family pictures of his own to give the audience what was at the beginning some smiles and laughs. But as the talk advanced, the story of Daniel's daughter and wife started to get deeply emotional. Daniel's message was clear and simple: live the moment so you can avoid later regrets. This was by far the wisest advice offered to the audience get during the whole conference.