DroidconNL Amsterdam 24-25 November 2014
The first talk was from Raimon Rafols and was the same talk he gave at Droidcon London a few weeks ago. He gave a performance analysis comparing Dalvik and ART. Basically ART is faster at everything, but they both start with the same output of the javac compiler. javac is not optimized, so anything you can do to improve you code will help. Most of what he said was obvious, such as using StringBuilder instead of string concatenation, and using for loops with pre-calculated end instead of foreach loops.
Second talk was from Daniele Bonaldo about how to build Android from source. This is not very relevant for me, but it’s nice to know what to expect.
I also caught the end of Joan Puig Sanz’s talk about building native C++ apps. Didn’t look too difficult if that’s what you want, but you need to use Eclipse and not Android Studio (for now), and you might want to consider building a separate apk for each platform (MIPS, ARM, X86, 64-bit) otherwise you get one big apk with all the runtimes in it.
Third talk was from Alexey Kuznetsov of Booking.com about dynamic code and resource loading in order to speed up the development cycle. The problem is that when you make a small change to the code then you need to build and package the entire app and deploy to the device. By his estimate this takes about 1½ minutes. With a few tricks with the AssetManager and ClassLoader he was able to reduce this to 25 seconds. The minute that you save helps you keep focus.
Fourth talk was from securify.nl. They specialize in penetration testing of mobile and web apps, as well as teaching “security by design”. The talk was mostly about the findings of an investigation they did that showed that a large number of Dutch apps implemented a custom SSL TrustManager with flaws that allowed a man-in-the middle attack. But if you use the standard Java or Apache implementations then you shouldn’t have that problem.
Talk five was by Paul Lammertsma about building a Chromecast app. He went through the process of connecting the sender app (Android, or anything else) and the receiver app (single-page html).
Last up for the first day was a quiz about some of the less-known edge-case pitfalls of the Android architecture and lifecycle.
The second talk of day two was about ANT+ and Bluetooth LE protocols that are used for fitness devices. Pretty in-depth about the protocols, but it demystified them a bit.
The third talk was about AAR, the Android library archive format, which was a bit more relevant for day-to-day development. Until recently it was difficult to include libraries in your project, mainly because of the problem of combining resources and assets, but AAR solves this and it’s now easy to create or use an AAR project using Maven, Gradle and Android Studio.
Talk four by Ostap Andrusiv was about extending your app to wearables. He started by describing the scope of wearables - glasses, watches and bands - and talking about his belief that they would become more mainstream once they became more fashionably attractive. Sony was first with the SmartWatch, and then Android expanded on the idea with Wear and will probably supercede it. He described the structure for a project shared with SmartWatch and Wear, with the Model, Controller (Presenter) and the interface for the View in a library project, and the implementation of the Views in the platform-specific projects.
After lunch were Weibe Elsinga and Ali Derbane talking about the frameworks for functional testing. Nothing new for me, although it seems like Espresso is quickly rising to the dominant position. Calabash is holding a good second place because of the natural language test specifications. Also described were Robotium, Selendroid and Robolectric. Forgotten but promised for the next version of this talk was Appium. Google was very slow to provide a decent testing framework, but they just recently started promoting Espresso after incubating it for a while.
The sixth talk was a very in-depth talk by Sebastiano Poggi about the Canvas API. This is the base for all Android UI but it’s badly documented. Canvas is a wrapper for Skia, the native 2D rendering framework that’s also shared with Chrome. Since Honeycomb some parts of Canvas can be implemented in the hardware layer, but check the table for unimplemented features for each Android version. Useful to know is that Canvas is stateful and the same canvas gets passed around whenever you need one, which can make your life easier, for example by drawing something in an off-screen canvas and applying it to the current canvas.
Last talk of the day and the conference was about hacking and botnets.
For a quick visual summary of most of the talks I went to, and a few I didn’t, I highly recommend: