General

Structura unei aplicații (conform platformei alese)

Структура андроид приложения включает четыре основных компонента, которые
можно сочетать друг с другом – activity, services, broadcast receiver и content
Provider. Информация о том, какие из этих компонентов используются в
конкретном приложении, хранится в специальном файле – AndroidMainfest.xml.

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

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

Activity – представляет собой визуальный интерфейс для выполнения одной

задачи пользователя. Например, приложения для передачи текстовых сообщений
могут иметь одну «activity» для показа списка контактов, вторую «activity» для
редактирвания сообщений и другие «деятельности» для просмотра старых
сообщений или изменения настроек. Все эти «деятельности» формируют единый
пользовательский интерфейс, но не зависят друг от друга. Каждое из них
реализовано в виде базового класса Activity. Activity может находится в одном из
трёх состояний:

— Активное – находится на переднем плане экрана мобильного устройства и

может взаимодействовать.
— Приостановлено – приложение потеряло фокус, но все ещё доступно
пользователю. Приостановленное «Activity» может быть уничтожено системой в
случае нехватки памяти.
— Остановлено – полностью перекрыто другими «Activity» Оно больше не видно
пользователю и будет уничтожено системой, когда понадобится память.

Если «Activity» приостановлено или остановлено, система может удалить его из

памяти, либо отправить запрос на его завершение или просто уничтожить его
процесс. Когда «Activity» снова отображается пользователю, его состояние
полностью восстанавливается. Activities являются основной частью разработки
приложений для Android.
Более сложные приложения могут иметь несколько окон, т.е. они состоят из
нескольких активностей, которыми надо уметь управлять и которые могут
взаимодействовать между собой. Активность, которая запускается первой,
считается главной. Из нее можно запустить другую активность.

Выполнение приложения Android по умолчанию начинается с класса MainActivity,

который по умолчанию открыт в Android Studio. По умолчанию MainActivity
содержит только один метод onCreate(), в котором фактически и создается весь
интерфейс приложения.

SERVICE (служба) — это компонент android-приложения без видимого

интерфейса, который запускается в основном потоке приложения. Служба должна
быть объявлена в манифесте. Службы в Android работают как фоновые процессы
и представлены классом android.app.Service.

Они не имеют пользовательского интерфейса и нужны в тех случаях, когда не

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

Android даёт службам более высокий приоритет, чем бездействующим

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

Трансляция (broadcast) — это просто сообщение, заключенное в объект Intent.

Трансляция может быть неявной или явной.

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

батареи или наличии интернета. Cистема сама следит за подобными вещами и
готова поделиться со всеми нуждающимися своими сообщениями. Задача
пользователя заключается в том, чтобы реализовать у себя широковещательный
приёмник (Broadcast Receiver). Получатель трансляции всегда будет получать
уведомления, независимо от состояния вашего приложения - работает ли ваше
приложение в фоновом режиме или вообще не работает в данный момент.
Широковещательные сообщения делают приложение более открытым.
Приёмник широковещательных сообщений — это компонент для получения
внешних событий и реакции на них. Инициализировать передачи могут:

- другие приложения или службы;

- сама система;
- ваше собственное приложение;

Класс BroadcastReceiver является базовым для класса, в котором должны

происходить получение и обработка сообщений, посылаемых клиентским
приложением с помощью вызова метода sendBroadcast(). Зарегистрировать
экземпляр класса BroadcastReceiver можно динамически в коде или статически в
манифесте.

Для статической регистрации в файле манифеста в секции application следует

создать секцию receiver и указать класс приёмника. Атрибут
android:exported="true" сообщает получателю, что он может принимать
широковещательные сообщения вне области приложения. Внутри секции
указывается фильтр намерений в виде строки, чтобы определить, какие
сообщения приёмник должен прослушивать.

Если регистрация была сделана через манифест, приложение не обязано

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

Когда широковещательное сообщение прибывает для получателя сообщения,

Android вызывает его методом onReceive() и передаёт в него объект Intent,
содержащий сообщение. Приёмник широковещательных сообщений является
активным только во время выполнения этого метода. Процесс, который в
настоящее время выполняет BroadcastReceiver, т. е. выполняющийся в настоящее
время код в методе обратного вызова onReceive(), как полагает система, является
приоритетным процессом и будет сохранён, кроме случаев критического
недостатка памяти в системе.

Контент-провайдер или "Поставщик содержимого" (Content Provider) - это

оболочка (wrapper), в которую заключены данные. Это способ расшарить для
общего пользования данные вашего приложения. Обычно это данные из БД. И
создание класса провайдера похоже на создание обычного класса для работы с
БД. Мы используем SQLiteOpenHelper для управления базой, и реализуем методы
query, insert, update, delete класса ContentProvider.

Поставщик содержимого применяется лишь в тех случаях, когда вы хотите

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

В Android существует возможность выражения источников данных (или

поставщиков данных) при помощи передачи состояния представления - REST, в
виде абстракций, называемых поставщиками содержимого. Базу данных SQLite
можно заключить в поставщик содержимого. Чтобы получить данные из
поставщика содержимого или сохранить в нём новую информацию, нужно
использовать набор REST-подобных идентификаторов URI.
Для создания собственного контент-провайдера нужно унаследоваться от
абстрактного класса ContentProvider: public class MyContentProvider extends
ContentProvider {

А также его следует зарегистрировать в манифесте с помощью тега provider с

атрибутами name и authorities. Тег authorities служит для описания базового пути
URI, по которому ContentResolver может найти базу данных для взаимодействия.
Данный тег должен быть уникальным, поэтому рекомендуется использовать имя
вашего пакета, чтобы не произошло путаницы с другими приложениями.

В Android Studio во вкладке проекта можно найти следующие элементы:

src – cодержит исходный код приложения.

com.example.StructureProjectApp – это package, наименование которого,

указывается при создании проекта.

Main.java – файл исходного кода, в котором описан класс главной Activity.

gen – содержит java файлы, создаваемые автоматически во время разработки

приложения. Файлы, находящиеся в папке gen не должны изменяться в ручную!

BuildConfig.java – содержит константу DEBUG, значение константы

устанавливается автоматически в зависимости от того, является ли версия
текущей сборки приложения, конечной или промежуточной.

Константа позволяет запускать код только в режиме отладки. Файл

BuildConfig.java был добавлен после выхода ADT revision 17.

R.java – хранит уникальные идентификаторы для всех ресурсов приложения (ID).

main.xml – файл описывает компоновку элементов экрана.

assets – папка, позволяющая организовать совершенно произвольную структуру

вложенных папок и файлов. Содержимое папки assets не считается ресурсами.

bin – каталог сборки приложения. При компиляции приложения Google Android

получается сборка, размещаемая в этом каталоге.

res – содержит структуру папок ресурсов приложения. Наименование каждой

папки определяет тип ресурсов, которые она должна содержать.

AndroidManifest – файл, который указывает точку входа в приложение. Служит

для задания общей информации о приложении. Определения атрибутов
приложения. Запроса прав доступа к определенным критическим операциям и
другой информации. Данный файл принято называть файлом описания, или
файлом манифеста.

protect.properties – содержит параметры проекта, например версию API. Файл

создается автоматически и не может быть удален.
 Operatii asupra Serviciilor (conform platformei alese)

Запущенная служба может работать на переднем плане. Это означает, что

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

— Приложения, которые проигрывают медиа-файлы в фоне.

— Приложения, которые обновляют данные о местоположении в фоне.

Когда запущенная служба помещается на передний план, она должна вывести на

экран уведомление, явно сообщая пользователю, что служба работает. Это
важно, потому что запущенная служба на переднем плане отделена от
жизненного цикла UI-компонентов (за исключением, разумеется, самого
постоянного уведомления). И нет другого способа сообщить пользователю о том,
что на его телефоне что-то работает (и потенциально потребляет много ресурсов)
кроме как вывести в UI постоянное уведомление. Ниже пример старта запущенной
службы на переднем плане:

public class MyActivity extends Activity{

private void commandStart() {

if (!mServiceIsStarted) {

moveToStartedState();

return;

if (mExecutor == null) {

// Start Executor task in Background Thread.

}
Остановка запущенных служб

Параметр piStopService типа PendingIntent (который передается в конструктор

уведомления) фактически передает Intent с константой Command.STOP типа
Integer. Чтобы остановить службу мы запускаем Intent через startService(Intent) и
далее обрабатываем этот Intent в методе onStartCommand() запущенной службы.
Чтобы остановить службу вы можете выполнить одно из следующих действий:

1) Передать Intent с дополнительным параметром в startService(), который затем

будет обработан в onStartCommand() и фактически служба вызовет stopSelf(). И,
если к службе не привязаны никакие другие компоненты, это вызовет onDestroy()
и служба завершит свою работу.

2) Создать явный Intent (указывая на класс службы) и передать его в метод

stopService(), который вызовет stopSelf() и, затем, onDestroy()

Пример остановки службы из Activity:

public class MyActivity extends Activity{

void stopService1(){

stopService(new MyIntentBuilder(this).build());

void stopService2(){

startService(new MyIntentBuilder(this)

.setCommand(Command.STOP).build());

Привязка службы

В отличие от запущенных служб, привязанные службы позволяют установить

соединение между компонентом Android, привязанным к службе, и службой. Это
соединение предоставляется реализацией интерфейса IBinder, который
определяет методы для взаимодействия со службой. Простым примером этого
может быть реализация привязанной службы в одном процессе с клиентом (т.е. в
рамках вашего собственного приложения). В этом случае Java-объект, подкласс
Binder, передается клиенту, который может использовать его для вызова методов
службы. Отличия между привязанной и запущенной службами:

1) У клиентского компонента нет соединения с запущенной службой. Он просто

использует объекты Intent посредством startService() или stopService(), которые
обрабатываются службой в методе onStartCommand().

2) Когда клиентский компонент (Activity, Fragment или другая служба) соединяются

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

В привязанной службе вы должны реализовать метод onBind(), для получения

клиентом экземпляра IBinder. Метод 'onBind()' будет вызван только один раз, при
первой привязке клиента. Для последующих клиентов, система выдаст такой же
экземпляр IBinder:
public class MyService extends Service{

public IBinder onBind(Intent intent){

if (mBinder == null){

mBinder = new MyBinder();

return mBinder;

Объект IBinder обеспечивает программный интерфейс, с помощью которого

клиенты могут взаимодействовать со службой. Как говорилось выше, самый
простой способ реализации IBinder — это расширение класса Binder, экземпляр
которого возвращается из метода onBind():

public class MyService extends Service{

public class MyBinder extends android.os.Binder {

MyService getService(){

// Simply return a reference to this instance

 //of the Service.

return MyService.this;

Отвязка от службы и вызов onDestroy()

Чтобы отвязаться от привязанной службы, клиент просто вызывает

unbindService(mServiceConnection). Затем система вызовет onUnbind() в самой
службе. И, если у привязанной службы больше нет клиентов, и также, если,
служба не является запущенной службой, то система вызывает onDestroy. Вот как
выглядит вызов unbindService() в клиентском компоненте:

public class MyActivity extends Activity{

protected void onStop(){

if (mServiceBound){

unbindService(mServiceConnection);

mServiceBound = false;

Вывести список всех запущенных сервисов

ActivityManager am = (ActivityManager) this

.getSystemService(ACTIVITY_SERVICE);
List<ActivityManager.RunningServiceInfo> rs = am.getRunningServices(50);

for (int i = 0; i < rs.size(); i++) {

ActivityManager.RunningServiceInfo rsi = rs.get(i);
Log.i("Service", "Process " + rsi.process + " with component "
+ rsi.service.getClassName());
}
Переход в запущенное состояние

Поскольку клиент, привязываясь к службе, не переведет ее в запущенное

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

1) Если служба привязывается к клиенту, то она не запущена (и вmServiceStarted

содержится false)

2) Вызывается moveToStarted() и там создается явный Intent с Extras

Command.START, и далее вызывается startService() или startForegroundService().

3) Это приводит к вызову onStartCommand(), который опять вызывает

commandStart().

4) Но теперь в commandStart() значение переменной mServiceIsStarted равняется

true, и поэтому метод commandStart() выполняет свое прямое предназначение,
т.е. запускает полезную работу службы.

Завершение работы службы и отвязывание

Если служба не в запущенном состоянии и клиентский компонент отвязывается от

службы, то служба уничтожается и вызывается onDestroy()

Но если она в запущенном состоянии она не уничтожается. И она будет "убита",

только если запущенное состояние будет остановлено (через вызов
stopService(Intent) или вызов startService(Intent) c Extras в Intent, которые говорят о
намерении остановить службу, например Command.STOP).

На изображении ниже представлена диаграмма, в которой суммируются

состояния службы и переходы между ними для запущенной и привязанной
службы одновременно:
 Metode Asynchrone (async/await)

Когда мы сталкиваемся с длительными операциями, такими как сетевые запросы

или транзакции в базу данных, то надо быть уверенным, что запуск происходит в
фоновом потоке. Если же забыть об этом, то можно получить блокировку UI
потока еще до того, как задача закончится. А во время блокировки UI
пользователь не сможет взаимодействовать с приложением. К сожалению, когда
мы запускаем задачу в фоне, то не можем использовать результат тут же. Для
этого нам потребуется некая разновидность callback'а. Когда callback будет
вызван с результатом, только тогда мы сможем продолжить, например запустить
еще один сетевой запрос.
С помощью async-await можно привести этот код к более императивному стилю с
той же функциональностью. Вместо отправки callback'а можно вызвать
"замораживающий" метод await, который позволит использовать результат так же,
словно он был вычислен в синхронном коде.

Метод async позволяет использовать await и изменяет способ получения

результата. При входе в метод, каждая строка будет выполнена синхронно пока
не достигнет точки "заморозки"(вызова метода await). По факту, это все, что
делает async — позволяет не перемещать код в фоновый поток.

Метод await позволяет делать вещи асинхронно. Он принимает "awaitable" в

качестве параметра, где "awaitable" — какая-то асинхронная операция. Когда
вызывается await, он регистрируется в "awaitable", чтобы получить уведомление,
когда операция закончится, и вернуть результат в метод asyncUI. Когда "awaitable"
завершится, он выполнит оставшуюся часть метода, при этом передав туда
результат.

AsyncTask and Threads

Thread - это легкий процесс для достижения concurrency и максимального

использования процессора. В android вы можете использовать поток для
выполнения действий, которые не касаются пользовательского интерфейса
приложения.

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

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

Применение фоновых потоков — необходимое условие, если вы хотите избежать

появления диалогового окна для принудительного закрытия приложения. Когда
активность в Android на протяжении 5 секунд не отвечает на события
пользовательского ввода (например, нажатие кнопки) или приёмник
широковещательных намерений не завершает работу обработчика onReceive() в
течение 10 секунд, считается, что приложение зависло. Подобные ситуации
следует избегать любой ценой. Используйте фоновые потоки для всех трудоёмких
операций, включая работу с файлами, сетевые запросы, транзакции в базах
данных и сложные вычисления.

Класс AsyncTask позволяет определить операции, которые будут выполняться в

фоне, вы также будете иметь доступ к обработчику событий, что позволит
отслеживать прогресс выполнения задач и выводить результаты в контексте
главного графического потока. Он предлагает простой и удобный механизм для
перемещения трудоёмких операций в фоновый поток. Благодаря ему вы
получаете удобство синхронизации обработчиков событий с графическим
потоком, что позволяет обновлять элементы пользовательского интерфейса для
отчета о ходе выполнения задачи или для вывода результатов, когда задача
завершена.

Следует помнить, что AsyncTask не является универсальным решением для всех

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

Напрямую с классом AsyncTask работать нельзя (абстрактный класс), вам нужно

наследоваться от него (extends). Ваша реализация должна предусматривать
классы для объектов, которые будут переданы в качестве параметров методу
execute(), для переменных, что станут использоваться для оповещения о ходе
выполнения, а также для переменных, где будет храниться результат.

Данный класс предоставляет удобства для выполнения некоторой работы над

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

AsyncTask разработан как вспомогательный класс вокруг Thread и Handler и не

представляет собой общую структуру потоков. AsyncTasks в идеале следует
использовать для коротких операций (не более нескольких секунд). Если вам
нужно поддерживать потоки в течение длительных периодов времени,
настоятельно рекомендуется использовать различные API, предоставляемые
java.util.concurrent pacakge, такие как Исполнитель, ThreadPoolExecutor и
FutureTask.

Interfete si Clase Abstracte

Класс, содержащий абстрактные методы, называется абстрактным классом. Такие

классы помечаются ключевым словом abstract. Абстрактный метод не завершён.
Он состоит только из объявления и не имеет тела: abstract void yourMethod();

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

абстрактного класса, но хотите иметь возможность создания объектов нового
типа, вам придётся предоставить определения для всех абстрактных методов
базового класса. Если этого не сделать, производный класс тоже останется
абстрактным, и компилятор заставит пометить новый класс ключевым словом
abstract. Абстрактный класс связывает между собой и объединяет классы,
имеющие очень близкую связь.

Интерфейс описывает только поведение. У него нет состояния. А у абстрактного

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

Классы могут реализовывать сколько угодно интерфейсов, но наследоваться

можно только от одного класса.

Разница между абстрактным классом и интерфейсом

Ключевое слово abstract используется для того, чтобы создать абстрактный

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

Подклассы используют ключевое слово extends чтобы наследовать абстрактный

класс. При этом они должны обеспечить реализацию всех заявленных методов в
абстрактном классе. Если же подкласс не является абстрактным классом и
использует ключевое слово implements для реализации интерфейсов, то
он должен обеспечить реализацию для всех методов, объявленных в интерфейсе.
Абстрактные классы могут иметь методы с реализации, тогда как интерфейс
обеспечивает абсолютную абстракцию и не может иметь каких-либо реализаций
метода.

Абстрактные классы могут иметь конструкторы; интерфейсы не могут иметь

конструкторов.

У абстрактного класса есть все черты обычного Java-класса, за исключением того,

что мы не можем создать его экземпляр. Мы можем использовать ключевое
слово abstract чтобы создать абстрактный класс. Интерфейс может иметь только
статические public static final константы и объявления методов.

Абстрактные методы классов могут иметь public, private, protected и static

модификаторы доступа, а методы интерфейса неявно public и abstract, поэтому
мы не можем использовать другие модификаторы доступа с методами
интерфейса.

Подкласс может наследовать только один абстрактный класс, и реализовать

несколько интерфейсов.

Абстрактный класс может наследовать другой класс и реализовывать

интерфейсы, а интерфейс может только наследовать другие интерфейсы.

Мы можем запустить абстрактный класс, если он имеет метод main(). Мы не

можем запустить интерфейс, потому что у него не может быть реализации метода
main().

Интерфейс обеспечивает так называемый контракт для всех классов, которые

реализуют интерфейс. Абстрактный классы — класс с реализацией метода по
умолчанию для подклассов.

Noțiunea de Context

Context – это объект, который предоставляет доступ к базовым функциям

приложения: доступ к ресурсам, к файловой системе, вызов активности и т.д.
Activity является подклассом Context, поэтому в коде мы можем использовать её
как ИмяАктивности.this (напр. MainActivity.this), или укороченную запись this.
Классы Service, Application и др. также работают с контекстом. Доступ к контексту
можно получить разными способами. Существуют такие методы как
getApplicationContext(), getContext(), getBaseContext() или this, который упоминался
выше, если используется в активности. Через контекст можно узнать практически
всю информацию о вашем приложении - имя пакета, класса и т.п.

Тем не менее, следует различать контекст в разных ситуациях. Допустим, у вас

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

Context имеет свои методы, позволяющие получать доступ к ресурсам и другим

объектам.

— getAssets()

— getResources()

— getPackageManager()

— getString()

— getSharedPrefsFile()

Protocolul HTTP

HTTP — широко распространённый протокол передачи данных, изначально

предназначенный для передачи гипертекстовых документов (то есть документов,
которые могут содержать ссылки, позволяющие организовать переход к другим
документам). Аббревиатура HTTP расшифровывается как HyperText Transfer
Protocol, «протокол передачи гипертекста» или «язык гипертекстовой рассылки».

Протокол HTTP предполагает использование клиент-серверной структуры

передачи данных. Клиентское приложение формирует запрос и отправляет его на
сервер, после чего серверное программное обеспечение обрабатывает данный
запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское
приложение может продолжить отправлять другие запросы, которые будут
обработаны аналогичным образом.
Задача, которая традиционно решается с помощью протокола HTTP — обмен
данными между пользовательским приложением, осуществляющим доступ к веб-
ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно
благодаря протоколу HTTP обеспечивается работа Всемирной паутины.

Также HTTP часто используется как протокол передачи информации для других
протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком
случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP

для передачи данных — сами данные при этом могут иметь любой формат,
например, XML или JSON.

HTTP — это клиент-серверный протокол, то есть запросы отправляются какой-то

одной стороной — участником обмена (user-agent) (либо прокси вместо него).
Чаще всего в качестве участника выступает веб-браузер, но им может быть кто
угодно, например, робот, путешествующий по Сети для пополнения и обновления
данных индексации веб-страниц для поисковых систем.

Каждый запрос (англ. request) отправляется серверу, который обрабатывает его и

возвращает ответ (англ. response). Между этими запросами и ответами как
правило существуют многочисленные посредники, называемые прокси, которые
выполняют различные операции и работают как шлюзы или кэш, например.

Обычно между браузером и сервером гораздо больше различных устройств-

посредников, которые играют какую-либо роль в обработке запроса:
маршрутизаторы, модемы и так далее. Благодаря тому, что Сеть построена на
основе системы уровней (слоёв) взаимодействия, эти посредники "спрятаны" на
сетевом и транспортном уровнях. В этой системе уровней HTTP занимает самый
верхний уровень, который называется "прикладным" (или "уровнем приложений").
Знания об уровнях сети, таких как представительский, сеансовый, транспортный,
сетевой, канальный и физический, имеют важное значение для понимания работы
сети и диагностики возможных проблем, но не требуются для описания и
понимания HTTP.
Чтобы отобразить веб страницу, браузер отправляет начальный запрос для
получения HTML-документа этой страницы. После этого браузер изучает этот
документ, и запрашивает дополнительные файлы, необходимые для отбражения
содержания веб-страницы (исполняемые скрипты, информацию о макете
страницы - CSS таблицы стилей, дополнительные ресурсы в виде изображений и
видео-файлов), которые непосредственно являются частью исходного документа,
но расположены в других местах сети. Далее браузер соединяет все эти ресурсы
для отображения их пользователю в виде единого документа — веб-страницы.
Скрипты, выполняемые самим браузером, могут получать по сети
дополнительные ресурсы на последующих этапах обработки веб-страницы, и
браузер соответствующим образом обновляет отображение этой страницы для
пользователя.

Веб-страница является гипертекстовым документом. Это означает, что некоторые

части отображаемого текста являются ссылками, которые могут быть
активированы (обычно нажатием кнопки мыши) с целью получения и
соответственно отображения новой веб-страницы (переход по ссылке). Это
позволяет пользователю "перемещаться" по страницам сети (Internet). Браузер
преобразует эти гиперссылки в HTTP-запросы и в дальнейшем полученные HTTP-
ответы отображает в понятном для пользователя виде.

На другой стороне коммуникационного канала расположен сервер, который

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

Между веб-браузером и сервером находятся большое количество сетевых узлов

передающих HTTP сообщения. Из за слоистой структуры, большинство из них
оперируют также на транспортном сетевом или физическом уровнях, становясь
прозрачным на HTTP слое и потенциально снижая производительность. Эти
операции на уровне приложений называются прокси. Они могут быть
прозрачными, или нет, (изменяющие запросы не пройдут через них), и способны
исполнять множество функций:

- caching (кеш может быть публичным или приватными, как кеш браузера)

- фильтрация (как сканирование антивируса, родительский контроль, …)

- выравнивание нагрузки (позволить нескольким серверам обслуживать разные

запросы)

- аутентификация (контролировать доступом к разным ресурсам)

- протоколирование (разрешение на хранение истории операций)

Metodele și cîmpurile prot. HTTP

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

разделителей, указывающая на основную операцию над ресурсом. Обычно метод
представляет собой короткое английское слово, записанное заглавными буквами.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если
сервер не распознал указанный клиентом метод, то он должен вернуть статус 501
(Not Implemented). Если серверу метод известен, но он не применим к
конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not
Allowed). В обоих случаях серверу следует включить в сообщение ответа
заголовок Allow со списком поддерживаемых методов. Кроме методов GET и
HEAD, часто применяется метод POST. Все методы:

1) GET - запрос содержимого указанного ресурса. Может кешироваться.

2) HEAD HTTP запрос - аналогичен методу GET, за исключением того, что в

ответе сервера отсутствует тело. Проверка наличия ресурса. Может
кэшироваться.

3) POST - применяется для передачи пользовательских данных заданному

ресурсу. Не кэшируется.

4) OPTIONS - запрашивает информацию о коммуникационных параметрах

сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса
следует использовать символ *.

5) PUT - помещает тело содержимого запроса по указанному URI.

6) PATCH - аналогично PUT, но применяется только к фрагменту ресурса.

7) DELETE - удаляет данные, находящиеся на сервере.

8) TRACE - требует, чтобы тело содержимого запроса было возвращено без

изменений. Используется для отладки.

9) LINK - связывает информацию заголовка с документом на сервере.

10) UNLINK - о связь информации заголовка с документом на сервере.

XML/Json (metode de serializare/deserializare)

Сериализация — это процесс сохранения состояния объекта в

последовательность байт. Сериализация используется для передачи объектов по
сети и для сохранения их в файлы. Например, нужно создать распределённое
приложение, разные части которого должны обмениваться данными со сложной
структурой. В таком случае для типов данных, которые предполагается
передавать, пишется код, который осуществляет сериализацию и
десериализацию. Объект заполняется нужными данными, затем вызывается код
сериализации, в результате получается, например, XML-документ. Приложение-
получатель создаёт объект того же типа и вызывает код десериализации, в
результате получая объект с теми же данными, что были в объекте приложения-
отправителя. Таким образом, можно сказать, что десериализация — это процесс
восстановления объекта из этих байт.

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными,

основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко
читается людьми. Несмотря на происхождение от JavaScript, формат считается
независимым от языка и может использоваться практически с любым языком
программирования. Для многих языков существует готовый код для создания и
обработки данных в формате JSON.

XML — расширяемый язык разметки. XML разрабатывался как язык с простым

формальным синтаксисом, удобный для создания и обработки документов
программами и одновременно удобный для чтения и создания документов
человеком, с подчёркиванием нацеленности на использование в Интернете. Язык
называется расширяемым, поскольку он не фиксирует разметку, используемую в
документах: разработчик волен создать разметку в соответствии с потребностями
к конкретной области, будучи ограниченным лишь синтаксическими правилами
языка. Расширение XML — это конкретная грамматика, созданная на базе XML и
представленная словарём тегов и их атрибутов, а также набором правил,
определяющих, какие атрибуты и элементы могут входить в состав других
элементов. Используется для хранения и передачи данных. Так что увидеть его
можно не только в API, но и в коде.

JSON - Синтаксис JSON - это, по сути, JavaScript, и поэтому любой компонент с

механизмом JS будет очень хорошо справляться с его синтаксическим анализом -
даже сложные структуры данных будут эффективно преобразованы в "живые"
объекты. Парсеры JSON существуют практически для любого языка, и его легко
использовать, даже если не используется движок JS (например, Google Gson,
который может легко преобразовывать JSON в соответствующие объекты), что
делает его хорошим кандидатом для межъязыкового общения - например, в
архитектуре обмена сообщениями.

XML - имеет много преимуществ JSON - кросс-языковой, легкий и т.д. Adobe Flex,
например, очень хорошо обрабатывает XML, даже лучше, чем JSON. Это
определенно подходящая замена для JSON. Я лично предпочитаю JSON за его
JS-подобный синтаксис, но XML тоже хорош.

notiuni generale și moduri de utilizare RegEx

Регулярные выражения — формальный язык поиска и осуществления

манипуляций с подстроками в тексте. Для поиска используется строка-образец
(англ. pattern, по-русски её часто называют «шаблоном», «маской»), состоящая из
символов и метасимволов и задающая правило поиска. Для манипуляций с
текстом дополнительно задаётся строка замены, которая также может содержать
в себе специальные символы. Это шаблоны, используемые для сопоставления
последовательностей символов в строках. В JavaScript регулярные выражения
также являются объектами. Эти шаблоны используются в методах exec и test
объекта RegExp, а также match, replace, search и split объекта String.

Регулярные выражения – мощное средство поиска и замены в строке.В JavaScript

регулярные выражения реализованы отдельным объектом RegExp и
интегрированы в методы строк. Существует два синтаксиса для создания
регулярного выражения.
1) Длинный синтаксис:
regexp = new RegExp("шаблон", "флаги");

2) Короткий синтаксис, использующий слеши "/":

regexp = /шаблон/; // без флагов

regexp = /шаблон/gmi; // с флагами gmi

Регулярные выражения используются некоторыми текстовыми редакторами и

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

— найти все последовательности символов «кот» в любом контексте, как то:

«кот», «котлета», «терракотовый»;

— найти отдельно стоящее слово «кот» и заменить его на «кошка»;

— найти слово «кот», которому предшествует слово «персидский» или

«чеширский»;

В Java могут использоваться нестандартные приёмы использования регулярных

выражений по синтаксису. Например, во многих языках выражение \\ означает, что
ищется символ обратного слеша, который идёт за специальным мета-символом
регулярного выражения. В Java придётся использовать для этой цели \\\\. Но таких
различий немного.

Пакет содержит два класса - Pattern и Matcher, которые работают вместе. Класс
Patern применяется для задания регулярного выражения. Класс Matcher
сопоставляет шаблон с последовательностью символов.

Регулярное выражение состоит из обычных символов, наборов символов и

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

Символы новой строки, табуляции и др. определяются при помощи стандартных

управляющих последовательностей, которые начинаются с обратного слеша (\).
Например, символ новой строки можно задать как \n.
 HTML Parsing/xPath

HTML (HyperText Markup Language — «язык гипертекстовой разметки») — самый

базовый строительный блок Веба. Он определяет содержание и структуру веб-
контента. Другие технологии, помимо HTML, обычно используются для описания
внешнего вида/представления (CSS) или функциональности/поведения
(JavaScript) веб-страницы.

Под гипертекстом ("hypertext") понимаются ссылки, которые соединяют веб-

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

Xpath — это язык запросов к элементам xml или xhtml документа. Также как SQL,
xpath является декларативным языком запросов. Чтобы получить интересующие
данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю
«черную» работу за вас выполнит интерпретатор языка xpath.