Droidcon is a series of conferences, focused on software development for Google’s Android smartphone framework. It all started in 2009 as a small movement of Android developers in Berlin. We believe that true power lies in fundamentals so we decided to visit the precursor of all Droidcons – Droidcon Berlin.
There were four stages full of awesome speakers and only three of us. We tried to remember as much as it is possible and we would like to share with you a short recap from our favourite sessions.
Refactoring Plaid App – A reactive MVP approach
by Hannes Dorfmann
As a fan of architectual patterns I was really excited about this session. Hannes Dorfmann is an awesome software engineer with deep knowledge of modern Android platform. He is also a creator of Model-View-Presenter library called Mosby.
In my opinion he was one of the strongest speaker of all conference. With confidence on the stage Hannas describes step by step process of refactoring well know Nick Butcher’s Plaid App using MVP approach. To hide the database he uses repository pattern with RxJava on top. I was really amazed how his point of view is similar to mine. During the talk I had this feeling that he is the guy I want to work with.
To sum up I am really happy that I had the opportunity to attend this session. Hannas confirmed my belief that I am in the right state of mind. If you feel lost in your app and you do not know what to do please check Hannas blog and twitter. I am more than sure that you will find there some useful ideas and inspirations.
More to read and watch:
Pushing the boundaries of the layout system and typography
by Thorben Primke and Lin Wang
One of the most interesting sessions during this Droidcon was design focused talk by Thorben Primke and Lin Wang, both representing Pinterest. The title of the talk was “Pushing The Boundaries Of The Layout System And Typography”. And the fact that this talk made so big impression on me is a little bit surprising, because I am usually much more into stuff like architecture, code quality, testing etc, and here are two guys talking about UX and UI.
So what was so good about it? In short, the amount of thought and work that went into the system Pinterest created.
They came up with a design system, called Brio, that basically lets you design for all the platforms, Android, iOS, you name it, at once. It works like this: all devices are divided into predefined groups based on their sizes. For each group, there is a dedicated layout grid, on which the designer does his (or hers) magic. And one might think, that the bigger the device the more cells in the grid, right? Wrong. I mean not always, because this grid is made up of very clever units of measurement called Brio points that are device size independent. So, while on a small device one Brio point might be 3dp x 3dp, on a bigger device it might be 6dp x 5dp. And that is what makes this system so awesome – the designer doesn’t care about screen sizes. All he (or she) needs to do his (or hers) job is a list with all supported grids. How cool is that?
That is all good and convenient for a designer, but one might ask what happens next when a programmer gets the design and all sizes, margins and paddings are in those strange, unfamiliar units? That is where the real fun begins. The talk covered some of the challenges guys at Pinterest faced while trying to translate their Brio points to units Android system could understand. They tried custom attributes in attrs.xml with custom attribute extraction. And it worked but it was not perfect, so they decided to do in programmatically. First, they tried Java but the amount of boilerplate that they had to generate to make it work was insufferable. Finally, along came Kotlin <3 and Anko library that lets you create UI programmatically using DSL. It is clean and easy to read, and since there is no XML parsing – faster than XML. I am not going to dive deep into how it works and how guys from Pinterest implemented their solution. If you want to learn more, check the links below.
As I mentioned before, the most impressive aspect of this talk, at least for me, was that they didn’t take the easy way. They could just design for all platforms and screen sizes separately and then let programmers implement it in a standard way, like most of other companies do. But they wanted to make the process easy and they wanted to make their apps to look exactly the same on every platform. And they wanted their designs and layouts pixel perfect. And apparently they made it work.
More to read and listen to:
Ten ways to analyse runtime failures with Classyshark
by Boris Farber
ClassyShark is an open source tool developed by Google. Creator and main contributor is Boris Farber, Developer Advocate at Google, focusing on multidex and performance of data intensive apps. The tool is dedicated mainly for big apps with lots of code and many dependencies, because in this kind of apps sometimes very strange things happens when used by end users. These problems are even harder due to the fact, that they are not visible in source code in IDE, and therefore can’t be easily fixed.
Some common examples are: long launch time, APK crashes in release build, but not in debug, large APK with multiply classex.dex files, problems with native code
Here with help comes ClassyShark, a tool where we can explore APK, look at classes, methods and signatures along with lots of useful information about APK: per package or per class method counts, number of classes.dex files and it’s content, etc. One of the biggest advantages of this tool is performance. APK is loaded very fast and incremental search works just like in IDE. When exploring our APK we see that our own code occupies only small portion of the entire file, this indicates that we should use Proguard or some other obfuscation tool to remove redundant stuff that is not needed in our app. It is worth mentioning that ClassyShark sees exactly the same methods number as runtime does.
Apart from exploring our file, we can do some pretty cool things with help of this tool:
– easy check, if Proguard was used: if package, class and method names are readable, obfuscation was not used
– find dependency which should not be included in our up, but somehow it is (ex. transitive dependency)
– see native method count, libraries and dependencies
ClassyShark also has command line interface. We can utilize this feature in our build servers. For example, we can fail build if some package or app exceeds our own method count limit, or some „bad” library will be included in our app. Due to gradle support, we can have all ClassyShark functionality in our app during runtime.
ClassyShark supports following file formats: .apk, .dex, .class, .jar, .aar, android binary
XML’s, resources in binary format.
All in all, ClassyShark can be extremely useful tool in figuring out the problem which occures only in the production environment. It has a bunch of cool features and can be used on our development machine, build servers as well as during normal execution of an analyzed application.
More to read and listen to:
Thanks for reading!
Piotr Ślesarew, Piotr Szypuła, Mateusz Dybaś