Solid Quacamole

Automatically cancel running builds on the same branch, when a new commit is pushed Image taken from: https://cloud.google.com/images/products/cloud-build/cloud-build.png CloudBuild is a CI/CD offered by Google. At Workable’s Mobile department we made a proof of concept to check if CloudBuild fits our needs in order to be used for artifact (APK) building.A complex project requires a lot of custom configuration in order to properly set it up and we were able to find most of them in the great CloudBuilders community repo.

Image taken from: https://bit.ly/32EDPVH Our codebase at Workable’s Android app has grown over the years due to the wide variety of features we offer. As most of you already know, a single monolithic Android app is often one factor that contributes to slow build times. One of the proposed ways of reducing build times, is to split the monolithic app module into smaller modules, that could be cached and compiled once.

Image taken from ProAndroidDev Android Studio 3.5 has reached beta and it was time to try it out as a daily driver in work. Especially with Project Marble having introduced so many bug fixes and performance improvements, that meant the benefits would have an immediate effect. Android Studio 3.5 also includes a new version of “instant run” written from scratch. Since we had it disabled in order to avoid possible build issues with the previous implementation, it was time to give the new “instant run” aka “Apply changes”, a try.

Taken from https://cloud.google.com/blog/products/maps-platform/introducing-new-improved-places-sdks Courtesy of Google. Context Up until January 29, 2019 all Places functionality was part of Play Services. Since that day Google announced new Places SDKs for both Android & iOS platforms. (https://cloud.google.com/blog/products/maps-platform/introducing-new-improved-places-sdks). The deadline for the migration to new Places SDK, is July 29, 2019. The new Places SDK brings in new methods replacing the previous ones, so this should be considered as a breaking change if you want to follow that path.

An example of our testing pipeline In our days, almost every project, is backed by a Continuous Integration system (aka CI). Either that is an Open Source project or a private repository in the organization of your company. > Why do I need a CI? Well, CI is what will have your back, at any given time. We are engineers and we might make mistakes from time to time, but 99% of those times our mistakes could have been easily detected by the proper tools, running in our CI, for each PR or commit.

Nearly a year and a half ago, Facebook released Litho as an Open Source project. Litho is an Android framework, which lets you define your UI in a declarative way. It immediately got my interest and I started getting my hands dirty with some examples and pet projects.It was a nice experience getting in touch with Litho and its React-like nature, that was a first for me. The amount of interest in that new area, made me realise that I could dive a bit more into it, by also contributing to the project.

Android Community in Greece has its own Slack team :) New members that want to join our Slack team, fill out an invitation form and then administrators invite them over to the team! But the form currently was asking for quite a little of info that would let us understand and analyze the needs of the people joining our team. We ended up discussing it with the Admin team and decided to actually add a multi-select question with all the channels of the Slack team, in order to better understand why new people want to join the team.

What is Litho? Litho is a declarative UI framework for Android, by Facebook, that was teased from Lucas Rocha the past October on a blog post he wrote in Facebook’s Engineering blog. Litho is backed by Yoga which is a cross-platform layout engine, based on the FlexBox architecture.Litho already includes some widgets, in its core: e.g.: Text, Image and EditText. You might notice though, that there are some basic widgets that are missing, like a Button.

Software engineering (SWE) is the application of engineering to the development of software in a systematic method. As Software Engineers, even more those of us who have to deal with Front-End Software Engineering, we deal every day with loads of errors. We can pretend that they do not exist… but, if we really care about the UX of our app, we have to deal with them.Dealing with errors though, is not just something that has an effect on the end result and what a user sees.

How many times have you struggled logging in on a newly downloaded app? How many times have you registered on a social network, a streaming service or a productivity tool and you found out, that they also provide a mobile solution? Well personally, I can recall a lot of times, that I found myself in that position. A lot of apps provide great UI, even on their log-in screens, but UX is something more painful and as a result something more valuable, when you are trying to attract new users!

Most of us, are using RecyclerView to present data to our users, in the form of a list. It is a common thing as well that a RecyclerView can draw multiple layouts on its rows, which pretty much means different XML layouts, different things to allocate memory for and sometimes tricky parts where things get so messy that we have frame drops.Workable’s Android application, is one of those applications that need to present data in the form of a list.