MOBOS 2020 – an Android developer’s perspective

From left to right – Cristi Streng (CTO), Csaba Biro (Android developer), Daniel Szasz (iOS developer), David Popa (Android developer) and Pal Levente (Android developer)

Hi, I’m Pal Levente and I’m an Android developer going on 6 years strong at Mobiversal

It’s not the first time I’ve gone to MOBOS (Mobile Operating Systems Conference), and it’s probably not the last time. So this article is going to provide you with an honest opinion on what I experienced at the conference.

And this…

… Is the obligatory first selfie upon arrival at the conference (PS. I’m an Android developer that uses an iPhone, because reasons)

Before starting the conference, we got the opportunity to taste great food, with a variety of dishes.

Paying attention on an empty stomach? Not recommended 🙂

After we filled our bellies with delicious food, we took our seats for the first presentation we’ve participated in.

Flutter

The first talk I attended was about Flutter, where Swav Kulinski presented his vision of what Flutter is. He is a professional with years and years of experience in the mobile sector. What he did was renounce native development in favor of Flutter.

For those of you who don’t know, Flutter is a cross-platform framework (Android, iOS and Web), which lets you write code in a single place and have it run on multiple platforms (basically a single codebase).

Flutter can be considered to be a rendering/graphic framework. Every element inside the application is a widget and the build time is considerably reduced. Changing the data/elements and running them took under a second, as opposed to Gradle where we need to wait minutes upon minutes to see the changes made.

Unfortunately, Kulinski forgot to tell us what architectures we can use with Dart/Flutter.

He also summed up that Flutter should be used mainly by startups, who need to ship something fast. What he doesn’t recommend though, is to not rewrite existing applications just for the sake of having them cross-platform.

Tesla

The Tesla with Sebastian Sarca, a good friend of mine and our former CTO

At the conference, there was a start-up that deals with car rentals which held a competition for the people at the conference. The prize was a paid weekend of driving luxury car brands (even Tesla, see pic below).

The fun part came when they had Skoda in between the car brands considered to be luxurious. That’s awesome because I drive a Skoda, even though I considered it to be the poor man’s Volkswagen.

The Tesla after the test drive (just kidding, it’s an Internet image)

Clean code – Kotlin

The next presentation I’ve participated in was about clean code practices with Kotlin.

Magda Miu presented different examples and modes of using Kotlin. The presentation was intended towards beginners with Kotlin. She even told us she took inspiration from Robert C. Martin’s book, Clean Code.

This presentation dealt with concepts familiar to me, to us. We already apply clean code concepts / S.O.L.I.D. principles in our work.

After the presentation, I went to personally talk to her and afterward I asked her for a few tips about testing. She recommended O’Reilly’s Unit Testing book. I need to give it a read someday, as it explains in detail what unit tests are, when to use Mock vs Spy and other best practices.

Flixbus

For me, Flixbus’s presentation was the best one. Vladimir Jovanović is a Rockstar Android Guru. I’ve even thought about keeping in touch with him for further insights. He works for the renowned German bus transport company Flixbus.

Vladimir Jovanovic of Flixbus

He talked about Flixbus’s app, which was developed both for Android and iOS, natively. The apps were developed back in 2013-2014 and because they weren’t properly maintained, the code became legacy code.

At one point, the company needed to introduce new payment modes, features, etc. and didn’t know how to continue further based on the existing code. After a number of debates spanning multiple days, they came to the conclusion that the Android app will be refactored (from Java to Kotlin, new architectures and breaking the code up into modules).

On iOS they decided to rewrite the whole app, being written in Objective-C and all. One of the reasons behind writing it all over again was that in 2020 it’s hard to find developers who know Objective-C.

He got our attention when he told us that he doesn’t recommend fully “rewriting” applications because many functionalities will be “lost” in the new one. Also, as long as you develop the new app, you can’t offer support for the old one. For a year and a half it took them to rewrite the app, they offered limited or no support.

It’s important to stress this fact as Customer Support is one of the main pillars of a good product. We even dedicated a whole chapter to Customer Support in our book, From A to App Success: How to turn ideas into apps that make a difference (which is free to download).

He told us that decisions like this need to be thoroughly weighed as they can bring even a large company to bankruptcy.

Flixbus’s Android team is made out of 6 people, 4 coders + 2 testers; while the iOS team has 5 people, 1 person with Objective-C knowledge (and the oldest in the company) and the rest Swift developers and testers.

At Appointfix, we were confronted with the same issues as the people at Flixbus. God classes with lots of lines of code, without any architecture and coupled code. The Activities/Fragments (undesirably) contained the business logic and a number of mistakes.

This is why we took the decision to refactor the app in such a way that we could also do maintenance work on it at the same time. One part was rewritten/published online while focusing on continuing the refactoring process on others (trunk-based development). Little by little, we refactored with Kotlin and new architecture, then we published the app and awaited feedback.

After the presentation was done, I went to the guy and started to talk more in-depth about different testing modes and Android architectures.

And then it became clear to me that Vladimir Jovanović is a textbook programming Rockstar.

Flixbus’s Android team decided to refactor the code based on a number of modules. Payments, Networking, Features, etc. I asked him how they solved the issue of “UI communication”, a problem that our team at FieldVibe was confronted with. He told me that it depends on the developer/team how they want to treat this case. 

You can use communication interfaces (how they did it) and/or through deep linking. By deep-linking I mean navigating through activities/fragments through intents with URLs.

He also told me that for their Flixbus Android app they have thousands of unit tests and hundreds of UI tests. Their unit tests test different Android parts such as the ViewModel, Services, etc.

All in All, I really enjoyed Flixbus’s presentation, and most of all, I really hope that one day I’ll get to work on something with one of Android’s Rockstars, Vladimir Jovanović.

Heading back home

Around 18:30 we headed back home. We had a lot of fun with this year’s edition of MOBOS, where we partook in interesting presentations, shared jokes and insights with fellow domain colleagues from the mobile industry and of course enjoyed the awesome food.

There was a bit of an expectation from my part for some of the speakers to be more professional. But, like I said, the last presentation was awesome and well worth everything.

Summing up my to-do list based on the conference:

  1. Read O’Reilly’s unit testing and implement the examples
  2. Continuous integration (Jenkins + Fastlane). The tests need to run automatically + code-style check. If you don’t respect the code then it will be rejected by the system.
  3. Integrating code check plugins (Find bugs)
  4. Research for creating a mini-project with module-based architecture

Overall, MOBOS was a great experience for everybody, and there was a lot to learn and enjoy. Hopefully, we’ll get to show up next year’s edition which will certainly be the best yet!


This article has been brought to you by Pal Levente, courtesy of Mobiversal.

Leave a Reply

Your email address will not be published. Required fields are marked *