In the post about my first day at the Dutch BABBQ, I have spent quite some good words for the speakers who really deserved them, but I have been also quite harsh in expressing my little disappointment about the location and the overall organization. Let’s be clear about that: there was nothing very bad about the organization, at the end it was good what they have accomplished , but it was just of a lower level compared with the standards set from other android events in Europe (droidcons and GDG dev fests).
Anyway, my impression about day 2 are very different. The level of the talks today have been all very high, and all the speakers rocked on the stage. Maybe because of this, all the little disappointments about the organization passed unobserved during this second day 🙂
The talks
10 ways to improve your Android app performance
by Boris Farber, developer advocate at Google
The first talk of the day was great! A Google developer advocate gave us for free his lessons learned on the field while helping companies to succeed with the android development.
Here is the list of the top 10 topics that he covered:
- Activity leaks
In short activity leaks are references held to unused activities.
For example registering an activity as a listener and not removing it in the onDestroy() method can cause an activity leak. - Activity leaks
"Because once is not enough."Another bad example of activity leak is a post delayed handler. For example, if the activity is closed before that the code in the handler is executed, then an activity leak occurs!
THE FIX:MyHandler(MainActivity activity) { mActivity = new WeakReference(activity) }In this way the GC can clean the reference.
TIPS to avoid activity leaks:
- remove static references,
- use instead event buses,
- use tools like MAT
- Use UI thread only for UI
Things not to do on ui thread:- images loading and caching,
- networking
- json parsing
- database access
How to do it? See point 4.
- Use librarise
For image loading use Glide, Picasso or Fresco."Don't do by yourself unless you have some really good reason to do that. Memory and bitmaps are tricky, use LRUCache which is optimized for image storing and is part of the support library!"For networking, don’t use java.net APIs because they are blocking, use instead OkHttp, Volley or Retrofit which are made primarily to handle networking problems related to mobile devices (things that were not taken into account in the standard java libraries).
- Large JSONs
Test the size of your json, measure with timestamps the time taken to parse them and use one of the following libraries:- GSON, if you are dealing with small json,
- Jackson or ig-json-parser, otherwise.
- Concurrency API
Service methods run on UI thread, so consider using IntentService AsyncTask, Executors, Loopers and Handlers (see the slides at the end to understands the APIs and tradeoffs) - System abuse
- Don’t call private APIs by reflection
- Don’t use Runtime.exec
- Don’t call private native methods(NDK/C level)
- Deprecation
"API will be removed and your app will not work in a shiny day close to release!"Compelling reasons to move away from deprecated method:
- security
- correctness
- performance
TIPS: refactor your dependencies!
- Bring your own gloves
There are various versions, devices, OEMs and users: some APIs may behave differently. Consider bundling your own version of the lib, for example in the case of security libraries, so that your app works as expected also on rooted devices. - Architecture
"Most of the bugs are caused by misunderstanding the architecture and the APIs like activities, fragments, and tasks"TIPS: add logs on callbacks, make the architecture consistent so that it is easy to understand for new people who join the team, and have someone experienced in your team!
But this was not all from Boris, I was literally astonished when he presented his open-sourced project made to help us to identify problems like the ones mentioned above: Classy Shark
This tool was written after solving by hand circa 80-90 runtime cases:
"innovation comes from frustration".
The SLIDES of this talk are available on Boris’s website: www.api-solutions.com.
Interfacing with Sensors
by Michael Schloh von Bennewitz
Michael is a computer scientist and expert on network software engineering. His talk was a short version of the one available on youtube which you should not miss if you are passionate about IoT.
In addition to the good quality of the contents, the talks was quite entertaining. He handed-over to the audience a few beacons (like the one that I have in the picture below)
while he was explaining how they work and how it is possible to interface with them.
Then he did a very interesting comparison and live demo of the most popular development boards out there and of various sensors, like the thermo sensor which he is using in the picture below to measure his body temperature 🙂
During this talk for the first time I also heard about BAN: Body Area Networks and the crazy thing about them is that there is a IEEE standard to regulate them!
Every application should be secure
by Dmitry Dain, Virgil Security
Applied cryptography is hard:
"How many developer are able also to do security out there?"
There is not a single hard step, it is a combination of 100s of things all working perfectly that presents a challenge"
Did you heard about this https://en.wikipedia.org/wiki/Sony_Pictures_Entertainment_hack and this http://www.nytimes.com/2015/07/10/us/office-of-personnel-management-hackers-got-data-of-millions.html ?
There are plenties of cases like those above. SSL fails to scale. “It was developed to connect, but not to secure data that nowadays we are sending to the cloud.”
Virgil Security wants and can prevent those hacks to happen. Their work is based on the values listed in this slide:
Everybody have trouble to remember password.
Virgil guides software developers into the forthcoming security world in which everything will be encrypted (and passwords will be eliminated).
Ok, but what is Virgil?
Virgil is a stack of security libraries (ECIES with Crypto Agility wrapped in Virgil Cryptogram) and all the necessary infrastructure to enable seamless, end-to-end encryption for any application, platform or device.
There are only 4 functions to know in order to use Virgil’s stack, sign, encrypt, decrypt and verify. We don’t have to care about passwords, seeds, and any other type of parameters needed to configure an encryption protocol.
For example,the only parameters needed to encrypt are: what (the message), and the who (the receiver of the message, specified by his public key).
Another important feature to mention about this lib is that it scales across regulatory domains thanks to what is called “crypto agility”. All this is transparent to the user.
Finally, Virgil removes the need of SSL certificates. There is no need to use a third party entity to certify someone trustability. Virgil holds a repository of public keys easily accessible via rest API.
What if this repo of public keys is hacked?
Well, our app security will still be preserved because each public key is valid only when signed by the private key of the real owner. So the communication between two entities will not work.
Event Buses: The @channel of Android Architecture
by Bill Phillips, Big Nerd Ranch
“Organizations which design system…are constrained to produce designs which are copies of the communication structures of these organizations” – Melvin Conway
During this talk Bill helped us to reflect on the problems caused by using event buses.
How problem arise with event bus?
Event bus helps to create high-oriented spaghetti code. It is really appealing to solve a communication problem by broadcasting a message to anybody. The control flow of a clearly defined single-responsibility is completely messed up. Consider also that the event fired may fire more events and so on. In this way there is no architecture anymore in the code.
A goto has the same problem of event bus: it breaks the design to solve a problem.
Posting an event to accomplish something very much violate a boundary in the code.
Bill didn’t explicitly said to not use event buses, because they can still be useful to propagate and handle error cases in the whole app, however it was clear that he was not a fun of event buses.
“Only break into someone else’s context if it is your legitimate responsibility to do so”.
His talks definitely helps to re-think on our architectures, but honestly I was expecting from him a clear alternative to event bus.
Wear’s the Party!
by Paul Lammertsma, CTO & co-founder of Pixplicity, Dutch Android User Group co-organizer.
I really liked this talks because it gave all the info necessary to start developing for android wear. Specs, features, possibilities, APIs, code samples and tips, all packed in this presentation.
This talk was pretty much similar to the one that Paul gave to the mdevcon 2015, available also on youtube.
Android Testing at Skyscanner
This talks was not only interesting for the contents, testing testing and testing, which I am really a fun of, but it was also very fun, see the pic below for example. The guy had some good humor 🙂
It was nice to see how at Skyscanner they deal with fragmentation, which is very important for their kind of products. They are available worldwide on mobile and web, and they have to deal with localizations, cultures, and various network requirements.
To have an high quality product they had to build a rigorous testing strategy connected to their CI environment. They do crowd testing, which exponentially increased their device/OS/network coverage. They use Applause to find out localizaton issues. Applause is really good also on follow up on testing.
Moreover they really thought through their releasing strategy. In some countries may be easy to download 50MB of apk every week. In other countries, instead, 50MB may be one week of salary, therefore it is better to release over there less often, like every 6-8 weeks.
They use a lot also the “staged rollout“:
“one of the killer feature of the Google Play Store, while on Apple you simply cannot do that. For Apple you need to do it manually by releasing to few markets only and with a lot of flags set in analytics to warn if anything goes wrong”.
Other testing strategies and tools adopted at Skyscanner are:
- A/B Testing,
- Selenium, which drives action on the web, programmable on various languages,
- Cloud Testing, to reduce number of devices to purchase and to increase the device fragmentation coverage (Amazon Farm lab).
“When I joined Skyscanner I had more android devices than the company had”.
With a little help from my libs
by Royi Benyossef, GDE and Android group leader at Vidmind.
Unfortunately I could not follow the whole talk of this other GDE because I was in the parallel talk about testing at Skyscanner, however I was able to find his slides here.
I really recommend to see the slides and to follow this guy because I had the opportunity to see his speeches in other conferences and he really had something to teach :-).
UX Matters
by Wiebe Elsinga, GDE for Android at Egeniq
And finally, one of the best speaker and most entertainer guy of the conference walked on the stage at the end of the second day of the BABBQ.
As he described himself, he has a “passion for bad design and bad user experience”.
“There will be some images of iPhones, but only for example of bad design”.
His presentation was already given a few times in other android events, so was nothing new for me, however it was a good refresh, because he has some very good tips for all designer and developers:
- analyse your users: “knowing is half of the work”,
- (re)thing: don’t assume anything, think about alternatives,
- “making it simple is hard to do”,
- adapt, make it familiar,
- brand your app, use the right colors,
- give interaction feedback, “it’s really annoying when I click on something and nothing happen, did I did it wrong?”
- add support for new stuff, like android wear support or tv, it makes user to feel special,
- help the user, try quick tutorial to give information, but not annoy them,
- “designers are also nice people”, talks to them if you feel that something is wrong with your design,
- “read the f*cking documentation” provided by Google
And to conclude, his last quote (his own quote) was:
“know what you make, for whome you make it, and how“.
Conclusion
This first Big Android BBQ in Europe was generally a good event. Despite the poorly selected location and the almost not existence of expo area, there was for sure a lot to learn thanks to the great speakers that were there. I hope that they will have a second edition of the event next year, but I wish that they will find more sponsors in order to have the possibility to arrange every thing a bit better.
Last but not least, a pic from twitter about the world’s largest marshmallow sculpture build at the BABBQ during the two days.
