У меня сейчас довольно нагруженный период и до написания технических заметок нет ни сил, ни вдохновения, поэтому решил сделать подборку всяких товаров с Aliexpress, какими пользуюсь сам, может кому-то что-то приглянется. В подборку войдут не только полезности, но и приятности, по возможности упомяну нюансы, которые могут всплыть при выборе.

Постараюсь сделать подборку из не самых очевидных вещей, поэтому всякие кабели, коробки и сумки сюда не войдут.

Ссылки на конкретные товары прикреплять не буду, по заголовку будет понятно, как найти тот или иной товар.

1. Подставка для монитора

Здесь все просто и без нюансов. Мне хотелось из алюминия, но существует куча разных вариантов и в том числе варианты из дерева и абсолютно разных размеров.

2. Полка на монитор

Поразился находчивости людей, каким пришла в голову идея данного изобретения и как полка для роутера и какой-нибудь мелочи - отличный вариант, что позволяет сэкономить место непосредственно на столе.

3. Огромный коврик для мыши

Очень приятно с таким работать и размеры ковриков иногда встречаются огромнейшие. Можно найти как монотонные варианты, так и с прикольным принтом.

4. USB регулятор громкости

До моих колонок ручка регулировки уровня звука расположена сзади и лезть туда неудобно. Поэтому отличное решение.

5. Подставка для телефона

Часто тестирую свой код на реальном девайсе и такая штука топово помогает. Определенно лучше, чем с девайсом, лежащим на столе.

6. Ящик для хранения кабелей

Крепкая штука. У меня такая расположена на полу и в ней сетевой фильтр. Стоит недешево для куска крепкого пластика и фанеры, но мне слишком надоела пыль в гнездах сетевого фильтра.

7. Силиконовая скатерть для стола

Существует просто огромных и разных размеров и я смог найти подходящую под свой немалый стол, чему доволен, ведь на самом столе системник и колонки, да и в принципе царапать стол не хочется. При толщине в 1-2мм у пленки нет мягкости и на ней даже удобно писать и ничего не подкладывать.

8. Органайзер для кабеля

Тут и лишних слов не надо.

9.1 Стяжка

9.2 Стяжка

10. Подставка для наушников

11. Стол на кровать для ноутбука

Скажу честно: используется редко. Но иногда возможность перенести рабочее пространство на кровать - очень кстати!

12. Подвесной органайзер

Иногда есть куча вещей, которым не место под рукой, но при этом далеко убирать не хочется. И это вполне решение. Не сказать, что смотрится как исключительно кухонный вариант.

13. Светодиодная лента

Не относится к организации, но дает приятный бонус к атмосфере. Лента самоклеящаяся. Можно найти экземпляры с оклееной стороной от известного бренда 3М. Управляются разными способами: от блютус до пульта. Есть варианты для подключения через USB, а есть с питанием от сети. Главный нюанс выбора: как правило ленты двух типов - с цифрами 2835 или 5050. Разница в цене минимальна, но светодиоды расположены нормально именно у второго варианта, в едином блоке. В первом варианте нужный цвет будет получаться при смешении диодов, что расположены далеко друг от друга и если вашу ленту что-то перекрывает, то вместо выбранного света получите лишь радугу.

ФИНАЛ

Для тех, кто дошел до конца - выкладываю главные товары, что мне очень помогли организовать свое место. Какая моя была главная идея при организации рабочего места: избавиться от старого маленького стола и сделать все так, чтобы удобно было работать. Так как мне очень важен психологический момент закрытия крышки рабочего ноута, дабы переключиться в другой контекст, то мысленно закладывал идею, что нужно шэрить изображение на монитор, не плодить большое количество мониторов и в этом мне помогли больше всего последние две вещи.

14. Настольная подставка для ноутбука

Позволяет чуть более компактно ноутбуку разместиться на столе, да и подставка спокойно складывается и убирается подальше после окончания рабочего времени.

15. HDMI сплиттер

То, что помогло по сути организовать всё, как и хотелось. В стационарник и ноутбук идут HDMI и USB кабели (mother USB - father USB type C). Из сплиттера выходит HDMI в монитор. И все готово для того, чтобы перебрасывать по мере надобности изображение на мониторе то с ноутбука, то с ПК - по одному лишь клику на кнопку.

Самое главное не промахнуться со сплиттером. Они бывают двунаправленные и первая моя попытка покупки сплиттера была неудачной, так как по HDMI шел ток и тем самым вращал вентиляторы на видеокарте, на корпусе и кулер. Поэтому нужен именно однонаправленный, а лучше ищите тот, который приложил сюда в заметку.

ЭПИЛОГ

В заметку не вошло много всякого разного, но итак вышло все довольно объемно. Надеюсь, что минимум натолкнул на какую-то идею для поиска полезностей, что помогут организовать рабочее пространство. И отдельный респект тем, кто дошел аж до эпилога!

И зачем это все надо?

Это заметка для зеленых новичков. Не самые зеленые и не самые новички - давно уже попробовали руками все сами. В данной заметке я буду использовать: Dagger Hilt, RxJava2, Kotlin Coroutines и Retrofit2. Dagger Hilt задействован исключительно для МОЕГО удобства, строго не рекомендую начинать познавать Dagger с Hilta, потому что сокращена куча boiler-plate'а, которая дает понимание принципов работы Dagger'а, поэтому это лишь помощь мне, чтоб не плодить совсем дикий щиткод в примерах, за который вам отобьют руки всей бригадой за который отклонят в будущем ваши pull-request'ы.

Y-нылое введение

Начну с определений.

И изначально основное предназначение было именно в этом, а не в том, что в этом вашем Android'е вы ей только потоки переключаете, негодники и негодницы господа и дамы.

С Kotlin Coroutines - все сложнее. Чтобы в них разобраться - надо английский знать, поэтому обращаемся к русскоязычной документации:

И тяжелее всего осознать, как практически обеспечивается эта самая легковесность. Что есть еще на эту тему в доке:

Теперь переходим к практике.

Что делаю и как будет выглядеть?

В качестве полигона буду делать приложение с единственной Activity, что имеет некую ViewModel, которая содержит DataSource-класс (не хотелось обзывать Repository). DataSource что является источником данных и представляем, что этот класс будет нужен на уровне всего приложения. В качестве источника данных буду использовать сторонее API из списка публичных API. И буду поэтапно дергать сетевые запросы: сначала через RxJava2, потом через Coroutines, причем даже не буду ничего делать в UI-слое, ведь задача просто успешно сделать сетевые запросы через разные инструменты и увидеть информацию в логе.

Меньше слов и больше дела! Поехали!

Акт нулевой: затаскиваем зависимости в проект

Студия сгенерировала пустой проект. Начинаем добавлять все нужные зависимости.

1. В build.gradle проекта:

...
dependencies {    
...   
classpath 'com.google.dagger:hilt-android-gradle-plugin:2.38.1'
...
}
...

2. В build.gradle модуля:

plugins {    
...    
id 'kotlin-kapt'    
id 'dagger.hilt.android.plugin'
}

dependencies {
...
implementation 'androidx.fragment:fragment-ktx:1.3.6' // for by viewModels()

//Rx Java2
implementation 'io.reactivex.rxjava2:rxandroid:2.1.1'
implementation 'io.reactivex.rxjava2:rxjava:2.2.9'

//Coroutines
def coroutines = "1.5.1-native-mt"
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines"
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines"

//retrofit 2
def retrofit2 = "2.9.0"
implementation "com.squareup.retrofit2:retrofit:$retrofit2"
implementation "com.squareup.retrofit2:converter-gson:$retrofit2"
implementation "com.squareup.retrofit2:adapter-rxjava2:2.4.0"

//Dagger Hilt
def daggerHilt = "2.38"
implementation "com.google.dagger:hilt-android:$daggerHilt"
kapt "com.google.dagger:hilt-compiler:$daggerHilt"

}

Акт первый: закладываем основы основ

Создаем сущность Data-класса, что будет возвращаться по запросу:

data class Fact(    
   val fact: String
)

Создаем API-интерфейс Retrofit'а для RxJava2:

interface ApiRx {    

   @GET("resources/dogs/all")    
   fun getAllFactsRx() : Single<List<Fact>>    
  
   companion object {
           
      private const val BASE_URL 
      = "https://dog-facts-api.herokuapp.com/api/v1/" 
             
      private var gson = GsonBuilder()            
         .setLenient()            
         .create()        
   
      var retrofit: Retrofit = Retrofit.Builder()            
          .baseUrl(BASE_URL)            
          .addConverterFactory(GsonConverterFactory.create(gson))            
          .addCallAdapterFactory(RxJava2CallAdapterFactory.create())            
          .build()    
   }
}

Создаем API-интерфейс Retrofit'а для Kotlin Coroutines:

interface ApiCoroutines {    

   @GET("resources/dogs/all")    
   suspend fun getAllFactsCoroutines() : List<Fact>  
  
   companion object {
           
      private const val BASE_URL 
      = "https://dog-facts-api.herokuapp.com/api/v1/" 
             
      private var gson = GsonBuilder()            
         .setLenient()            
         .create()        
   
      var retrofit: Retrofit = Retrofit.Builder()            
          .baseUrl(BASE_URL)            
          .addConverterFactory(GsonConverterFactory.create(gson))                       
          .build()    
   }
}

Акт второй: основы для Dagger'а

В первую очередь создаем класс App, помечаем аннотацией, добавляем Permission для Internet'а и регистрируем в manifest'е:

@HiltAndroidAppclass 
App : Application()

...
<uses-permission android:name="android.permission.INTERNET"/>
<application
...
android:name=".App"
</application>
...

Акт третий: создаем класс DataSource, ViewModel и дописываем коллбэк в Activity

class DataSource(    
   private val apiRx: ApiRx,    
   private val apiCoroutines: ApiCoroutines
) {
 
}

@HiltViewModel
class MainViewModel @Inject constructor(    
   private val dataSource: DataSource
) : ViewModel() {
 
   fun onCreate() {
   
   }
   
   private fun fetchDataRx() {
   
   }
   
   private fun fetchDataCoroutines() {
   
   }
}

@AndroidEntryPointclass 
MainActivity : AppCompatActivity() {    

   private val viewModel: MainViewModel by viewModels()    
   
   override fun onCreate(savedInstanceState: Bundle?) {        
       super.onCreate(savedInstanceState)        
       setContentView(R.layout.activity_main)        
       viewModel.onCreate()    
   }
}

Акт четвертый: создаем компонент приложения

@Module
@InstallIn(SingletonComponent::class)
class AppComponent {    
   @Provides    
   fun providesApiCoroutines()    
   = ApiCoroutines.retrofit.create(ApiCoroutines::class.java)   
    
   @Provides    
   fun providesApiRx()    
   = ApiRx.retrofit.create(ApiRx::class.java)    
   
   @Provides    
   @Singleton    
   fun providesDataSource(apiRx: ApiRx, apiCoroutines: ApiCoroutines)    
   = DataSource(apiRx, apiCoroutines)
}

Акт пятый: дергаем API через RXJava2

Начинаем с DataSource, добавляем туда функцию:

fun getFactsRx() : Single<List<Fact>> {    
   return apiRx.getAllFactsRx()
}

Переходим к MainViewModel, где нужно выполнить подписку на событие:

...
fun onCreate() {        
   fetchDataRx()           
}
 
@SuppressLint("CheckResult")
private fun fetchDataRx() {      
   dataSource.getFactsRx()            
      .subscribe({                
          Log.d("MainViewModelDebug", "Success: $it")            
      }, {                
          Log.d("MainViewModelDebug", "Error: $it")            
      })    
}
...

Суровые синьоры со стажем догадались, что вывелось в консоль!

MainViewModelDebug: Error: android.os.NetworkOnMainThreadException

Акт шестой: разбираемся, что пошло не так

Цитирую отличную выжимку статьи с сайта xakep.ru, которая всё объясняет:

Акт седьмой: дергаем API через RXJava, но теперь корректно

Добавляем важные строки, которых не хватало. Фактически эти две строки можно интерпретировать так: оператор создания subscribeOn приказывает выполниться методу getAllFactsRx() в отдельном IO-потоке, а оператор observeOn передает результат выполнения в Main-thread Android'а:

fun getFactsRx() : Single<List<Fact>> {    
   return apiRx.getAllFactsRx()
      .subscribeOn(Schedulers.io())
      .observeOn(AndroidSchedulers.mainThread())
}

Смотрим лог, и там пришел ответ сервера, значит всё вандефульно:

MainViewModelDebug: Success: [Fact(fact=All dogs can be traced ...

Акт восьмой: дергаем API через Coroutines

Идем в DataSource и аналогично Rx добавляем функцию:

suspend fun getFactsCoroutines() : List<Fact> {    
    return apiCoroutines.getAllFactsCoroutines()
}

И вызываем метод из ViewModel:

...
fun onCreate() {
   //fetchDataRx()        
   fetchDataCoroutines()    
}
 
private fun fetchDataCoroutines() {    
   val exceptionHandler = CoroutineExceptionHandler { _, it ->        
      Log.d("MainViewModelDebug", "Error: $it")    
   }    
   viewModelScope.launch(exceptionHandler) {        
      val resultGetFacts = dataSource.getFactsCoroutines()        
      Log.d("MainViewModelDebug", "Success: $resultGetFacts")    
   }
}
...

Смотрим лог:

MainViewModelDebug: Success: [Fact(fact=All dogs can be traced...

И здесь нужно остановиться и подумать. Что упущено относительно RxJava2?

Добавляем лог:

private fun fetchDataCoroutines() {    
...
   viewModelScope.launch(exceptionHandler) {        
      ...   
      Log.d("MainViewModelDebug", "Current thread: ${Thread.currentThread()};\nisMainThread: ${Looper.getMainLooper().thread == Thread.currentThread()}")    
   }
}

И после этого видим в консоли:

MainViewModelDebug: Current thread: Thread[main,5,main];
isMainThread: true

И вот она та самая легковесность, о какой сообщалось в самом начале заметки в описании корутин. Не смотря на то, что мы явно не давали указание о том, что запрос делать нужно не в Main-потоке, корутины с помощью подкапотной магии не вывалились в Exception.

Акт девятый: дергаем API через Coroutines, но теперь корректно

Не смотря на то, что Exception не произошел - работать с корутинами нужно правильно. И, как мы уже знаем, нужно сделать так, чтобы корутина поняла, что мы хотим выполнить операцию не через главный поток. Для удобства сделаем это, как и в случае с RxJava2, на уровне DataSource и посмотрим на результат.

Вносим изменения в DataSource в getFactsCoroutines():

suspend fun getFactsCoroutines() : List<Fact> {
    return withContext(Dispatchers.IO) {
       Log.d("MainViewModelDebug", "DataSource: Current thread: ${Thread.currentThread()};\nisMainThread: ${Looper.getMainLooper().thread == Thread.currentThread()}")        
       apiCoroutines.getAllFactsCoroutines()    
   }
}

Смотрим логи:

MainViewModelDebug: DataSource: Current thread: Thread[DefaultDispatcher-worker-1,5,main];
isMainThread: false
 
MainViewModelDebug: Success: [Fact(fact=All dogs can be traced...
 
MainViewModelDebug: Current thread: Thread[main,5,main];
isMainThread: true

Результат говорит о том, что на уровне DataSource операция выполнилась не в главном потоке, что нам как раз и нужно, а на уровне ViewModel'и мы уже оказываемся в Main-потоке.

Выводы

Что RxJava2 и что Kotlin Coroutines - две мощных библиотеки, позволяющие выполнять асинхронные операции, но с совершенно разными подходами по стилю написания. Оба инструмента помогают Android-разработчикам не грузить жизненноважный Main-thread, что занят и без того нелегкой отрисовкой UI. Kotlin Coroutines все больше набирает обороты и завоевывает новых сторонников из числа разработчиков в свои ряды, тем более на ее стороне легковесность, что позволила в данном примере не получить ошибку при выполнении сетевого запроса, как было в случае с RxJava2.

При всем при этом нельзя сказать, что век RxJava подошел к концу из-за атаки Корутин и завоевание почти 100% рынка проектов не за горами. У данной библиотеки останется немалое количество поклонников, да и самое главное, что всем нам долго никуда не деться от легаси-кода. Кроме того, на Ютубе и в подкастах, но не помню где точно - слышал мнение, что люди поработали с корутинами, но подход RxJava остался больше по душе.

Дата запуска блога: 22 июля 2021

В данной заметке предлагаю подборку каналов и подкастов по мобильной разработке. Каналы будут упорядочены по порядку убывания подписчиков. Начну с подкастов. Кроме этого, уже есть заметка со списком телеграм-каналов по мобильной разработке.

Подкасты

1. Mobile People Talks

Основное описание подкаста: Mobile People Talks — подкаст про мобильную разработку. И все остальное. Так что если вы не мобильный разработчик, не спешите закрывать страничку – разные выпуски имеют разные уровни погружения и будут интересны разработчикам с разным стажем и степенью мобильности). Хочется надеяться, что подкаст станет регулярным ресурсом, который поможет вам создавать лучшие приложения и продвигать их более эффективно, так как всегда есть место для роста экспертизы в мобильной разработке, учитывая сложный характер этой отрасли.

Ссылки подкасты: apple, google и soundCloud

2. Android story

Основное описание подкаста: Двое андроидщиков, двое Вов и иногда два разных мнения. Каждый подкаст мы обсуждаем новые статьи и просто новинки в мире андроида и программирования. Делимся мнениями, опытом и иногда пытаемся несмешно шутить.

Подкаст, соответственно, ведут, аккаунты в твиттере: Володимир Стельмащук и Вова.

Ссылка на страницу с доступными площадками подкастов

YouTube-канал

YouTube

1. Start Android

Основное писание канала: Обучающие видео-уроки по разработке приложений и игр для Android. Подпишитесь на наш канал, чтобы не пропустить новые уроки - обновление еженедельно! Мы поможем любому новичку стать продвинутым разработчиком андроид-приложений!

YouTube-канал

2. Mobile Developer

Основное писание канала: Всем привет! Меня зовут Алексей. Если ты когда-нибудь задумывался о том, чтобы делать крутые приложения для телефонов, хотел сделать свой инстаграмм или фейсбук, то тебе сюда. Свежие видео, новости из мира разработки, интервью и многое другое здесь - на канале Mobile Developer

Twitter автора

Telegram-канал

YouTube-канал

3. Android Broadcast. Все об Андроид разработке

Основное писание канала: Всё о современной разработке под Android от экспертов индустрии На канале вы найдёте: - Разбор свежих новинок из мира Android и мобильной разработки - Лучшие практики Android разработки - Интервью с ведущими экспертами индустрии - Тестовые собеседования в прямом эфире с разбором

Twitter проекта

Twitter автора

Telegram-канал

YouTube-канал

4. Mobius

Основное писание канала: На этом канале публикуются видео с Mobius — конференции для разработчиков под Android и iOS. Наверняка вы уже бывали на конференциях по мобильной разработке и знаете, что это такое... Теперь представьте, что из них аккуратно вырезали всю маркетинговую лапшу, «продающие» доклады и полностью сосредоточились на хардкоре и чистой практике. Вы получите Mobius — главную независимую конференцию по мобильной разработке в России!

Twitter проекта

Telegram-чат

YouTube-канал

5. Mobile Channel

Основное писание канала: Контент Mobile Channel посвящен разработке мобильных приложений: технологиям Android и iOS, кросс-платформенной разработке, архитектуре мобильных приложений, клиент-серверному взаимодействию и процессам разработки и тестирования. Здесь мы публикуем материалы с профессиональной конференции для мобильных разработчиков AppsConf (http://appsconf.ru/).

Twitter проекта

YouTube-канал

6. Mobile People

Основное писание канала: -

Telegram-канал

YouTube-канал

7. Android Guards

Основное писание канала: Официальный канал сообщества Android Guards.

Telegram-канал

YouTube-канал

8. Android Live

Основное писание канала: Всем привет. На данном канале вы найдёте самые актуальные новости из мира Android-разработки. Как подготавливаться к собеседованиям? Какие технологии изучать, чтобы оставаться в тренде? Это и многое другое можно узнать на канале Android Live.

Telegram-канал

YouTube-канал

Процесс - совокупность кода и данных, разделяющих общее виртуальное адресное пространство. Процессы изолированны друг от друга, поэтому прямой доступ к памяти чужого процесса невозможен (взаимодействие может осуществляться только с помощью специальных средств). Для каждого процесса ОС создает "виртуальное адресное пространство", к которому процесс имеет прямой доступ. Это пространство принадлежит процессу, содержит только его данные и находится в полном его распоряжении. Операционная система отвечает за то, как виртуальное пространство процессов проецируется на физическую память. Резюмируя, процесс - понятие на уровне операционной системы.

Поток - использует выделенные для процесса ресурсы и является способом выполнения процесса. Главный поток выполняет main-функцию и завершается. При выполнении главного потока могут порождаться дополнительные потоки. Потоки одного процесса могут обмениваться данными между собой.

Поток-демон - поток работающий в фоновом режиме. Если все потоки не демоны закончили свою работу, то программа завершается, не смотря на работу потоков-демонов.

Монитор - дополнительная надстройка над mutex'ом, в Java реализуется с помощью ключевого слова synchronized.

Семафор - средство для синхронизации доступа к какому-либо ресурсу. Особенность в том, что при создании механизма синхронизации он использует считчик, который указывает сколько потоков одновременно могут получать доступ к общему ресурсу. Семафоры в Java представлены специальным классом Semaphore.

Mutex - специальный объект для синхронизации потоков, прикреплен к каждому объекту Java, поэтому есть у всех экземпляров класса. Mutex - одноместный семафор.

*ЗАМЕТКА НА СТАДИИ РАЗРАБОТКИ*

Общие определения

Сетевой протокол - стандарт передачи и обработки информации. Кроме сетевых протоколов бывают и почтовые протоколы (SMTP, POP, IMAP и др), протоколы передачи файлов (FTP) и другие.

IP и TCP - два разных протокола, которые связывают друг с другом. Часто употребляются в комбинации сразу нескольких протоколов, каждый из которых выполняет операции на своем уровне.

TCP - отвечает за создание интернет-пакетов и их обратную сборку в нужном порядке в месте получения, а так же проверяет целостность информации.

IP - используется для доставки по нужному адресу, каждый отправленный пакет содержит адрес доставки, отвечает за маршрутизацию пакета к указанному компьютеру.

UDP - для передачи малых кусков информации, не гарантирует доставку пакетов в нужной последовательности и не дублирует передачу утерянных пакетов, но выше скорость передачи и меньше потребление системных ресурсов.

Socket - это программный интерфейс. Это абстрактное понятие, которое, в большинстве случаев, используется для коммуникации программ в сети (но не только).

WebSocket - это протокол (какой-либо заранее оговоренный порядок) обмена данными (как, например, http, ftp, ssl и т.д.). Этот протокол идет поверх (передается посредством) протокола TCP.

SSL (Secure Sockets Layer) - тип цифровой безопасности, которая позволяет зашифровать связь между веб-сайтом и веб-браузером.

TLS (Transport Layer Security) - обеспечивает конфиденциальность данных так же, как и SSL.

SSL/TLS handshake - ряд шагов, благодаря которому клиент и сервер инцируют связб, проверяют друг друга и начинают передачу данных через туннель SSL/TLS.

REST (REpresentational State Transfer) - термин, который первоначально введен Роем Филдингом (Roy Fielding), кто являлся одним из создателей протокола HTTP. Отличительной особенностью сервисов REST является то, что они позволяют наилучшим образом использовать протокол HTTP.

GraphQL - синтаксис, который описывает как запрашивать данные, и, в основном, используется клиентом для загрузки данных с сервера. Один из подходов проектирования API, альтернатива REST.

HTTP

HTTP-протокол - пользователь иницирует соединение к серверу для запроса информации, а сервер ожидает соединение для получения запроса, обрабатывает запрос и возвращает обратно сообщение с результатом. Работает совместно с протоколом TCP.

HTTPS - безопасное расширение HTTP устанавливающие и настраивающие SSL/TLS-сертификат

Метод HTTP — указывает на основную операцию над ресурсом. Методы бывают (подробнее о методах позже, после идемпотентности):

• GET
• POST
• HEAD
• OPTIONS
• PUT
• PATCH
• DELETE
• TRACE
• CONNECT

Коды состояния бывают:

• 1xx - Informational
• 2xx - Success
• 3xx - Redirection
• 4xx - Client error
• 5xx - Server error

Структура HTTP-сообщения

1. Стартовая строка (Starting line) определяет тип сообщения

• Для запроса: Метод URI HTTP/Версия
• Для ответа: HTTP/Версия Код состояние Пояснение

2. Заголовки (Headers) - тело сообщения, параметры передачи и прочее. Виды заголовком в порядке рекомендованной очередности посыла:

• General headers - могут включаться в любое сообщение клиента и сервера;
• Request headers - используются только в запросах клиента;
• Response headers - только для ответов от сервера;
• Entity headers - сопровождают каждую сущность сообщения.

3. Тело сообщения (Message Body) - отделяется от заголовка пустой строкой, это непосредственно данные сообщения

Идемпотентность, безопасность и методы HTTP

Идемпотентность - свойство объекта или операции при повторном ее применении к объекту давать тот же результат, что и при первом. То есть идемпотентная операция - действие, многократное повторение которого эквивалетно однократному.

Безопасный HTTP-метод - метод не меняющий состояние сервера.

Идемпотентный и небезопасный метод - сколько бы не повторялся запрос, только первый изменит состояние системы, а остальные состояние системы не меняют

Идемпотентный и безопасный метод - многократное повторение запроса вернет одно и то же состояние системы

Самое использование HTTP-методов при проектировании Rest-API - НЕ ГАРАНТИРУЕТ идемпотентность, разработчик легко может ее нарушить.

Теперь конкретно по основным характеристикам методов:

1. CONNECT - запускает двустороннюю связь с запрошенным ресурсом, можно использовать для открытия туннеля

2. HEAD - запрашивает заголовки. Такой запрос может быть выполнен перед загрузкой большого ресурса, например, для экономии пропускной способности.

3. TRACE - выполняет проверку обратной связи по пути к целевому ресурсу, предоставляя полезный механизм отладки.

4. OPTIONS -используется для описания параметров соединения с целевым ресурсом.

5. GET - запрашивает представление указанного ресурса, запросы должны только получать данные. ВАЖНО: GET-запрос имеет ограниченную длину

6. POST - предназначен для отправки данных на сервер. Тип тела запроса указывается в заголовке Content-type. ВАЖНО: в отличие от GET - метод POST не имеет ограничений по длине и соответственно не вызовет ошибку и условно не кэшируется.

7. PUT - создаёт новый ресурс или заменяет представление целевого ресурса, данными представленными в теле запроса. ВАЖНО: PUT в отличие от POST является идемпотентным

8. PATCH - имеет поведение типичного update-метода в CRUD'ах. ВАЖНО: PATCHможет как быть идемпотентным, так и нет, в отличие от PUT, который всегда идемпотентен.

9. DELETE - удаляет указанный ресурс. ВАЖНО: корректно реализованный DELETE является идемпотентным.

В основном материал брался:

https://ru.wikipedia.org/wiki/HTTP

https://developer.mozilla.org/ru/docs/Web/HTTP/Methods/CONNECT

1. Процессы и потоки

2. Сеть

*ЗАМЕТКА НА СТАДИИ РАЗРАБОТКИ*

На днях вышел Jetpack Compose, поэтому решил ностальгически пройтись по тем способам работы с View-слоем, какие были популярны у Android-разработчиков ранее, потому что работа с XML на View-слое уходит в прошлое.

0. Способы "из коробки"

0.1 findViewById

findViewById - нативный вариант работы с кнопкой. Итак, у нас есть в XML какая-то кнопка. Чтобы работать с ней из Java или Kotlin кода - нужно в XML задать ей ID:

 ...
 <Button
    android:id="@+id/button"
    android:text="Button"
    ... />
...

При компиляции приложения aapt создаст класс R, который содержит ресурс IDs для всех ресурсов в каталоге res.

Как правило, с кнопкой нужно работать не в одном каком-то методе жизненного цикла, но и обращаться к ней из класса бизнес-логики, то есть Presenter'а или ViewModel'и и нужно, чтобы кнопка была объявлена полем, заодно повесим слушать кликов что примерно будет выглядеть так:

public class MainActivity extends AppCompatActivity {
  
   Button button;

   @Override
   protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.nd_activity_main);
      button = (Button) findViewById(R.id.button);
      button.setOnClickListener(new View.OnClickListener() {
         @Override
         public void onClick(View v) {
            onClickButtons(v)
         }
      });
   }
   
   void onClickButtons(View view) {
      Toast.makeText(
      this, 
      "Здесь обработка клика", 
      Toast.LENGTH_SHORT).show();
   }
}

0.2 onClick в XML

Этот добавился несколько позже и позволяет задать вызов метода из XML-разметки напрямую. И данный способ не работает во фрагментах, только в Activity. Выглядит это так:

 ...
 <Button
    android:id="@+id/button"
    android:text="Button"
    android:onClick="onClickButtons"
    ... />
 ...

public class MainActivity extends AppCompatActivity {

   @Override
   protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
   }
   
   void onClickButtons(View view) {
      Toast.makeText(
      this, 
      "Здесь обработка клика", 
      Toast.LENGTH_SHORT).show();
   }
}

0.3 OnClickListener

Здесь нужно было просто реализовать интерфейс в Activity или Fragment'е, что на в итоге приводит к такому:

public class MainActivity extends AppCompatActivity 
implements View.OnClickListener {
 
   Button button;

   @Override
   protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.nd_activity_main);
      button = (Button) findViewById(R.id.button);
      button.setOnClickListener(this);
   }
   
   @Override
   public void onClick(View v) {
      onClickButtons()
   }
   
   void onClickButtons(View view) {
      Toast.makeText(
      this, 
      "Здесь обработка клика", 
      Toast.LENGTH_SHORT).show();
   }
}

2. ButterKnife

Разработчики - люди ленивые. И им изначально казалось, что совершается слишком много телодвижений для начала работы со виджетом. И большую популярность обрела библиотека ButterKnife, которую написал Jake Wharton. Первая версия библиотеки вышла 5 марта 2013 года. Как выглядел тот же самый, но чуть расширенный код относительно того, что выше (пример позволяет обрабатывать клик двух кнопок):

public class MainActivity extends AppCompatActivity {
  
   @BindView(R.id.button)
   Button button;
   
   @BindView(R.id.button2)
   Button button2;

   @Override
   protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);
      ButterKnife.bind(this);
   }
   
   @OnClick({R.id.button, R.id.button2})
   void onClickButtons(View view) {
      switch (view.getId()) {
         case R.id.button:
         Toast.makeText(this,
         "Здесь обработка клика button",
         Toast.LENGTH_SHORT).show();
         break;
         
         case R.id.button2:
         Toast.makeText(
         this, 
         "Здесь обработка клика button2",
         Toast.LENGTH_SHORT).show();
         break;
      }
   }
}

3. DataBinding

В 2015 году уже были release-candidate версии этого решения от Google. Точную дату выхода релизной версии не помню, но по-моему активно заговорили о таком решении после Google IO 2017. Нельзя сказать, что оно было очень популярным, так как суть работы происходит через кодогенерацию, что увеличивает время сборки проектов. Это плохо тем, что в сегодняшние дни очень крупные компании стараются модуляризировать свою архитектуру, чтобы при каких-либо изменениях пересобиралась как можно меньшая часть проекта и соответственно уменьшалось время сборки, хотя они даже не используют DataBinding. Сама суть DataBindinga в связывании напрямую xml-кода и ViewModel-класса бизнес-логики, что позволяло даже писать Java-код в XML, то есть у нас напрямую вызывалась функция класса ViewModel'и через лямбда-выражение:

...
<layout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto">
    <data>
    <variable
    name="viewModel"
    type="com.example.project.MainViewModel" />
    ...
 <Button
    android:id="@+id/button"
    android:text="Button"
    android:onClick="@{() -> viewModel.onClickButtons()}"
    ... />
...

4. Kotlin Synthetyc

Если верить тому, как мельком я посмотрел доступные GitHub-репозитории, то разработка Kotlin Synthetyc началась примерно примерно в середине 2016 года. Но данный способ работы со View хоть и был немногословным, но быстро стал Deprecated в версии Kotlin 1.4.20, что датирована 5 мая 2021 года. Принцип работы основан на генерации кода плагином, который автоматически подтягивал нужный import.

 
import kotlinx.android.synthetic.main.activity_main.*
 
class MainActivity: AppCompatActivity() {

   override fun onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      setContentView(R.layout.nd_activity_main)
      button.setOnClickListener {
         onClickButtons()
      }
   }
   
   fun onClickButtons() {
      Toast.makeText(
      this, 
      "Здесь обработка клика", 
      Toast.LENGTH_SHORT).show();
   }
}

5. ViewBinding

В феврале 2020 года с выходом Android Gradle plugin 3.6.0 - разработчики смогли подключать ViewBinding для работы со View в своих проектах. Данный метод тоже основан на генерации binding-классов, но ликвидирован недостаток DataBindinga в виде очень долгого времени сборки, ну и соответственно нет возможности писать код в XML.

class MainActivity: AppCompatActivity() {

   private lateinit var binding: ActivityMainBinding
   
   override fun onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      binding = ActivityMainBinding.inflate(layoutInflater)
      setContentView(binding.root)
      binding.button.setOnClickListener {
         onClickButtons()
      }
   }
   
   fun onClickButtons() {
      Toast.makeText(
      this, 
      "Здесь обработка клика", 
      Toast.LENGTH_SHORT).show();
   }
}

class MainActivity : ComponentActivity() {

   override fun onCreate(savedInstanceState: Bundle?) {
       super.onCreate(savedInstanceState)    
       setContent {
               Example("Android")    
       }
   }
}
    
@Composable 
fun Example(name: String) {
   val ctx = LocalContext.current 
   Button(onClick = {

      onClickButtons(ctx,"Здесь обработка клика")
      
   }, colors = ButtonDefaults.textButtonColors( 
      backgroundColor = Color.Red 
   )) { 
      Text(text = name) 
   } 
}


fun onClickButtons(ctx: Context, msg: String) {    
   Toast.makeText(ctx, msg, Toast.LENGTH_SHORT).show()
}   

Мобильному разработчику важно держать руку на пульсе. На мой взгляд в этом сильно помогает телеграм и несколько крутейших каналов, по каким удобно держаться в тренде. Какие-то каналы буду вносить в список без подводки. Не от того, что они хуже, а от того, что во многом каналы носят информационный характер. Поехали!

1. Мобильная разработка

1.1 Mobile Insights by AppTractor

Канал с дайджестами статей по мобильной разработке. Ссылки как на русскоязычные, так и на англоязычные материалы.

1.2 Записки разработчицы

Здесь и про IOS, и про Android, и про мультиплатформу от мобильной разработчицы и Google Developer Expert в одном лице.

1.3 Мобильный разработчик

Ранее на канале практиковались уроки по Kotlin под Android, но теперь упор на Flutter.

1.4 Мобильная разработка

1.5 Библиотека мобильного разработчика

1.6 Oh, my Flutter

2. Android

2.1 Android Broadcast

Слишком крутой русскоязычный канал, что даже не хочется писать подводку. Как обсуждения чего-то нового, примеры кода, так и собеседования на разные уровни. Здесь невозможно не найти для себя что-то полезное и интересное.

2.2 StartAndroid

Канал от создателя одноименного сайта. Сам сайт для изучения основ разработки под андроид, наверняка уже с ним знакомы, кроме того, там отличные уникальные платные курсы, а канал содержит море полезных материалов и часто обновляется.

2.3 Android books channel

Канал с книгами. Скорее всего, как правило, обучение будет ограничиваться статьями, но на каждое правило - всегда есть свое исключение!

2.4 EasyCode

Канал со стримами видео, лайвкодингом и подобной интересной кучей плюшек.

2.5 Android Good Reads

2.6 Android Live

2.7 Android Guards Today

2.8 Android Дичь

2.9 Android в Лицах

2.10 paradiSEcurity

2.11 Mobile Native

3. IOS

3.1 iOS Good Reads

3.2 Dodo Pizza Mobile

3.3 iOS Elite Talks

3.4 iOS.Devs Camp

3.5 iOS.Events

4. Interview

4.1 Android Interview Review

Давно не обновляется, но полезной информации много[0].

4.2 IT Interview Review

Давно не обновляется, но полезной информации много[1].

4.3 Java задачи с собеседований

Довольно активный канал, где много тестов со скриншотами кода, где предлагается выбрать верный ответ.

Предисловие

Каждый новичок, что пытается писать под Android, рано или поздно сталкивается с моментом, когда наступает понимание, что писать весь код в одной Activity или даже Fragment'е неудобно. И в этой заметке хочу рассмотреть некоторые вопросы про архитектуру. Думаю, что каждый слышал про то, какие в принципе бывают архитектурные паттерны, но на всякий случай начну с их перечисления:

• MVC
• MVP (VIPER и другие производные от MVP, в том числе PIDOR)
• MVVM
• MVI

Цель самой архитектуры - написание кода, который легче поддерживать. И тут отмечу важный момент. Стадии, какие прошел я и какие, как мне кажется, проходят почти все разработчики, что смотрят в сторону архитектурных решений:

1. Ужас от написанного своего приложения без архитектуры.
2. Первые попытки написания кода на архитектурном паттерне. Этот этап характерен ощущением, что код стал более легкоподдерживаемым, но при этом самого кода становится больше. То есть, плюс к читабельности, но минус ко времени написания фичей.
3. Грамотное выделение абстракций и сокращение boilerplate-кода.

С первой стадией все понятно. А вот со второй и третьей сложнее. Вторая стадия может длиться довольно долго. А третья стадия - высшая точка понимания, потому что наступает момент, когда хорошо изучены тонкости языка и код начинает быть более автоматизированным, абстрагируется все больше удобных вещей в Base-классах.

Разработчик сталкивается с разными проектами, разными нюансами и разным стеком технологий. И архитектуры, что являлась бы серебряной пулей, попросту не существует, иначе все бы разработчики писали идентичный код по сэмплу, например, от Google.

Теперь рассмотрим подробнее каждый шаблон и попробую изложить свое видение, как лучше их понять.

MVC

Это самый простой шаблон, где основная бизнес-логика содержится в классе Model. Мне кажется, что нет смысла долго останавливаться на данном шаблоне даже новичку и на мой взгляд погружение в архитектуру вполне нормально начинать с MVP. Но если все таки есть желание попробовать руками MVC, то рекомендую книгу "Android. Программирование для профессионалов". В новых изданиях внимания этому шаблону уделяется вроде бы меньше, смотрел мельком, поэтому желательно рассмотреть этот вариант, если уж собрались, на основе более старых изданий, например, третьего.

MVP

MVP - настоящая взрослая архитектура. Мне в свое время понадобилось много времени, чтобы вообще понять, как в Android построить MVP. Главной ошибкой было то, что я пытался читать статьи, вникать и понимать, а не писать код. А построение архитектуры - это практический навык. Есть уже написанная шикарная статья о том, как построить MVP-архитектуру: MVP в Android для самых маленьких.

В чем взрослость и преимущества MVP: выраженный класс Presenter для бизнес-логики, который управляет, как View, так и Model. То есть по итогу должен получиться мегакласс, где содержится логика всего приложения и который каждому слою приказывает, что тому делать конкретно и передает необходимые для этого данные. То есть Presenter не должен содержать get-функций с возвращаемым типом. И можно прекрасно понять, что происходит на экране, читая только лишь имплиментацию Presenter'а. Схематично конструктор Presenter'а может выглядеть так:

class MainPresenter(
   val mainView: MainContract.View, 
   val mainModel: MainContract.Model
) : MainContract.Presenter { ... }

MVVM

Чуть более сложный для понимания шаблон, поэтому настоятельно рекомендую попробовать в первую очередь MVP. Забегу вперед и мотивирую: если освоить MVVM-шаблон, то по сути нужно будет дальше приложить минимальное усилие, чтоб познать MVI и собрать в голове полную копилку знаний об основных архитектурных паттернах проектирования Android-приложений. Первое и главное отличие в названиях слоев бизнес-логики: в MVP и его производных она хранится в Presenter, тогда как в MVVM эту роль исполняет ViewModel. Во вторых, это способ взаимодействия View-слоя и ViewModel. Это осложнено тем, что ViewModel не знает явно о View-слое, но при этом им управляет. Как такое может быть? Об этом чуть дальше.

Прежде чем начать разбираться с MVVM нужно обговорить более детально о видах взаимодействия View и ViewModel и вот какие они бывают:

1. Прослушивание событий во ViewModel, происходящие во VIew, примеры: нажатие кнопки, изменение текста в EditText.
2. Изменения во ViewModel, которые после configuration changes должны подтягиваться актуальные значения, примеры: пришли данные с сервера и нужно показать/скрыть виджет на View-слое, изменить текст в TextView.
3. Исполнение View-слоем однократных событий по приказу ViewModel'и, пример: показать диалог, показать тост или перейти на другой фрагмент/экран.

Схематично ViewModel выглядит так:

class MainViewModel(
   val mainModel: MainContract.Model
) : ViewModel(), MainContract.ViewModel { ... }

Понятно, что связь View с ViewModel никуда не девается, не смотря на отсутствие в конструкторе View, она лишь усложняется и варианты управления View-слоем ViewModel'ю есть такие:

1. связывание XML-кода и ViewModel'и через DataBinding;
2. реализация шаблона проектирования Observer для отправки событий из ViewModel во View для изменения состояний отдельного View-widget'а или даже целиком View-слоя.

Далее немного более детально о том, как в каждом из способов разруливаются вышеназванные виды взаимодействия.

MVVM через DataBinding

DataBinding - библиотека, основанная на кодогенерации и содержит в себе Observable-классы, которые лежат во ViewModel и связываются напрямую с XML-разметкой. Подробнее о работе с событиями:

1. Прослушивание событий происходит через реализацию функций напрямую в XML-разметке, пример в виде прослушивания изменений в EditText-виджете:

android:onTextChanged =
"@{(text, start, before, count) -> viewModel.onUsernameTextChanged(text)}"

2. Изменения во ViewModel происходит через вышеназванные Observable-классы-обертки и подобным образом связываются с XML. Пример: мы сделали внутри viewModel поле:

 val name = new ObservableField<String>()

Тогда связывание поля с XML будет выглядеть так:

 android:text="@={viewModel.name}"

3. Исполнение View-слоем однократных событий можно реализовать через предложенный Google класс - SingleLiveEvent. Пользоваться им нужно, как обычной LiveData. Класс можно скопипастить в свой проект. Есть статья, где наглядно показано, как этим всем пользоваться.

MVVM через шаблон-Observer

Для такой реализации MVVM нужно будет использовать LiveData или Kotlin Flow, что как раз и реализуют принцип шаблона Observer, а LiveData еще и согласована с жизненным циклом нашего View. Подробнее о работе с событиями:

1. Прослушивание событий происходит банально через колбэки. View знает явно и хранит в себе ссылку на ViewModel, что как раз нам позволяет использовать её методы.

2. Изменения во ViewModel происходит через MutableLiveData или MutableStateFlow. У нас всегда на View-слое будет актуальное значение нашего конкретного виджета или всего View-слоя.

3. Исполнение View-слоем однократных событий можно реализовать, как в DataBinding'е через SingleLiveEvent.

Мини-резюме по MVVM

При правильном и опытном подходе MVVM упрощает процесс написания тест-кода (в следствие меньшего количество явных связей) и по сути может являться чуть менее многословной архитектурой, чем MVP с ее производными. Из этих двух подходов рекомендую реализацию через шаблон-Observer, по двум причинам:

1. В DataBinding кодогенерация, что дает ощутимое замедление времени сборки проекта.
2. Вчера Google выкатили релизную версию JetPack Compose, что делает подход с DataBinding'ом еще менее актуальным, ведь наступает эра отказа от XML в пользу кодовой верстки экранов через Kotlin.

Ссылки на примеры с реализацией не прикладываю. В интернете туториалов много на каждый подвид MVVM, поэтому что-то конкретное рекомендовать не буду, так как есть выбор и куча альтернатив.

MVI

Думаю по тексту было заметно, что глобальное отличие MVP от MVVM по сути лишь во взаимодействии между View и ViewModel-Presenter'ом. Так вот, мотивировал выше не зря. MVVM еще проще трансформируется в MVI, чем MVP в MVVM. Когда я только пытался изучать MVI - было мало статей и по ним не получалось понять основной принцип. И когда в очередной раз я на своем pet-проекте писал, как я думал, MVVM, то в один прекрасный момент до меня дошло, что это как раз получилась MVI, такой вот каламбур.

Идея MVI построена вокруг более пристального контроля View-слоя. У нас есть некий ViewState data-класс, который хранит в себе кучу полей, что контролируют состояние View. И из ViewModel'и напрямую во View летит через Observer-шаблон только этот data-class. Кроме ViewState может быть еще Action-сущность на уровне ViewModel'и. Для наглядности приведу пример: мы загружаем данные с сервера. И в зависимости от того, какие данные пришли, например, пустой список для отображения на нашем экране или нет, мы выбираем один из определенных class'ов sealed-класса Action'a, вызываем функцию sendAction(Action.NotEmptyList), далее этот метод у себя под капотом вызывает onReduceState(Action.NotEmptyList). И функция onReduceState имеет возвращаемый тип ViewState, где как раз определены все наши ViewState'ы через функцию копирования copy() у Data-классов.

Текстом это тяжело передать, чтоб было понятно, поэтому, как заявил в начале заметки - нужно практиковаться. И есть отличный легкий пример с реализацией подобной архитектуры без хитрющих абстракций, который вполне можно понять, поэтому оставляю ссылки. Проект многомодульный, и дабы новички не терялись, оставлю ссылки так: пример одного экрана, наглядная абстракция BaseViewModel.