Введение
На прошлой лекции мы рассмотрели принципы Clean Architecture от Роберта Мартина, а также их адаптацию для разработки приложений под Android, и пришли к выводу, что эти принципы позволяют решить все озвученные задачи при построении архитектуры приложения: они делают код модульным, тестируемым и легко читаемым.
Но как говорится, нет предела совершенству, и такую архитектуру можно и нужно улучшать. Какие недостатки есть у архитектуры, предложенной ранее? Во-первых, даже для достаточно простых экранов мы получаем слишком много разных классов (View, Presenter, UseCase, Repository, Navigator и другие). Здесь нужно исходить из задачи – если вам нужно реализовать простой экран с парой текстов и кнопкой, не нужно реализовывать для него все эти принципы. Во-вторых, мы видели, что слой бизнес-логики практически не содержит кода. Да, конечно, мы писали достаточно простое приложение, в котором не может быть много логики, но разве это не самый распространенный случай на сегодняшний день? Сегодня существует правильная тенденция, когда вся бизнес-логика переносится на сторону сервера. Эта тенденция является правильной потому, что на стороне сервера логика описывается только один раз (а не для всех мобильных платформ по отдельности), а также потому, что на стороне сервера логику можно изменить гораздо более оперативно.
Поэтому вполне возможно, что мы можем убрать слой бизнес-логики. А ту небольшую бизнес-логику, которая останется в приложении, можно переместить в другой управляющий элемент, к примеру, в Presenter. Таким образом мы избавимся от лишнего слоя, лишних взаимодействий и лишних моделей, упростив в конечном случае реализацию отдельных экранов.
При этом мы видели, что слой данных работает очень хорошо и скрывает от слоя представления детали работы с серверными запросами и кэшированием. Поэтому в нем нет недостатков, и его можно оставить нетронутым (разве что необязательно переносить его в отдельный модуль, так как сейчас правило зависимостей упрощается).
Слой представления, разумеется, никуда исчезнуть не может, так как именно на нем происходит взаимодействие с пользователем. Но для работы приложения нужно обеспечить взаимодействие между интерфейсом и слоем данных. Эту работу возьмет на себя делегат для слоя представления. Этим делегатом может быть элемент, управляющий логикой работы в любом паттерне: MVC, MVP, MVVM.
Поэтому итоговая схема может выглядеть следующим образом:
При этом мы не потеряем возможность тестирования и сохраним модульность архитектуры приложения. Более того, теперь у нас есть один основной элемент, который содержит всю логику конкретного экрана – это делегат (Controller / Presenter / ViewModel). И поэтому для упрощения почти всегда достаточно тестировать только его.
Поскольку работа делегата полностью зависит от того, какие данные он получает от сервера, для тестирования делегата достаточно подменять реализацию репозитория.
Это общее теоретическое изложение, которое нужно для того, чтобы понять идею – упростить архитектуру в соответствии с наиболее часто встречающимися задачами. Но чтобы работать с такой архитектурой, нам потребуется лучше понять суть различных паттернов уровня представления и детальнее разобрать паттерн MVP.
Введение в сериализацию
определение
Сериализация заключается в преобразовании информации о состоянии объекта вФорма хранения или передачипроцесс. Во время сериализации объект записывает свое текущее состояние во временное или постоянное хранилище. Позже вы можете воссоздать объект, прочитав или десериализовав состояние объекта из области хранения.
использование
Главная цель:
- Сериализация записывает объекты в виде потоков байтов и сохраняет их в памяти, файлах и базах данных.
- Передача сериализованных объектов другим клиентам по сети
В разработке для Android объекты данных Intent, Bundle и Binder должны быть сериализованы. пример:
Есть два способа сериализации в Android
- Сериализуемый интерфейс
- Parcelable интерфейс
Межпроцессные взаимодействия
Каждое приложение Android работает в собственном процессе с уникальным идентификатором процесса. Когда вы запускаете приложение, система Android генерирует процесс и выполняет основное действие в основном потоке. Плюс этого в том, что приложение живет в изолированной среде, и другие приложения не могут его прервать.
Исходя из этого, Android позволяет запускать компоненты в другом процессе, который не используется для запуска приложения. Для этого вам нужно использовать тег процесса внутри AndroidManifest.xml. У процесса может быть случайное имя, например myNewProcess.
Многопроцессорность повышает безопасность вашего приложения и улучшает управление памятью. Однако, если вы его используете, вам нужно найти способ взаимодействия между различными процессами.
Вам нужно включить только один программный интерфейс — IBinder, но Android предоставляет три способа его определения:
- Использование AIDL
Первый способ мы уже рассмотрели в этом туториале, но не стесняйтесь изучить и другие.
StartManager 1.4 — Развитие альтернативного стартера Промо
Очередная редакция альтернативного стартера, являющегося продолжением StartManager 1.3. Спасибо всем, кто присылал свои замечания и пожелания, и тем, кто перечислял финансы на поддержку проекта. С учетом накопленного опыта, стартер был достаточно сильно переработан в плане архитектуры. В основном сделан упор на масштабируемость, для способности программы быстро адаптироваться к расширению предъявляемых требований (т.к. довольно часто просят добавить ту или иную хотелку). Было пересмотрено внешнее оформление, переработан существующий и добавлен новый функционал. В общем можно сказать, что стартер эволюционировал, по сравнению с предыдущей редакцией. Однако пока не всё реализовано, что планировалось, поэтому еще есть куда развиваться в плане функциональности.
1 стартмани
23.04.2014
147140
1778
Alexoniq
1575
Создание новой активити
Первым делом следует создать новый класс, который должен наследоваться от класса и переопределять метод .
Таким образом мы получим пустое окно. Чтобы в этом окне хоть что-то отображалось нужно создать разметку — layout. Добавляется она в ресурсах (папка res) в подпапке layout.
Теперь эту разметку нужно “подключить” к активити в методе .
Ну и наконец, чтобы приложение могло использовать только что созданную активити её нужно объявить в манифесте приложения при помощи элемента .
Все вышеперечисленные шаги можно сократить до одного благодаря наличию в Android Studio стандартных шаблонов: правой кнопкой мыши вызываем контекстное меню и в нём выбираем New -> Activity -> “выбрать нужный шаблон”.
После этого класс, разметка, а также запись в манифесте будут добавлены автоматически.
Serializable
Serializable is a markable interface or we can call as an empty interface. It doesn’t have any pre-implemented methods. Serializable is going to convert an object to byte stream. So the user can pass the data between one activity to another activity. The main advantage of serializable is the creation and passing data is very easy but it is a slow process compare to parcelable.
A simple example of serializable as shown below –
import java.io.Serializable;
class serializableObject implements Serializable {
String name;
public serializableObject(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
Parcelable
Parcel able is faster than serializable. Parcel able is going to convert object to byte stream and pass the data between two activities. Writing parcel able code is little bit complex compare to serialization. It doesn’t create more temp objects while passing the data between two activities.
A simple example of Parcel able as shown below –
import android.os.Parcel;
import android.os.Parcelable;
class parcleObject implements Parcelable {
private String name;
protected parcleObject(Parcel in) {
this.name = in.readString();
}
public parcleObject(String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public static final Creator<parcleObject> CREATOR = new Creator<parcleObject>() {
@Override
public parcleObject createFromParcel(Parcel in) {
return new parcleObject(in);
}
@Override
public parcleObject[] newArray(int size) {
return new parcleObject;
}
};
@Override
public int describeContents() {
return 0;
}
@Override
public void writeToParcel(Parcel dest, int flags) {
dest.writeString(this.name);
}
}
Vrundesha Joshi
Published on 10-Apr-2019 09:45:57
- Related Questions & Answers
- Difference between Parcel able and Serializable in android
- What is the difference between Externalizable and Serializable interfaces in Java?
- How to pass data between activities with android Serializable
- Difference between Java and Kotlin in Android with Examples
- What is difference between gravity and layout_gravity on Android?
- What is difference between onCreate() and onStart() on Android?
- What is difference between FillParent and wrap content in android?
- PHP Serializable interface
- Difference between == and === operator in JavaScript
- Difference between !== and ==! operator in PHP
- Difference between . and : in Lua programming
- Difference between JCoClient and JCoDestination
- Difference between String and StringBuffer.
- Difference between StringBuffer and StringBuilder.
- Difference between C# and .Net
Previous Page
Print Page
Next Page
Создание колбэка для подключения к службе
Чтобы использовать MusicService внутри других классов, нам нужно создать его экземпляр. Откройте MainActivity.kt и добавьте в начало класса следующее:
Здесь мы объявляем переменную, которая содержит экземпляр сервиса. В данный момент сервис является null. Мы назначим новое значение, когда активити подключится к службе с помощью интерфейса Binder. Чтобы уловить изменения состояния соединения, создайте колбэк соединения.
Добавьте код под инициализацией musicService:
Этот блок кода не сложно понять:
- Это колбэк для состояния подключения сервиса.
- Когда активити подключается к сервису, система использует экземпляр MusicBinder и getService() чтобы передать ссылку в musicService.
- Когда сервис отключается, воспроизведение звука прекратится, если ссылка на сервис еще не приняла значение null, при этом ссылка на сервис будет удалена.
Также устанавливается флаг isMusicServiceBound, который проверяет состояние привязки к сервису в обоих методах в соответствии с заданными вами параметрами
Это важно, чтобы избежать исключений DeadObjectException, которые удаленные методы генерируют при разрыве соединения
Привязка к Сервису
Следующим шагом мы создадим привязку сервиса при запуске MainActivity. Найдите onStart() и добавьте:
Здесь вы проверяете, имеет ли сервис уже привязку. Если нет, вы вызываете метод привязки.
Метод привязки еще не существует, поэтому добавьте его код ниже onDestroy():
В этом куске кода мы:
- Заявляем о намерении запустить MusicService
- Предоставляем сервису информацию о нашем Intent вместе с колбэком соединения и флагом, который автоматически создает сервис, если привязка существует.
Чтобы избежать утечек памяти или ошибок, вам нужно добавить код для отмены привязки сервиса. Добавьте в unbindMusicService() следующее:
Таким образом, вы говорите сервису выполнить onServiceDisconnected() в колбеке boundServiceConnection.
Отображение сообщения
Для отображения сообщения на экране, создайте виджет и установите текст с помощью. Затем добавьте в качестве корневого представления макета активити , передав его в .
Полный метод для теперь выглядит следующим образом:
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Get the message from the intent
Intent intent = getIntent();
String message = intent.getStringExtra(MainActivity.EXTRA_MESSAGE);
// Create the text view
TextView textView = new TextView(this);
textView.setTextSize(40);
textView.setText(message);
// Set the text view as the activity layout
setContentView(textView);
}
|
1 |
@Override publicvoidonCreate(Bundle savedInstanceState){ super.onCreate(savedInstanceState); Intent intent=getIntent(); Stringmessage=intent.getStringExtra(MainActivity.EXTRA_MESSAGE); TextView textView=newTextView(this); textView.setTextSize(40); textView.setText(message); setContentView(textView); } |
Теперь вы можете запустить приложение. Когда оно откроется, введите сообщение в текстовое поле, нажмите Отправить, и сообщение появится во второй активити .
Вот и все, вы создали своё первое Android приложение!
Чтобы узнать больше, перейдите по ссылке на следующий курс.
Забудем о boilerplate!
За время использования MVVM в разработке мы столкнулись с тем, что нам приходилось писать много надоедливого кода: модификация Activtiy/Fragment под базовые классы, прописывание длинных названий Binding-классов в дженериках, создание и связывание ViewModel, а на ранних стадиях и вовсе приходилось копировать базовые классы из проекта в проект, что также занимало драгоценное время. Именно поэтому мы создали библиотеку и плагин для Android Studio, с помощью которых эта рутина стала занимать всего 2-3 клика.
Библиотека AndroidMvvmHelper — это набор базовых классов для удобной работы с MVVM. В этот перечень входят классы как для работы с Activity (BindingActivity и ActivityViewModel), так и с Fragment (BindingFragment и FragmentViewModel), в которых уже реализована логика связывания, а также определены необходимые методы для получения callback-ов. Для того, чтобы начать ее использовать — необходимо просто определить зависимость в grdale-файле:
dependencies {
...
compile 'com.github.stfalcon:androidmvvmhelper:X.X'
}
Хотя решение с библиотекой и упрощает жизнь, создание классов все еще достаточно трудоемкий процесс. Для решения этой задачи мы разработали плагин для IntelliJ IDEA и Android Studio — MVVM Generator. Он позволяет в один клик создать класс BindingActivity (или BindingFragment), его ViewModel, подготовленный xml-файл для разметки и зарегистрировать компонент в AndroidManifest (в случае активности, конечно же). Кроме того, если плагин не обнаружит зависимости библиотеки MVVMHelper, она будет автоматически добавлена.
Чтобы его установить, нужно зайти в раздел управления плагинами:
 |
 |
В нем нажать кнопку “Browse repositories” для поиска доступных плагинов в сети:
В поле поиска вводим “MVVM Generator”, выбираем найденный плагин и жмем “Install”:
По окончанию установки необходимо перезапустить IDE. После этого плагин готов к работе.
Теперь давайте создадим фрагмент профиля. В случае, как и при создании обычного класса, вызываем контекстное меню на нужном пакете и выбираем “Create Binding Fragment”
После того, как мы введем название фрагмента (в нашем случае это “ProfileFragment”) мы получим следующее:
Заглянув внутрь, мы увидим готовые к работе классы:
public class ProfileFragment
extends BindingFragment<ProfileFragmentVM, FragmentProfileBinding> {
public ProfileFragment() {
// Required empty public constructor
}
public static ProfileFragment getInstance() {
return new ProfileFragment();
}
@Override
protected ProfileFragmentVM onCreateViewModel(FragmentProfileBinding binding) {
return new ProfileFragmentVM(this);
}
@Override
public int getVariable() {
return BR.viewModel;
}
@Override
public int getLayoutId() {
return R.layout.fragment_profile;
}
}
public class ProfileFragmentVM
extends FragmentViewModel<ProfileFragment> {
public ProfileFragmentVM(ProfileFragment fragment) {
super(fragment);
}
}
Помимо этого у нас сразу готов xml:
<layout xmlnsandroid="http://schemas.android.com/apk/res/android"
xmlnsapp="http://schemas.android.com/apk/res-auto"
xmlnstools="http://schemas.android.com/tools">
<data>
<variable
name="viewModel"
type="com.stfalcon.androidmvvmexample.features.profile.ProfileFragmentVM"/>
</data>
<RelativeLayout
androidlayout_width="match_parent"
androidlayout_height="match_parent">
</RelativeLayout>
</layout>
И все это буквально за пару секунд! Итак…
Представляем Android Services
Android Services — это компонент, который помогает выполнять длительные процессы, такие как обновление базы данных или сервера, запуск обратного отсчета или воспроизведение звука. По умолчанию Android Services запускаются в том же потоке, что и основные процессы приложения. Такой вид службы также называют local service.
Ресурсоемкие задачи данный сервис будет выполнять в фоновом режиме. Это позволит пользователю взаимодействовать с приложением. Например, если пользователь захочет позвонить или просмотреть уведомления при обновлении сервера, он сможет сделать это, не прерывая и не отменяя обновления.
Для этого нужно создать фоновый поток и вручную указать, какие задачи должны выполняться именно в этом потоке, поскольку сервисы не поддерживают реализацию потока напрямую.
Поскольку Android Services не имеет пользовательского интерфейса, он никак не зависит от последовательности выполнения других процессов. Это означает, что вы можете запускать его, даже когда пользователь вообще никак не взаимодействует с приложением.
Кроме того, другие компоненты приложения могут взаимодействовать с сервисами или даже осуществлять межпроцессное взаимодействие (InterProcess Communication (IPC)). Если вы будете дальше следовать этому туториалу, то узнаете больше о IPC.
В следующих разделах этого туториала мы применим каждый из перечисленных ниже типов Android Services и добавим в наше приложение Memo много новых функций:
- Foreground service: Добавим сервис TimerService, который содержит логику для отслеживания времени.
- Bound service: Используем MusicService, который позволит нам воспроизводить, ставить на паузу и перемешивать саундтреки.
Давайте начнем!
Определение Binder
К этому сервису нельзя получить доступ за пределами этого приложения, и у него нет собственного процесса. Следовательно, нам необходимо создать интерфейс, который будет иметь доступ к контексту сервиса. Сделаем это, расширив класс Binder. Таким образом, все компоненты могут использовать все общедоступные методы из Binder или Service.
Теперь, чтобы определить интерфейс, добавьте эти строки внизу класса:
MusicBinder вложен в другой класс и может получить доступ ко всем его методам. Он также может использовать все методы Binder. Внутри него вы создаете метод для получения контекста сервиса.
Понимание роли жизненного цикла приложений
Операционная система (ОС) Android — это многопользовательская система Linux. В большинстве случаев каждое приложение работает в собственном процессе Linux. ОС создает процесс, когда необходимо выполнить любой из компонентов приложения. Когда ни один компонент приложения не запущен, а ОС требуется освободить память для запуска других приложений, процесс прерывается.
ОС Android использует иерархию по важности, чтобы определить, какие процессы оставить в живых или уничтожить. В этой иерархии процессы делятся на разные типы
Этот тип зависит от запущенных в данный момент компонентов приложения и их текущего состояния.
Самый распространенный компонент приложения — Activity. Каждое приложение для Android имеет одно или несколько активити. Когда пользователь перемещается по приложению, действия проходят через разные состояния жизненного цикла.
Разработчики должны понимать, как различные компоненты влияют на время жизни процесса. Неправильное использование этих компонентов может привести к тому, что система остановит процесс, пока выполняет важную работу.
Использование ViewModel для хранения данных пользовательского интерфейса
ViewModel предназначен для хранения данных, связанных с пользовательским интерфейсом, и управления ими с учетом жизненного цикла.
Во-первых, замените логику сохранения и восстановления состояния в MainFragment.kt подходом, использующим ViewModel.
В пакете viewmodels создайте новый класс с именем MainViewModel.kt.
Это будет ViewModel для вашего главного экрана. Вы будете использовать его для сохранения состояния DogCount. Используйте _dogCount для отслеживания состояния и dogCount для отображения его наблюдателям. Для обновления состояния используйте setDogCount().
Если вы хотите узнать больше о LiveData, обратитесь к Android Developer documentation.
В MainFragment.kt добавьте следующее:
Добавьте следующую строку выше onCreate():
Таким образом, вы добавили код для создания MainViewModel для MainFragment.
Затем добавьте в MainFragment.kt следующий метод:
Этот метод позволяет вам подписаться на наблюдаемое состояние в MainViewModel. Каждый раз, когда состояние dogCount изменяется, приложение передает новое состояние во вью, и с новым состоянием вызывается renderDogCount(), в результате чего пользовательский интерфейс обновляется.
Затем измените onViewCreated(), чтобы подписаться на MainViewModel после вызова суперкласса:
Вам также понадобится логика, которая обновит состояние в MainViewModel. Измените updateDogCount() следующим образом:
Этот метод вызывается всякий раз, когда пользователь обновляет счетчики. Он обновит MainViewModel с новым состоянием. MainViewModel протолкнет это состояние через dogCount, и MainFragment получит уведомление, поскольку он подписан на MainViewModel.
Наконец, в MainFragment удалите onSaveInstanceState(), вызов renderDogCount (dogCount) из onResume() и код saveInstanceState? .Run {…} в onCreate(). Вам это больше не нужно. 
Скомпилируйте и запустите приложение. Коснитесь счетчиков пару раз и поверните экран. Вы должны увидеть что-то вроде этого:
На приведенном ниже рисунке можно увидеть время жизни ViewModel рядом с соответствующим жизненным циклом действия.
Объекты ViewModel привязаны к Lifecycle, передаваемому ViewModelProvider при получении ViewModel. Он остается в памяти до тех пор, пока Lifecycle, на который он рассчитан, не исчезнет навсегда. В случае активити это происходит, когда она завершена. Для фрагмента это происходит, когда он отсоединяется.
Понимание обратных вызовов жизненного цикла фрагмента
Теперь вы можете немного глубже погрузиться в каждое событие жизненного цикла, чтобы лучше понять жизненный цикл фрагмента:
- onCreate(): фрагмент достигает состояния Created. Подобно onCreate() активити, этот колбэк получает Bundle, содержащий любое состояние, ранее сохраненное onSaveInstanceState().
- onCreateView(): вызывается для расширения или создания вью фрагмента.
- onViewCreated(): вью фрагмента создается с ненулевым объектом View. Это представление устанавливается для фрагмента и может быть получено с помощью getView().
- onStart(): фрагмент переходит в состояние Started. В этом состоянии гарантируется, что вью фрагмента доступно и безопасно выполнить FragmentTransaction для дочернего FragmentManager фрагмента.
- onResumed(): фрагмент переходит в состояние Resumed. Он становится видимым после завершения всех эффектов Animator и Transition. Теперь пользователь может взаимодействовать с фрагментом.
- onPause(): фрагмент возвращается в состояние Started. ОС вызывает этот колбэк, когда пользователь начинает покидать фрагмент, пока фрагмент все еще виден.
- onStop(): фрагмент возвращается в состояние Created и больше не отображается.
- onDestroyView(): запускается после завершения всех анимаций выхода и переходов, когда представление фрагмента было отделено от окна. На этом этапе все ссылки на представление фрагмента должны быть удалены, что позволит очистить представление фрагмента от мусора.
- onDestroy(): фрагмент переходит в состояние Destroyed. Это происходит при удалении фрагмента или при уничтожении FragmentManager. На этом этапе жизненный цикл фрагмента подошел к концу.
Теперь, когда вы лучше понимаете, что скрывается под капотом, переходите между основным экраном и экраном Share, чтобы увидеть танец жизненного цикла фрагмента.
Как вы видели в этом и предыдущем разделе, жизненный цикл Android довольно сложен. Управлять состояниями и взаимодействовать с пользовательским интерфейсом в нужное время может быть непросто для неопытных разработчиков. Это привело к появлению некоторых новых API и компонентов Android, которые должны облегчить жизнь всем разработчикам Android. Одним из таких компонентов является ViewModel.
Создать Intent
это объект, который обеспечивает связывание отдельных компонент во время выполнения (например, двух активити ). представляет «намерение что-то сделать». Вы можете использовать интент для широкого круга задач, но чаще всего они используются, чтобы начать другую активити .
Внутри метода, создайте для запуска активити под названием:
Intent intent = new Intent(this, DisplayMessageActivity.class);
| 1 | Intent intent=newIntent(this,DisplayMessageActivity.class); |
Для этого требуется импортировать класс:
import android.content.Intent;
| 1 | import android.content.Intent; |
Полезный совет: В Eclipse, нажмите Ctrl + Shift + O для импортирования недостающих классов (Cmd + Shift + O на Mac). В Android Studio команда для импорта Alt+Enter.
Конструктор, используемый здесь принимает два параметра:
- в качестве первого параметра( используется, поскольку класс является подклассом )
- компонента приложения, в который система должна доставить (в данном случае активность, которая должна быть запущена)
Отправка intent в другие приложения
Intent, созданный в этом уроке считается явным, поскольку указывает точный компонент приложения, в которое интент следует отправить. Тем не менее, интенты также могут быть неявными, в этом случае не указывает нужный компонент, позволяя любой программе установленной на устройстве отвечать на интенты, пока она удовлетворяет спецификациям мета-данных действия, задаваемыми в различных параметрах. Для получения дополнительной информации читайте курс .
Примечание: Ссылка на вызовет ошибку, если вы используете интегрированную среду разработки, такую как Eclipse например, потому что класс еще не существует. Игнорируйте ошибку на данный момент; вы скоро создадите класс.
Intent не только позволяет начать другую Activity, но также может выполнять связь данных в Activity. В методе, используйте для получения элемента и добавьте его текстовое значение в Intent:
Intent intent = new Intent(this, DisplayMessageActivity.class);
EditText editText = (EditText) findViewById(R.id.edit_message);
String message = editText.getText().toString();
intent.putExtra(EXTRA_MESSAGE, message);
|
1 |
Intent intent=newIntent(this,DisplayMessageActivity.class); EditText editText=(EditText)findViewById(R.id.edit_message); Stringmessage=editText.getText().toString(); intent.putExtra(EXTRA_MESSAGE,message); |
Примечание: Вам необходим оператор импорта для . Вы определите константу буквально сейчас.
может нести коллекцию различных типов данных в виде пары ключ-значение, называемых Extras. Метод принимает имя ключа в первом параметре и значение во втором параметре.
Для того, чтобы Activity смогла запросить дополнительные данные, вы должны определить ключ для дополнений вашего интента, используя общедоступную константу. Так что добавьте определение в начало класса:
public class MainActivity extends ActionBarActivity {
public final static String EXTRA_MESSAGE = «com.example.myfirstapp.MESSAGE»;
…
}
|
1 |
publicclassMainActivityextendsActionBarActivity{ publicfinalstaticStringEXTRA_MESSAGE=»com.example.myfirstapp.MESSAGE»; … } |
Изучение жизненного цикла активности
На рисунке выше показаны различные состояния, через которые происходит активность в течение своего жизненного цикла:
- Initialized: создается экземпляр активити и инициализируются его свойства.
- Created: активити теперь полностью инициализировано и готово к настройке своего пользовательского интерфейса.
- Started: активити видна пользователю.
- Resumed: активити видна пользователю и находится в фокусе. В этом состоянии пользователь, скорее всего, взаимодействует с активити.
- Destroyed: активити уничтожена, и ОС может освободить свою память.
Обратите внимание на разные колбэки (обратные вызовы) между состояниями. ОС вызывает эти колбэки, когда активити переходит из одного состояния в другое
Вы можете переопределить эти методы в своих активити, чтобы выполнять задачи в ответ на эти изменения состояния жизненного цикла.
Прежде чем объяснять каждый колбэк, проверьте их в действии. Откройте MainActivity.kt и добавьте логирование в onCreate() и onResume(). Также переопределите другие колбэки:
Всякий раз, когда вы переопределяете такой колбэк, убедитесь, что вы также вызываете метод суперкласса. Если вы этого не сделаете, ваше приложение не выполнит какую-то важную работу и может вылететь или зависнуть.
Скомпилируйте и запустите приложение. Затем проверьте логи. Чтобы просмотреть логи в Android Studio, откройте инструмент Logcat, щелкнув Logcat внизу на странице. Введите PuppyCounter в историю поиска, чтобы показать результаты:
Затем закройте приложение, нажав назад, или проведите пальцем в обратном направлении, если у вас включена навигация с помощью жестов. Еще раз проверьте логи. Вы должны увидеть что-то вроде этого:
Заметка
В логах вы не увидите сообщение «Back button clicked» (Нажата кнопка назад). Мы добавили это в изображение, чтобы вам было легче заметить нажатия кнопок.
Объявление сервиса в Manifest
Перед использованием сервиса его необходимо объявить в AndroidManifest.xml. Сервис — это компонент Android, точно так же, как и Activity. Для удобства наш проект уже содержит классы сервисов, но вам все еще необходимо правильно их конфигурировать.
Перейдите к AndroidManifest.xml и добавьте этот код внутрь application:
В этом кода вы можете увидеть следующее:
- Android:name: Имя класса сервиса.
- Android:enabled: Если установлено значение true, система может создавать экземпляры сервисов.
- Android:exported: Если установлено значение False, то системе сообщается, что ни одно другое приложение не может запускать и использовать эти сервисы.
Значение android:name выделиться красным цветом, но пока просто не обращайте на это внимание. Мы починим это чуть позже
А пока начнем работу по реализации нового функционала.
