Android Programming (with Kotlin)

...

(incomplete)

You may find portions of this post hard to understand if you haven't checked the following:

(SLT1) Standards For Learners and Teachers

First Steps

Visit batikanor.com/d/android%20dev%20course OR search for "android dev course" then take the pathway that fits you the most. Please check the prerequisited before reading this blog post through.

Some quotes from the pathways I've taken without any order whatsoever:

The unit for margins and other distances in the UI is density-independent pixels (dp). It's like centimeters or inches, but for distances on a screen. Android translates this value to the appropriate number of real pixels for each device. As a baseline, 1dp is about 1/160th of an inch, but may be bigger or smaller for some devices.
Just like dp is a unit of measure for distances on the screen, sp is a unit of measure for the font size. UI elements in Android apps use two different units of measurement, density-independent pixels (dp) which you used earlier for the layout, and scalable pixels (sp) which is used when setting the size of text. By default, sp is the same size as dp, but it resizes based on the user's preferred text size.
String resources should have lowercase names, and multiple words should be separate with an underscore.
After finishing the pathway(s) you could either start working on a project, making use of the android studio api along the way, or improve yourself on one the following topics:

1. Kotlin

2. Design Patterns

They make the code more understandable for everyone. It is good practice to follow conventions while programming so that when other people take on or try to contribute to the project it won't feel foreign to them.
They make the project loosely coupled
Please visit batikanor.com/d/android%20common%20architectural%20principles or run "ddgr -j android common architectural principles" and see the results for yourself.

2.1 MVVM: Modal View ViewModel

Actually the term MVVM is never openly said by google, but it recommends this pattern and it is popularly known as MVVM by the developer community.

Activity/Fragment Classes: UI of our application

To display data, we use data binding with the help of ViewModel. So our activity is just dependent on ViewModel to get data.

One of the benefits is that the ViewModel won't update the data if the view is destroyed, solving some problems that may occur due to lifecycle changes.

ViewModel will fetch the data from the repository. ViewModel is only dependent on the repository to get the data.

The repository may use the local database ( that is, for this graph, SQLite ) or a backend server using RESTful API. (To learn more about RESTful api, visit batikanor.com/d/RESTful%20api or run "ddgr -j RESTful api")

So ONLY THE REPOSITORY is dependent on MULTIPLE SOURCES TO GET THE DATA.

We will try to fetch the data from the local storage first (cuz if the user has a connectivity issue, the other option will be unavailable, as the RESTful API requires network connection to fetch data.)

Google says it is important to use a pattern that follows the common architectural principles, which doesn't always mean that MVVM be a must. Let's check our other options

2.2 MVP: Modal View Presenter

2.2.1 Jetpack Components (You could learn from developer.android.com )

E.g. pagination isn't really a part of most courses, so you should learn to learn it by your own

2.2.2 Room (For database)

2.3 MVC: Modal View Controller

2.4 ??: Unique Architecture Of Some Other Sort

Additional:

They say if you already know kotlin well, it shouldn't be hard for you to learn swift. I haven't tried that out myself but I think that it is useful knowledge.