![programmer-1653351_640.png](https://cdn.steemitimages.com/DQmSASH1cUBxLkR9vYFBkF6RRTqM3KNNhFsZg9xw4UiHrp9/programmer-1653351_640.png)

In the past several months I haven't written out a lot of the articles - not technical - about my developer's life - neither philosophical. I didn't had much time because I worked on several projects simultaneously - personal and non-personal.

And this month I got the time to work more on my own projects again and to think a little more about stuff. So here are some notes on the items I can point out about technology and stuff.

My "Breathe In" application (and probably not only it) is totally outdated in several terms - of code standards - using the best practices, patterns, components and code level improvements. I learned a lot and I will probably not integrate all my new knowledge about Android.

Lint code check - Android Studio (IntelliJ) is becoming very smart on static code analysis that could resolve future run-time/production issues.
Forget about the features "late-init" and "!!" (assume variable is not null) in Kotlin programming language. In Kotlin - Initializing properties outside of the constructor forces us to define it as null-able or late-init. I have seen initialization errors in my experience, no matter how much thinking I person puts into the code and it's workflow. It is better to define them as null-able and probably access the property by a method and in it, you could check for null equality. Assuming a variable is null-able with "!!" is also a No-No!
Thinking outside of the concrete platform you are targeting. Yes, every tool and program is designed for specific environment and we cannot escape the specifics, but if we try to target new place, we fall into platform dependencies/implementation hell. For example - many Android apps are designed for phones, but tablets exist already for about a decade, I'm seeing a future where Android Apps will run on Desktop-like computers. Having an app act like it is on a phone will bring very very poor user experience.

Some code level examples for this in Android are:

Non-Android Google APIs layering basic phone functionality - I had some trouble with Maps & Location APIs, but probably there are more.
Voice - Google has the Assistant, but on Amazon devices - there is no OK Google, because there is Alexa. That is why I don't like them both in theoretical/philosophical point of view. They are proprietary - owned by Google and Amazon, they are different, non-standard. I currently don't see any Voice Provider portability.
Android totally refactored their support library and migrating old project is starting to look like a little hell, they did it several times, migrating from Eclipse to IntelliJ, creating several UI/UX iterations, the list could go on to infinity.
Google increasingly adds restrictions to the apps on code level and more that are published to the store - with stuff that looks beneficial to the end user - like:
Restricting apps that target old versions of Android so background tasks will no longer will be unlimited - saving battery life.
GDPR complacency - theoretically every user must have control over what data the apps that he uses has access to, saves and guards and how the apps are using it.

In the end of the day all this is - is more non-business logic work for the end-developer making some business applications. I never liked a lot - fighting with the specific custom proprietary (even if the framework was open source) technologies. I see a lot of posts lately on Facebook and LinkedIn about lessons for learning technology X. It is good to have so much content and to have from where to learn. Any practical person must know from his own experience how stuff works, so not to code and expect that the programs (or anything in life) will work just because he wants it, but like I have written before - It is increasingly fake, empty, non-humanly valuable to me to focus so much on the tools, but to what everybody/and what the programs/ are doing in the End (in more practical terms).

And this month I got the time to work more on my own projects again and to think a little more about stuff. So here are some notes on the items I can point out about technology and stuff:

Lint code check - Android Studio (IntelliJ) is becoming very smart on static code analysis that could resolve future run-time/production issues.
Forget about the features "late-init" and "!!" (assume variable is not null) in Kotlin programming language. In Kotlin - Initializing properties outside of the constructor forces us to define it as null-able or late-init. I have seen initialization errors in my experience, no matter how much thinking I person puts into the code and it's workflow. It is better to define them as null-able and probably access the property by a method and in it, you could check for null equality. Assuming a variable is null-able with "!!" is also a No-No!
Thinking outside of the concrete platform you are targeting. Yes, every tool and program is designed for specific environment and we cannot escape the specifics, but if we try to target new place, we fall into platform dependencies/implementation hell. For example - many Android apps are designed for phones, but tablets exist already for about a decade, I'm seeing a future where Android Apps will run on Desktop-like computers. Having an app act like it is on a phone will bring very very poor user experience.

Some code level examples for this in Android are:

Non-Android Google APIs layering basic phone functionality - I had some trouble with Maps & Location APIs, but probably there are more.
Voice - Google has the Assistant, but on Amazon devices - there is no OK Google, because there is Alexa. That is why I don't like them both in theoretical/philosophical point of view. They are proprietary - owned by Google and Amazon, they are different, non-standard. I currently don't see any Voice Provider portability.
Android totally refactored their support library and migrating old project is starting to look like a little hell, they did it several times, migrating from Eclipse to IntelliJ, creating several UI/UX iterations, the list could go on to infinity.
Google increasingly adds restrictions to the apps on code level and more that are published to the store - with stuff that looks beneficial to the end user - like:
Restricting apps that target old versions of Android so background tasks will no longer will be unlimited - saving battery life.
GDPR complacency - theoretically every user must have control over what data the apps that he uses has access to, saves and guards and how the apps are using it.

In the past several months I haven't written out a lot of the articles - not technical - about my developer's life neither philosophical. I didn't had much time to improve my because I worked on several projects simultaneously - personal and non-personal.

And this month I got the time to work more on my own projects again and to think a little more. So here are some notes on the items I can point out about technology and stuff:
My "Breathe In" is totally outdated in several terms - of code using the best practices, patterns, components and code level improvements. I learned a lot and I will probably not integrate all my new knowledge about Android.

Lint code check - Android Studio (IntelliJ) is becoming very smart on static code analysis that could resolve future run-time/production issues.
Forget about the features "late-init" and "!!" in Kotlin programming language. In Kotlin - Initializing properties outside of the constructor forces us to define it as null-able or late-init. I have seen initialization errors in my experience, no matter how much thinking you put into the code and it's workflow. It is better to use define it as null-able and probably access the property by a method and in it, you could check for null equality. Assuming a variable is null-able with "!!" is also a no-no.
Thinking outside of the concrete platform you are targeting. Yes, every tool and program is designed for specific environment and we cannot escape the specifics, but if we try to target new place, we fall into platform dependencies/implementation hell.

Some concrete examples for this in Android are:

Non-Android Google APIs layering basic phone functionality - I had some trouble with Maps & Location APIs, but probably there are more.
Voice - Google has the Assistant, but on Amazon devices - there is no OK Google, because there is Alexa. That is why I don't like them both in theoretical/philosophical point of view. They are proprietary - owned by Google and Amazon, they are different in their configuration, APIs and so on.
Android Totally refactored their support library and migrating old project is starting to look like a little hell.
Google increasingly adds restrictions to the apps on code level and more that are published to the store - with stuff that looks beneficial to the end user - like:
- Restricting apps that target old versions of Android so background tasks will no longer will be unlimited - saving battery life.
- GDPR complacency - theoretically every user must have control over what data the apps that he uses has access to, saves and guards and how the apps are using it.

In the end of the day all this is - is more non-business logic work for the end-developer making some the business applications. I never liked a lot fighting with the specific custom proprietary (even if the framework was open source) technologies. I see a lot of posts lately on Facebook and LinkedIn about lessons for learning technology X. It is good to have so much content and to have from where to learn. Any practical person must know from his own experience how stuff works, so not to code and expect that the programs (or anything in life) will work just because he wants it, but like I have written before - It is increasingly fake, empty, non-humanly valuable to me to focus so much on the tools, but to what everybody is doing in the End (in practical terms).