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.
The speaker praised the smallness. In three aspects.
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.
Many conferences were related to basic software craftsmanship practices. At least three of them were about core practices.
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:
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.
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 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.
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.
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.
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:
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.
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.
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.
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:
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:
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.
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.