Best Practises for Android Development as a Daily Business
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 90 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47640 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
2
10
13
14
26
35
37
45
48
54
55
56
63
64
68
73
74
77
78
80
82
85
89
00:00
SoftwareInteractive televisionAndroid (robot)Projective planeAndroid (robot)Metropolitan area networkSoftware developerData managementBasis <Mathematik>Multiplication signComputer animation
00:45
Interactive televisionAndroid (robot)Mobile appGame theorySoftwarePrototypeComa BerenicesImplementationData managementProjective planeAndroid (robot)Cartesian coordinate systemSoftware architectureDigitizingSoftware developerAdventure game
02:06
Interactive televisionAndroid (robot)Computer animation
02:34
Interactive televisionAndroid (robot)InternetworkingWorkloadComputer animation
03:21
Interactive televisionAndroid (robot)Client (computing)Mobile WebData storage deviceComputer animation
03:52
Interactive televisionAndroid (robot)Concurrency (computer science)CodeComputer architectureSoftware developerSubstitute goodProcess (computing)CodeProgrammierstilMultiplication signFunctional (mathematics)Android (robot)Content (media)Projective planeAbstractionView (database)Square numberUniqueness quantificationBoilerplate (text)Computer architectureLibrary (computing)Goodness of fitPercolation theoryRule of inferenceContext awarenessConcurrency (computer science)Scheduling (computing)Formal languageKnowledge basePattern languageTerm (mathematics)Point (geometry)Data storage deviceFacebookPlanningComputer configurationDataflowCompilation albumRight angleMaxima and minimaECos40 (number)Line (geometry)Scripting languageMobile WebUniformer RaumAuthorization
09:15
Interactive televisionAndroid (robot)Computer architectureProgrammierstilSubsetPattern languageMachine codeCodeMereologySoftware developerConfiguration spaceProjective planeData structureLine (geometry)Variable (mathematics)Computer animation
10:42
Interactive televisionAndroid (robot)RAIDArchitectureGame controllerGame controllerCASE <Informatik>QuicksortVariable (mathematics)InjektivitätComputer architectureObject (grammar)Link (knot theory)Multiplication signVideo gameFunctional (mathematics)Shared memoryView (database)40 (number)Repository (publishing)SpacetimeSocial classLine (geometry)Derivation (linguistics)Template (C++)Projective planeEmailCartesian coordinate systemContext awarenessMedical imagingSquare numberCycle (graph theory)Configuration spaceCodeMobile appAndroid (robot)Pattern language2 (number)Computer fileProgrammierstilType theory
13:19
Interactive televisionArchitectureAndroid (robot)Source codeWeb 2.0Endliche ModelltheorieState of matterObject (grammar)Transformation (genetics)DatabaseServer (computing)Source codeInterface (computing)Module (mathematics)QuicksortData storage deviceJava applet
14:13
Interactive televisionAndroid (robot)CodeConfiguration spaceProjective planeCASE <Informatik>Right angleMotherboardConfiguration spaceText editorMultiplication signLine (geometry)Attribute grammarObject (grammar)Template (C++)Sign (mathematics)TunisCodeVideo gameWorkloadComputer architectureAndroid (robot)AutomationComplex (psychology)Set (mathematics)Control flowFile format2 (number)
16:05
Interactive televisionAndroid (robot)FreewareProduct (business)Shared memoryMultiplication signProjective planeAndroid (robot)Validity (statistics)FreewareProduct (business)Image registrationComputer animation
16:42
Interactive televisionAndroid (robot)TwitterFacebookImage registrationInsertion lossState of matter
Transcript: English(auto-generated)
00:00
Welcome, everyone, to this session, Best Practices for Android Development as a Daily Business. Sorry, I'm just amazed how many people are trying to fit in this room. Today, I learned best practices are very popular. So lessons learned from me, thank you for that. Also, another revelation before I really start,
00:21
I feel the title is a little fuzzy because daily business is not that what I meant, to be honest, because you all work in Android on a daily basis. What I meant, what I really meant with daily business is multi-project management. So what I'm trying to talk about today are best practices for teams
00:42
who work on multiple projects at a time. Before I really dive into this session, I'd like to introduce AppCom and myself as well. We at AppCom consider ourselves as your partner for digital adventures.
01:01
So if you have an idea, a prototype, or working software, doesn't matter, we take care of the issues. So we help you, oh, sorry. We help you to plan every aspect of how you realize a project. So if it's release management, portfolio strategy, design,
01:24
UX concept, and of course software architecture and implementation as well. We do a lot of apps, so hence the name AppCom, but we also do portal and backend solutions as well. Myself, I'm a software developer
01:41
for over 15 years right now. I started very early on by developing games. Unfortunately, nothing fancy too far. And I started developing Android applications for three years now. And I'm working as software architect for the last two years.
02:06
Oh, sorry. All right, another disclaimer before we really dive into the session. I'm not here to sell you anything. And I'm also not here to let me celebrate or break or something like that.
02:22
We learned in the last few years a lot from the Android community and we feel like we want to give you something back. So that's why we're here. We want to share our knowledge we found over the last few years. So why should you care? Why should you care about another guy
02:42
saving or presenting his best practices? There are a lot of best practices out in the internet. You can learn from that. So why does it matter that I show you ours? Why not? You are here to learn something anyway, yeah? Right, we want to share all of it. So why not keep an open mind and maybe you can take something out of it for you too.
03:05
And also what I try to focus on is our best practice for small teams having a huge workload. So I try to emphasize on the journey we made over the last three years and I want to show you how you can handle
03:21
huge workload in smaller teams. Then again, we have huge experience with very well-known clients especially in Germany and Europe. And also we tackled some of the more advanced techniques like releasing in custom stores
03:40
like the Citrix mobile store which was quite difficult to be honest. And also like MD&S, NFC and stuff like that. So every journey has its start. So let's look at the very beginning of our journey. How did we start three years ago?
04:00
We started out with a very stable but small department. We had three developers at max, now we have four. And we started with a huge knowledge base about clean code, important libraries like Dagger, XJava and stuff like that. And of course some of the architectural patterns like MVP, MVVM.
04:23
On the other hand, we had many concurrent projects at the time, each had its tight and very important of course, deadlines and its perks which made it very tricky to work with.
04:42
Like as I already said, there's a mobile store and various others. So what were the really big pain points? Of course, many concurrent projects, nobody likes that. Tight deadlines, that's another very bad thing.
05:02
And also a small department. Basically, we were very few developers who had many projects with a tight schedule. So what did we do? Disclaimer, I hope this is no surprise. We didn't practice any witchcraft, stopping time or something like that. We just followed some very basic and simple rules
05:21
we found to optimize the process and the workflow in our department. And I try to emphasize why it matters and why you should do it too if you already don't. Also, let's get into it. We wanted to write less code
05:40
because writing less code is always more time for us and time is key, especially when working with many projects at a time. So what we did is we analyzed where we can use annotations and where we can substitute code with annotations. I think you all know this piece of code,
06:01
not this one especially, but you all wrote an activity or fragment or stuff like that and set the content view for view. What we did is we created an annotation, a so-called layout annotation, and we created an abstract activity or fragment or whatever you want and just loaded the layout from there.
06:22
So what we did basically is we got rid of the inflation boilerplate code, which is always a good thing because the resulting code will look like this. Two benefits, the first one is the activity or fragment looks very clean and it's also very descriptive
06:41
because I don't want to write any code to get my layout inflated. I just want to be descriptive, to be as descriptive as possible. Also, it's faster to write. Again, we saved some time and also it's easier to read and reading code very easily is especially important
07:01
when working in teams because chances are that the developer who wrote that code is not the developer, no, the developer who's reading that code is not the developer who wrote the code. So it's very easy to make the code as readable as possible so you make it easier for your colleague. All right, the next thing to do,
07:21
you did this all, is using libraries. Well suited libraries, of course. It's very noble to write all the code by yourself, I know, but on a tight schedule, nobility is not an option. Especially the top lane is a very time saver.
07:42
I know some of them are criticized also for good reason but keep in mind that this scenario I'm talking about or the context I'm talking about is very few people, many projects at a time, very few time and yeah, in that manner,
08:01
libraries or using libraries is a real time saver. All right, one thing that happens when you work in a team is that everyone has its unique coding style. Having your unique coding style is perfectly fine. Yeah, that's very natural. But when working in a team,
08:21
it's a good thing that you speak in the same language in terms of coding style so it's easier to read. Consider these two functions. They were written by two distinct developers and when you think about it that your whole code base looks like this,
08:42
it's a mess because every time you go in a class or read a function, you have to just pass the coding style. So applying a unique code style for your whole team will uniform the code base and will look like this which is easier to read for all of us.
09:02
Again, I don't want to force you to use our code style but I want to show you that applying code style is very important. If you wonder, we use the Android Square coding style which can be downloaded here. Okay, code styles are just a subset
09:22
of the so-called coding guidelines. When you're defining code guidelines, you define more than the style but you also define how to name variables, what package structure you're using, what architecture you're using and stuff like that. So when you skip coding guidelines,
09:42
every developer will choose its own style. He's using so far and the code base will look like a mess especially when you skip the architectural part. So what we did is just like I said, we defined all of it so that we have a code base
10:02
which is healthy and easier to maintain. And also what we did unintentionally was applying the convention over configuration pattern which will force you that the code base of each project will look alike. So when you switch projects,
10:20
you always feel that you've seen this before because the last project just looked like this. We also published our coding guidelines. You can find them here. The main benefit when you define
10:41
how variable names are, how to name variables, you can derive live templates from it. You all know live templates I hope at least and I hope also that you know that live templates can be parameterized. So I consider this piece of code over here. We have three variables, the view ID,
11:03
the type and the view ID camel case and the view ID camel case is based on the view ID. So when I enter the view ID, the view ID camel case is written out without me doing anything. So that when you put this into practical things,
11:21
you see that when I name a variable user preview image view the name of the variable is also automatically set. And also we clocked this line. You can write that in less than a second. And when you consider a very complex layout, you see that you can save a huge amount of time.
11:42
These are just some examples of all live templates you don't have to read at all. You can find them also here, we publish them. And also another tip, when you want to share live templates, make it as easy as possible. We've seen the Square Android repository earlier. I showed at least a link to it and we wrote or this repository is based on it.
12:03
So you can install the live templates as easy as the code style. So the next thing is also pretty obvious. Apply an architecture, of course. You all need an architecture in your Android app. And if you document and communicate it to the team,
12:22
they can all apply it in each project, convention over configuration. I just want to go over our architectural style. Again, I don't want to force you to use it. I just wanted to emphasize that having an architecture is very important.
12:41
So usually we have an application activity in the fragment scope. In each scope there is the Android life cycle aware object and application or activity of fragment. We have also the classes which are relevant for the dependency injection. And also some sort of controllers
13:02
which provide incoming functionality like starting intents for phone, email, or stuff like that, loading assets and files. Same goes for the activity scope and in our fragment scope we use the MVP pattern and interactors.
13:20
This is just the app module. We also have usually a second module which is the data module. The main interface of the data module are so-called data stores. In these data stores we provide an interface for manipulating so-called data objects which are models and entities. I will get to that. Each data store utilizes some sort of data source
13:44
which can be a web data source, assets, memcache, a web service, database, stuff like that. And also this works very well when using X Java. But this is out of scope.
14:01
Then we have data source agnostic entities. The models which are provided by the data stores. And also the respective transformers. All right, one more very useful tip we found over the years is the toString method.
14:25
Consider a POJO, a very complex one if you will. When you log it to the logcat without overwriting toString you get this. That's pretty useful. But I'd like to see something more. So I overwrite toString method and I will get this. So this is very readable for now.
14:42
But if I put many more objects into this, so a nested object or a very complex object, it gets harder to read because many of the attributes and also the line breaks by the logcat. So what we basically did is we overwrote a toString method in Android Studio.
15:02
And we will get JSON. That's pretty useful because when we take this JSON and format it, we get this. And this especially works when you have complex objects and nested objects because it's still human readable.
15:21
Just a bit lengthy. All right, I will conclude this session because I don't have any more time when I read that sign correctly. The main thing you should focus when working in a small team with a huge workload is write less code, have more time because time is key. You need time to also focus on things that matter.
15:43
Conventional work configuration is very helpful because you will skip projects or you will do project hopping and when you know one project and you find yourselves better in the second project, it's very helpful because you save time by that. Automize everything including live templates
16:02
and have an architecture set. So to conclude this session, I have two more slides. I hope I get them in time. Have fun, learn, help, share. You work on the same team. You work for the same project and success. So yeah, work as a team.
16:21
Also some marketing, I had to include it. We provide a workshop for you guys. So if you want to learn more about Android and how to launch products and with validated methods like Lean Startup, follow the link, join us
16:40
and get a free registration for the workshop. You can also find us on Facebook, Twitter and GitHub of course and I'd like to see you soon. Reach out to us and yeah, let's make the world better. Thank you.