Building a mobile app isn’t only about coding. It is the entire process, automations and testing, code architecture and of course people behind all of that. I was writing about all of this in my latest blog post Fail safe, not fast.
Today you can also see the video from my presentation at Mobiconf 2018.
I was talking about our experiences from building mobile apps at Azimo. So if you are curious about how the relatively small team can build effectively an app for the global market, I invite you to watch this:
I also had a chance to share my insight during this year’s Google DevFest in Coimbra, Portugal. Slides from the updated presentation can be found on my SpeakerDeck.
I hope you’ll enjoy it. 🍿📺
Soon I’ll publish more posts about doing effective mobile engineering. Stay in touch!
Breaking the monolith to microservices is a well-known concept to make backend solutions extendable and maintainable in a scale, by bigger teams. Since mobile apps have become more complex, very often developed by teams of tens of software engineers this concept also grows in mobile platforms. There are many benefits from having apps split into modules/features/libraries:
features can be developed independently
project structure is cleaner
building process can be way faster (e.g., running unit tests on a module can be a matter of seconds, instead of minutes for the entire project)
In case you are struggling with multi-module Android project, I have created example app showing how to deal with things like:
Dependency injection with Dagger 2
Jacoco tests coverage report
Even if those are very basic things, it can take some time to make them working correctly in multi-module Android app. To have working solutions in one place, I have created example project on my Github account. There will be more over the time (proguard, instrumentation testing, instant apps). But even at this stage it is also worth sharing.
About one year ago I had a privilege to share my experience with mobile dev community at Mobiconf conference in Cracow. Because of my introvert nature, it was a big personal challenge to stand next to a couple meters high screen and talk to the international audience. I also don’t like to watch my video recordings, but having in mind the message which I wanted to share, I believe that it’s good to remind this particular one from time to time.
As developers (and engineering team leaders) it is always good to remember what is the biggest value we can give to the company. In a time of data driven development, where companies constantly learn about their users and try to adjust the product to meet expectations I believe that the most important thing is the ability to iterate fast. To bring new value in the smallest release cycles with a product free of bugs.
And this is what my presentation is about. Why we should test, use dependency injection or automate delivery process. I show Android app as an example, but the same rules can be applied to iOS or any other client side platform.
Today, during Google Developers Day in Kraków, we could see Google Developers + Udacity cooperation announcement which brings us 60 000 seats in their online courses (Web developer and Android developer, 30k seats in each one). The scholarship is dedicated to residents of Europe, Russia, Egypt, Israel and Turkey. All accepted students will have an opportunity to learn coding Android or Web during 3-months course with a help from Udacity and Google mentors.
10% of the best ones will have an opportunity to take a part in Nanodegree program for free, which ends with certification and a great chance to find a real job in the picked area.
As a former student of Udacity Nanodegree program (Artificial Intelligence Nanodegree in my case), I can only say: thank you Google, thank you Udacity! This amazing initiative with high-quality materials will bring tons of value for IT industry all over the world:
For students and future developers who will have a chance to learn how to build a real product from experts working with those technologies on daily basis,
For employers who will have a chance to hire well motivated junior devs with practical experience and great will to gain new skills,
For entire IT industry (including Google, Udacity and others), because more IT specialist means faster growth this area,
And for the people all around the world. Online and cheap/free access to knowledge means that there are much fewer limitations for those who have a great will to learn and want to be professionals in the future.
Every big tech company today is data-driven. Products are more often built based on collected data rather than internal opinions. It’s very likely that in this moment some of apps on your device are serving you A/B test variants, checking how: new layout, text or even functionality affect your activity and engagement.
The biggest companies have dedicated Business Intelligence teams, their own data warehouses, custom analytics tools and big flat screens in conference rooms showing realtime charts.
And the most important — endless audience waiting to be analysed by pie charts or bars 📊.
Some time ago I published unofficial Google Actions SDK written in Java. Source code and documentation can be found on Github: Google-Actions-Java-SDK. Library can be also downloaded from Bintray jCenter:
A couple months ago, during MCE³ conference, Gregory Kick in his presentationshowed a new concept of providing Subcomponents (e.g. to Activities). New approach should give us a way to create ActivitySubcomponent without having AppComponent object reference (which used to be a factory for Activities Subcomponents).
To make it real we had to wait for a new release of Dagger: version 2.7.
In Azimo Android app we use Dagger 2 as a framework for Dependency Injection to make our code architecture clean and easy to scale. Like in our previous post we would like to share our experience so today I’ll show how to avoid issues and build custom UserScope which can be used in production app.
Custom scopes in Dagger 2 can give better control on dependencies which should live unusual amount of time (different than application and screen lifetime). But to implement it properly in Android app we need to keep in mind things like: scope cannot live longer than application process, process can be killed by system and restored in the middle of user flow with new objects instances.