This article was written before Drivy was acquired by Getaround,
and became Getaround EU. Some references to Drivy may therefore remain in the post
Android Makers is the largest Android event in France, organized by the PAUYG and BeMyApp. This year the event was held in Le Beffroi de Montrouge - what a great place to enjoy a conference. There was much more space than the previous Android Makers event: we were really comfortable, with all we needed to be fully focussed on the conferences.
Below are some key takeaways of these 2 days of great conferences.
They gave us a big overview of the improvements of the last few years to Core Android development, from the view (ConstraintLayout) to the programming language (Kotlin) through the architecture, the tools and more.
Don’t use AbsoluteLayout, GridLayout and RelativeLayout any more. The best performances are provided by LinearLayout, FrameLayout and ConstraintLayout
Use SurfaceView not TextureView
Handling life cycle should be much more simple than previously, with the help of Architecture Component
Architecture components are not necessarily the way you must build your app, it’s a recommended way, but you must build what matches your need
Google recommends the libraries such as Glide, Picasso and Lottie, and they will never build equivalent tools in android SDK as they are already really good
Use systrace instead of traceview to profile your code, and the Android Profiler which containts a nice view including the touch events at the top (purple dot, the long dot are swipe event)
Remember that devices are resource-constrained, you must pay attention to, take care with the resources you use because there is a direct link to your user’s battery life
Travelling across Asia - Our journey from Java to Kotlin
A talk about their switch from Java to Kotlin at Deliveroo
Key takeaways:
Start small, like the test or the data class, and then increase slightly the amount of Kotlin code in your project. Everyone in your team must be confident about using it, and not feel the need to rush.
Use comments on PRs, to learn the language from concrete examples in your own code base - it’s always better than a HelloWorld example
Android Studio is your friend: it offers you alternatives to improve your kotlin code
You can use Android studio converter, but it doesn’t always convert with the optimum results.
At Deliveroo they schedule a weekly meeting called Kotlin Hour where all the developers share what they have learned on Kotlin.
I learned the existence of the Koltin Island (An island in Russia) far far away from the Java Island
Better asynchronous programming with Kotlin Coroutines
Good starting points if you have never used Coroutine, Erik told us about coroutines, and how we can use them to end up with simple code looking like the excerpt below for async calls:
Key takeaways:
Channel: basically a queue, it’s a way of passing multiple values to a coroutine
The coroutine doesn’t replace RxJava they can work together
During his talk Taylor answered a really good question What should a developer expect from a designer?
He divides his answer into 5 different parts:
Visual Design
Always design on Small Screen (recommended size 640x360, Nexus 5) because this is where you have all the constraints
Use consistent design across all of your app
Design Assets
Proper size, proper format assets (SVG, PNG, JPG), and optimized assets to avoid increasing your apk size. New App Bundle will also help a lot for this point)
Design Specification
To avoid wasting both your designer’s and developer’s time, use tools like Zeplin to easily communicate the complete design specification (The new Gallery tools would be a good alternative)
Interaction Design
Provided not only screen but also screen flow diagram
Animation should be defined with high quality video and even animation specification (delay, scale, duration etc…) and a timeline
Define the right interpolator depending on the animation purpose (FastOutSlowIn, LinearOutSlow`, etc… )
Animation Design
Today Lottie and After effect are the best ways to easily add complex animation to add to a mobile application
For simple icon transition you could also use Shape Shifter
He turned the question the other way around What should a designer expect from a developper
Communication, ensure we all speak the same language (dp, sp, FAB, Snackar, etc…)
Explain to them what the constraints are, what could be implemented, and what could be not, and moreover suggest alternative solutions
Overall a really great overview of theme, style, text appereance and more. He explained how you should write them and organize them in your project. If you don’t feel confident with this part of the Android sdk, I definitely recommend that you watch this presentation.
Key takeaways:
How to properly handle themes regarding API version, to avoid re-writing them for every version in addition to the new attributes for each new version
Stan gave us his feedback on how they manage remote configuration of their Dashlane app, without need of a new release on the store. He told us about five main concepts:
Web View: Load web content in your app
Pros: It allows you to update the entire screen
Cons: Bad user experience. This is ok for small parts of your app like the help center
Remote Screen config: Send screen content with json (text, icon)
Pros: Good user experience
Cons: Limited possibility for updating the layout
Remote Copy: Change the strings.xml by a remotely downloaded json file to easily update the wording with a Custom Layout inflator to manage string in .xml file
Pros: Fast wording updates in your app
Cons: Hard to manage multi-language, plurals and text formating
A/B test: Compare two experiences to choose the best
Comparing local and server-side A/B test
Server-side is more appropriate for remotely updating the A/B tests
Feature Flip: Remotely enable or disable features in your app
At Dashlane they distinguish between App Release and Feature Release. They release their app every 2 weeks, no matter the state of the feature, and then enable the feature when it’s ready
Good question from the audience, you can no longer use the new release note feature from the Playstore with this workflow
As I’m not a fan of “Magic programming”, it’s always interesting to understand how the tools you use work. This presentation about ADB was an in-depth understanding of how ADB works under the hood.
Key takeaways:
ADB is split in 3 parts:
adb client (adb command)
adb server (Multiplexer)
adb deamon (Phone)
Android Studio does not use abd but ddmlib(a jar that provides APIs for talking with Dalvik VM, both on Android phones and emulators)
I learned about the existence of the Google Sooner first ever Android phone, which has never been shown to the public.
Typesetting: desiging and building beautiful text layout
Big overview of all the Typesetting you can include in your app
Key takeaways:
Android P will add baseline param in TextView
android:firstBaselineToTopHeight: Distance from the top of the TextView to the first text baseline. If set, this overrides the value set for paddingTop.
android:lastBaselineToBottomHeight: Distance from the bottom of the TextView to the last text baseline. If set, this overrides the value set for paddingBottom.
I learnt about the existence of the android:breakStrategy param: Break strategy (control over paragraph layout).
If you have a long piece of text don’t use a single TextView but use a subset of paragraph that you must put in a recyclerView, doing it this way will give you all the benefits of the RecyclerView when you scroll.
Gradle in Android Studio 3.2 3.3 and beyond
Bradley Smith & Lucas Smaira, Google
This was a good overview of how Gradle and Android Studio work together. They highlighted the pain points and explained to us why it’s slow sometimes.
Key takeaways (new upcoming features):
Single Variant Sync (Sync only the selected variant, should be available in AS 3.3-canary)
PSD (Project structure Dialog) new graphical interface with nice suggestions, dependency graphs and more to help you manage your gradle file
He gave us a big overview of how the Android team work at Uber, and the tools and architectures they use.
Key takeaways:
The Uber app is based on a MonoRepository mainly to avoid dependency issues Full article
They introduced a system called Submit Queue which rebases changes on master and runs a customizable set of tests before merging them to avoid broken master
They use Buck and the Exopackage: from Ty word It's like instantApp but it's works :)
They have built a demo application with all the design components available, to keep a consistent design across the app
It’s quite impressive to see how many open-source libraries Uber have shared with the Android community:
OkBuck: OkBuck is a gradle plugin that lets developers utilize the Buck build system on a gradle project.
RIBs: Uber’s cross-platform mobile architecture framework.
Crumb: An annotation processor for breadcrumbing metadata across compilation boundaries.
AutoDispose: Automatic binding+disposal of RxJava 2 streams.
Artist: An artist creates views. Artist is a Gradle plugin that codegens a base set of Android Views.
NullAway: A tool to help eliminate NullPointerExceptions (NPEs) in your Java code with low build-time overhead
RAVE: A data model validation framework that uses java annotation processing.
Conclusion
This year Android Makers regroups 816 people, including 82 speakers and it was organized by 34 organizers. Thanks to them and all the sponsors who make this event possible! We will definitely come back next year. You can already buy your ticket for Android Makers 2019!
As always, it’s good to meet the android community and learn from other developers. This year the event became more international - I only saw one talk in French, all the other talks were in English. It was great to see that we have a conference in France that is attractive for the Android community!
See you next year!
Did you enjoy this post? Join Getaround's engineering team!