App Builders 2017
Seven mighty mobile developers from Elements Barcelona and Elements Almere flew to Lausanne, Switzerland to attend the App Builders 2017 conference held on April 24th and 25th. Read below what four of them thought of the talks, the city and the event in general.
Roberto
As you may be aware, Elements ❤️ Mobile Apps, and so our Android/iOS teams seized the great opportunity of attending the App Builders 2017 conference in Lausanne. A good chance to dive into new initiatives, platforms and topics that are trending in the mobile development industry, by some of the people who actively take part in shaping app development and contribute to this growing community.
In regards to the iOS/Swift world, some exciting things have been cooking since December 2015, when the Swift language was made open source, and Swift apps could now run on Linux. It did not take long for new platforms and initiatives to start kicking off. Two interesting uses for the shiny new open source language were the main subject in some of the conferences. Particularly “server-side Swift” by Jens Ravens and “Swift scripting in practice” by John Sundell, caught my attention.
In Server side Swift, Ravens dives into the advantages of writing Swift for the server, and goes over different solutions such as Kitura (IBM), Vapor, Perfect, arguing server-side Swift is pretty fast, and provides us with the benchmarks to prove it (comparison made against Node.js).
Ravens also talks a bit about MVC-RS. As iOS developers, we’re all too familiar with the MVC (Model View Controller) design pattern. It works OK for the most part, but once we start considering that we may have some server-side Swift for an app, we may also start thinking about code reusability across our server code and our app code. Considering this, the main issue with “vanilla” MVC is that we would usually build models in such a way that they directly handle the persistence layer. And different platforms (such as iOS and the Linux Server side) most likely use different persistence mechanisms. MVC-RS stands for Model View Controller — Router Storage, and tries to address this issue by abstracting the Persistence layer into Storage (S) components, and creating the role of a Router, as a coordinator/dispatcher entity. Imagine being able to code a full-stack Mobile Application fro the ground up, using a single language, and being able to reuse an important portion of your code on the backend and the client, such as your Models.
And on the subject of reusability, since we already have Swift for Linux and Mac OS, why not also do our scripting in Swift, right?. This was the main point of John Sundell’s “Swift scripting in practice” talk.
Sundell makes the point that a good argument for scripting in Swift could definitely be to the advantages that can come from sharing code between your scripts and your apps. Sometimes we need to run some sort of script to make pain-free some very painful typical and repetitive manual tasks. So what if now we can also make use of some of our app’s source in our scripts? it could simplify some tasks related to script maintenance. For instance let’s say we are building a game with different types of characters (heroes, villains, soldiers, …), which may be defined in our App as an enum for each type (called CharacterType).
Let’s also assume we have a script that adjusts some assets that correspond to our types of characters. Normally we would have to manually maintain both the app and the script whenever we would add a new type of character to our game, so that our script won’t break, but what if we could directly use our app’s CharacterType enum in the script?. It would mean that only need to change our app’s code, and the script would automatically work, because there’s only a single point of truth.
The main drawback Sundell also pointed out using Swift for scripting, is that the setup of a Swift script can be pretty cumbersome and it’s not as straightforward as, for instance, running a bash script. The bright side is he also introduced a tool to simplify creating a new Swift script from scratch: Marathon. In a nutshell, It allows for quickly creating and running a Swift script from scratch, and we thought it was a cool tool to check out.
With Swift being open-source we can’t wait to see what other tools and uses the community will come up with, and we’ll surely keep an eye out for anything new coming our way.
Oleksandr
Benedikt Terhechte spoke about a good practices of using protocols with associated types (which could be considered as a generic protocol). The subtitle of his talk was: “When to use and how to avoid their pitfalls” and he talked about the most important basics and shared some advanced examples. The full video of Benedikt’s talk can be found on YouTube.
There are two ways to introduce associated types: direct and indirect.
protocol ExampleProtocol {
// direct
associatedtype SomeType
var prop1: SomeType { get }
// indirect
var prop2: Self { get }
}There are two ways to adopt the protocol: explicitly and implicitly.
protocol ExampleProtocol {
associatedtype SomeType
func foo(arg: SomeType)
}
struct ExampleStruct1: ExampleProtocol {
typealias SomeType = Int
func foo(arg: SomeType) {}
}
struct ExampleStruct2: ExampleProtocol {
func foo(arg: Int) {}
}It’s important to keep in mind that associated types are undefined in the protocol and this fact makes the protocol an unfinished type.
protocol ExampleProtocol1 {}
protocol ExampleProtocol2 {
associatedtype T1
}
struct ExampleStruct {
var prop1: ExampleProtocol1
var prop2: ExampleProtocol2 // Compiler error
}There is a good trick of constraining types by the compiler.
protocol ActionType {}
struct ActionElectric: ActionType {}
struct ActionWater: ActionType {}
protocol Collectible {
associatedtype Action: ActionType
func act<Other: Collectible>(on other: Other)
where Other.Action == Self.Action
}
struct Pikachu: Collectible {
typealias Action = ActionElectric
func act<Other: Collectible>(on other: Other) {}
}
struct Raichu: Collectible {
typealias Action = ActionElectric
func act<Other: Collectible>(on other: Other) {}
}
struct Wartortle: Collectible {
typealias Action = ActionWater
func act<Other: Collectible>(on other: Other) {}
}
func arena() {
// Now only electric can fight against electric
let pikachu = Pikachu()
let raichu = Raichu()
let wartortle = Wartortle()
pikachu.act(on: raichu)
pikachu.act(on: tortle)
}There is a good example of validator implementation by using protocols.
protocol Validator {
associatedtype I
init()
func validate(_ input: I) -> Bool
}
struct EmailValidator: Validator {
func validate(_ input: String) -> Bool {
return input.characters.contains("@")
}
}
struct NameValidator: Validator {
func validate(_ input: String) -> Bool {
return !input.isEmpty
}
}
struct Value<V: Validator> {
private let value: V.I
private let validator: V
init(_ value: V.I) {
self.value = value
self.validator = V.init()
}
var validated: Bool {
return validator.validate(value)
}
}
func example() {
let email = Value<EmailValidator>("me@appventure.me")
let name = Value<NameValidator>("Benedikt")
let isValid = email.validated && name.validated
}Jeffrey
Our App Builders adventure started on Sunday the 23rd of April. Due to capacity constraints we had to be at the airport 3 hours in advance. After waiting we could finally take off, so we hoped. However, one passenger didn’t show up so his/her baggage had to be offloaded. Taxiing took about 20 minutes and we could finally start our flight. When we almost arrived near Geneva we could see the beautiful Alps and Mont Blanc. Next we took a small train trip and a short walk up the hill to get to the Novotel hotel.
The first day of the conference started with Felix Krause, the creator of fast lane and his experience with scaling open source projects. By introducing a GitHub bot a lot of tasks were automated to improve the complete process. Next was not a presentation at all but a new set-up in which a hoster asked questions (Q&A) to someone from the field. In this case the expert was Martin Odersky, talking about the future of functional programming. As one of the creators of Scala and contributor to the Java language he has a lot of experiences in working on languages and explains that the main challenge is working with people: Programmers tend to over-complicate things. Marcos Placona from Twillio started off blind-folded and showed us how you can easily extract API keys from an Android application. After his act he showed us how we can protect and improve security in Android applications. Cesar Valiente used Kotlin to demonstrate a Redux way of architecting Android applications. Elif Boncuk gave us a crash course on the amazing ConstraintLayout, which improves performance of layouts in general by having a flat hierarchy.
The second day started off with Laurent Bugnion giving an overview of the Xamarin programming platform. C# looks very similar to Java and has many of the same features, such as lambdas and co-routines. The interesting thing Xamarin is that you could potentially reach a shared code base of 60 to 70 per cent. Etienne Studer, from the Gradle team, gave us insights in the upcoming features of the Gradle system. The new features will greatly improve the build system in general. Rebecca Franks’ presentation was an in-depth overview of what you can do with Android Things as an IoT platform. It is still good old Android code to be able to interact with IoT devices. Another interesting talk was from members of a team of the SBB mobile application. SBB is the Swiss Federal System and is the most used application in the country. The Android team showed us their MVP-like architecture and how they can efficiently unit test with their approach. The App Builders conference brought us a lot of insights into the currently used technologies and what is yet to come. Switzerland has been an amazing experience with many beautiful views.
Raquel
App Builders was more than just a mobile event, for me it was also a reunion with my dear Dutch colleagues; so we spent two nice days in the beautiful (but expensive) Switzerland and we even learned a thing or two. We got the chance to listen to amazing people speak about their passions and share their knowledge with us, we attended talks about machine learning from a CERN particle physicist, heard conversations about privacy, listened to technical talks (iOS and Android), rediscovered Xamarin to build cross-platform applications… and all of that in just two days including some food and a nice after party!
Since I can’t write about every talk I found interesting during the App Builders event because I also need to work, meaning having fun coding from time to time, I’ve chosen a talk to get into more detail.
The topic I would like to extend is the Android Things presentation Rebecca Franks gave on the second day of the event; she’s an Android enthusiastic and her speech was really easy to follow. What I find really compelling about Android Things is that using this platform I get to enter into the exciting world of the “Internet of Things”, without a painful transition since it’s an extension of the Android platform (which as an Android developer I already know) for IoT embedded devices. It’s ideal for powerful, intelligent devices that need to be secure.
As they claim: “If you can build an app, you can build a device”, so the challenge is feasible and you get engaged quickly. And their claim is true, one of the advantages of working with Android Things SDK is that you can still use the tools you’re used to, like Android Studio, Firebase libraries, … so at the end is like your daily basis work, changing a bit the environment; but you still have the whole Google world behind it, and we all know, with Google we all live happier (don’t say this in front of the speaker who talked about privacy… discussions can ignite quite rapidly).
Let’s get our hands into it, what we first need is a development board, there are many options like the Raspberry Pi3 or the Intel Edison (https://developer.android.com/things/hardware/developer-kits.html); these boards may already integrate some of the components that we can need and it allows you to start development. It’s important to keep in mind that despite the similarities with the mobile apps we implement, in this case displays are completely optional so alternative UI should be considered, for instance, a voice based navigation or any peripheral to help you achieve what you want.
Android Things just landed so, clearly, there are still some edges that need to be sharpen but I think all it needs is time and a maturation process.
Some of the known cons are:
- Only available in developer preview.
- There are some known issues like hardware graphics acceleration being off
- Weave not yet available for this platform
- Documentation / samples are poor due to its short life
- A bit slow for things that need precise timing
- Not open source yet…
After all these first insights of the platform, our speaker, Rebecca, moved on to present a simple example. She used the Raspberry Pi3 with some basic electronic components, like a breadboard, jumper wires, a LED, resistors and a push switch to build an easy device that turn on a LED by simply pushing the button. While introducing us about these electronic components she also spoke about the Raspberry Pi Rainbow HAT and walk us through some basic electronic knowledge like the Ohm’s law or the pinout diagrams. After seeing some code we were able to see Android Things in action, from this basic demo and some other implementation examples you can already play a bit with all that is offered, like using Firebase realtime database or send push notifications… the options are infinite.
My conclusion would be… shall we? We have this immense playground right in front of us so why don’t we play a bit in it?
Looking forward to the next App Builders event!!!
Originally published at www.elements.nl on May 11, 2017.
