Разве Branch не является избыточным, по крайней мере, в Android? С такими вопросами, как: Android — возможно ли программно установить реферер где мы можем делать наши собственные глубокие ссылки, разве Branch теперь не является еще одним избыточным инструментом (по крайней мере, в Android)? Я могу делать все, что предлагает Branch, вообще без интеграции Branch. Или я что-то упускаю?
Sid 7 Мар 2016 в 12:17
1 ответ
Лучший ответ
(Полное раскрытие: в прошлом году я выполнил интеграцию приложения Branch и теперь работаю с командой Branch.)
Это хороший вопрос, и вы правы: ландшафт глубинных ссылок на Android значительно расширился, особенно с появлением ссылок на приложения в Android M. Как вы упомянули, разработчики URL-адрес установки Google Play (который также использует филиал) доступен для кто угодно и передает ограниченный объем данных в процессе установки. Однако он не всегда доставляется надежно и не особенно гибок. Многие партнеры Branch ранее пробовали этот подход и обнаружили, что он слишком медленный.
Git branch — работа с ветками
Branch по-прежнему предлагает несколько преимуществ
Поскольку на самом деле пока нет никаких «стандартов» для глубинных ссылок, Branch по-прежнему может быть полезным вариантом plug-and-play для разработчиков. Вот несколько конкретных областей, в которых помогает Branch:
Краевые случаи
Учитывая количество доступных устройств Android и версий ОС, их очень много. Вы будете думать, что все идет отлично, пока не встретите этого пользователя, который жалуется, что его ссылки не работают в Facebook при использовании Android 4.4.4. В настоящее время Branch отслеживает более 6000 таких ситуаций ( источник ), который может спасти вас от этого кошмара и гарантировать, что ваши ссылки будут работать везде.
Гибкость данных
Реферер установки Google Play позволяет передавать несколько строк через параметры запроса URL, но он не является постоянным хранилищем и работает только во время первой установки. Branch позволяет отправлять практически все, о чем вы можете подумать (а также добавляет некоторые полезные аналитические данные), и он постоянно доступен для каждой ссылки, которую когда-либо нажимали ваши пользователи.
Кроссплатформенность
Я знаю, что вы спрашивали конкретно об Android, но если у вашего приложения есть версия для iOS (или она может быть запущена в будущем), Branch позволяет легко справиться со всем с помощью одной системы.
Инструменты с добавленной стоимостью
Это не технология прямых ссылок как таковая, но Branch также может позволить вашим пользователям просматривать содержимое приложения перед установкой, сами текстовые ссылки для загрузки со своего компьютера и увидите , среди прочего, подробная аналитика по каждому фрагменту контента внутри приложения . Да, конечно, все это можно разработать собственными силами, но это требует значительных ресурсов.
Alex Bauer 7 Мар 2016 в 20:51
Это довольно хорошее объяснение. Спасибо за подробный ответ. Сейчас я перехожу к использованию Branch для глубинных ссылок. 🙂
GitHub ветки (branch) — зачем и какие нужны
8 Мар 2016 в 13:51
Это было бы круто! Пожалуйста, дайте мне знать, как только у вас будет возможность попробовать — хотелось бы услышать любые мысли, которые могут у вас возникнуть
Alex Bauer
8 Мар 2016 в 14:44
Кроме того, если вы не против принять ответ, это может помочь кому-нибудь еще с тем же вопросом в будущем! 🙂
Источник: question-it.com
Введение
Приложения можно продвигать самыми разными способами. Одним из таких способов является реферальный маркетинг. Этот вид маркетинга заключается в том, что информация о приложении будет распространяться не через рекламные сети, а от существующих пользователей к потенциальным.
Таким образом, использование реферального маркетинга может быть крайне полезно потому, что человек с большей вероятностью будет прислушиваться к мнению своих друзей, родных или близких, чем к объявлениям в рекламе. Например, пользователь, который скачал приложение и остался им доволен, сможет не только посоветовать приложение другим людям, но и дать так называемую реферальную ссылку, по которой будущие пользователи смогут напрямую перейти в магазин и установить приложение себе на устройство. Это придаёт продвижению некоторую «вирусность», что в данном случае пойдёт только на пользу.
В сети есть множество способов по реализации реферальных ссылок в приложениях, одно из них мы рассмотрели в предыдущей статье. В этой же хочется рассказать о таком инструменте, как Branch.io, который позволяет создавать быстрые ссылки, отслеживать переходы по реферальным, а также собирать аналитику по событиям в приложении.
Начало работы в Branch
Перед тем, как приступить к добавлению нужных инструментов в приложение, нужно зарегистрировать аккаунт и приложение в Branch. Для данной статьи мы будем добавлять реферальные ссылки в одно из наших приложений, русско-бурятский словарь Бурдик.
Как только вы зарегистрируете свой аккаунт, вам предложат придумать доменное имя для своих быстрых ссылок.
Имя можно выбрать любое, главное, чтобы оно было информативным и понятным. Например, напишем burdic.app.link.
После этого нужно указать, есть ли у вашей компании сайт, а также выбрать, на каких платформах работает ваше приложение (iOSAndroid) и дать ссылки на приложение в магазине.
Если у вас нет приложения на iOS, вы можете просто нажать No и пропустить этот шаг. Для Android же вам понадобится ввести название пакета, как оно указано в магазине, после чего приложение будет найдено.
Затем будет создана ваша первая быстрая ссылка, по которой вы сможете перейти или на ваш сайт, или в магазин, где находится приложение, в зависимости от того, что вы указали, а также от платформы. В будущем вы сможете отслеживать количество кликов по этой ссылке, или создавать больше быстрых ссылок для других целей.
Далее будет предложено добавить какую-либо информацию о приложении, а также указать схему URI, с помощью которой Branch будет открывать приложение. Её можно задать в формате вашеприложение://
Кроме того, на этой странице вы увидите инструкции по тому, как добавить Branch в свой проект и запустить его. Этот шаг можно пропустить сделать позднее, а сейчас перейти в панель управления.
На этом настройка на сайте завершена, и можно перейти к добавлению Branch в наше приложение. Если вы пропустили шаг с инструкциями и хотите их прочитать, вы можете на панели управления в меню нажать Set Up SDK.
Настройка Branch в приложении
Для начала вам нужно добавить библиотеку в зависимости проекта. Для этого откройте build.gradle модуля приложения и в блоке dependencies добавьте следующую строку.
dependencies
Важно учесть, что для работы библиотеки требуется минимальная версия SDK проекта 15. Если у вас указана версия ниже, вы должны либо повысить версию, либо добавить в проект библиотеку с версией не 2.+, а 1.14.5, однако функционал этой версии меньше, чем в актуальной.
Затем нужно в манифест приложения добавить необходимые теги. Откройте файл AndroidManifest.xml и добавьте в тег активности, на которой вы хотите запустить Branch, следующий код.
Вот этот код нужно добавить в конец тега .
Теперь нам нужно добавить в класс, наследующий от Application. Если у вас его нет, его можно легко создать, для этого в манифесте у тега добавьте атрибут android_name=»Имя класса». Поставьте курсор на имени класса и нажмите Alt + Enter, выберите Create class и Android Studio сама всё сделает.
В классе Application в метод onCreate() добавьте следующую строку.
Branch.getAutoInstance(this);
Затем в классе активности, для которой мы подключали в манифесте Branch, нужно добавить в метод onStart() следующий код, отвечающий за инициализацию библиотеки.
Кроме того, в классе активности нужно будет переопределить метод onNewIntent().
На этом настройка окончена, теперь при запуске или установке приложения в панели управления Branch на вкладке Liveview можно увидеть данные об устройстве, на котором запущено приложение, а также время и некоторую другую информацию.
Подключение реферальных ссылок
Сейчас в приложении есть кнопка «Поделиться», с помощью которой можно отправить простое сообщение кому-либо. Изменить принцип её работы, добавив в неё создание и отправку реферальной ссылки.
При нажатии на «Поделиться», пользователь увидит диалоговое окно с просьбой ввести своё имя.
Это имя впоследствии будет указано у человека, который установит себе приложение по созданной реферальной ссылке. Код диалогового окна выглядит следующим образом.
Если поле заполнено и нажата кнопка ОК, запустится метод genLink(), создающий реферальную ссылку. Код метода представлен ниже.
Здесь задаются такие данные, как название приложения, его краткое описание, ссылка на скачивание, а также имя из диалогового окна. В результате выполнения метода пользователю будут предложены приложения на его устройстве, с помощью которых он может поделиться ссылкой с другими людьми.
Например, можно отправить SMS-сообщение с реферальной ссылкой.
Перейдя по ней, пользователь попадёт в Google Play и, установив и запустив приложение, увидит имя человека, который поделился ссылкой. Все эти операции (создание ссылки, клики по ней) отслеживаются также на вкладке Liveview панели управления.
Отправка событий в Branch
Допустим, стоит задача проанализировать, какие слова чаще всего ищут люди в словаре. Это можно легко реализовать с помощью отправки событий в панель управления. Для этого в метод, где происходит поиск слов, добавим следующий код.
Метод userCompletedAction() посылает событие «search» с параметрами params, которые представляют из себя обычную JSON-строку. На панели управления она отобразится в следующем виде.
Источник: android-tools.ru
Жизнь — это движение! А тестирование — это жизнь 🙂
— Бранч — это отдельная ветка в коде. Вот смотрите, мы сейчас работаем в trunk-е, основной ветке.
Когда мы только-только добавили наш код на сервер, у нас появилась «точка возврата» — сохраненная версия кода, к которой мы можем обратиться в любой момент.
Потом разработчик добавляет новый функционал и коммитит его — это версия 1 кода.
При этом в самой VCS сохранены все версии, и мы всегда можем:
- Посмотреть изменения в версии 1
- Сравнить файлы из версии 1 и версии 2 — система наглядно покажет, где они совпадают, а где отличаются
- Откатиться на прошлую версию, если версия 2 была ошибкой.
Потом разработчик снова добавляет код — это версия 3.
И так далее — сколько сделаем коммитов, столько версий кода в репозитории и будет лежать. А если мы хотим сделать бранч, то система копирует актуальный код и кладет отдельно. На нашем стволе появляется новая ветка (branch по англ. — ветка). А основной ствол обычно зовут trunk-ом.
Теперь, если я захочу закоммитить изменения, они по-прежнему пойдут в основную ветку. Бранч при этом трогать НЕ будут (изменения идут в ту ветку, в которой я сейчас нахожусь. В этом примере мы создали branch, но работать продолжаем с trunk, основной веткой)
Так что мы можем смело коммитить новый код в trunk. А для показа заказчику использовать branch, который будет оставаться стабильным даже тогда, когда в основной ветке всё падает из-за кучи ошибок.
С бранчами мы всегда будем иметь работающий код!
Вы можете спросит — «Зачем эти сложности? Мы ведь всегда может просто откатиться на нужную версию! Например, на версию 2. И никаких бранчей делать не надо!».
Это верно. Но тогда нужно будет всегда помнить, в какой точке «всё работает и тут есть все нужные функции». А если делать говорящие названия бранчей, обратиться к ним намного проще. К тому же иногда надо вносить изменения именно в тот код, который на продакшене (то есть у заказчика).
Допустим, мы выпустили сборку 3, идеально работающую. Спустя неделю Заказчик ее установил, а спустя месяц нашел баг. У нас за эти недели уже 30 новых коммитов есть и куча изменений.
Заказчику нужно исправление ошибки, но он не готов ставить новую версию — ведь ее надо тестировать, а цикл тестирования занимает неделю. А баг то нужно исправить здесь и сейчас! Получается, нам надо:
- Обновиться на версию 3
- Исправить баг локально (на своей машине, а не в репозитории)
- Никуда это не коммитить = потерять эти исправления
- Собрать сборку локально и отдать заказчику
- Не забыть скопипастить эти исправления в актуальную версию кода 33 и закоммитить (сохранить)
Что-то не очень весело. А если нужно будет снова дорабатывать код? Искать разработчика, у которого на компьютере сохранены изменения? Или скопировать их и выложить на дропбокс? А зачем тогда использовать систему контроля версий?
Именно для этого мы и бранчуемся! Чтобы всегда иметь возможность не просто вернуться к какому-то коду, но и вносить в него изменения. Вот смотрите, когда Заказчик нашел баг, мы исправили его в бранче, а потом смерджили в транк.
Смерджили — так называют слияние веток. Это когда мы внесли изменения в branch и хотим продублировать их в основной ветке кода (trunk). Мы ведь объединяем разные версии кода, там наверняка есть конфликты, а разрешение конфликтов это merge, отсюда и название!
Если Заказчик захочет добавить новую кнопочку или как-то еще изменить свою версию кода — без проблем. Снова вносим изменения в нужный бранч + в основную ветку.
Веток может быть много. И обычно чем старше продукт, тем больше веток — релиз 1, релиз 2. релиз 52.
Есть программы, которые позволяют взглянуть на дерево изменений, отрисовывая все ветки, номера коммитов и их описание. Именно в таком стиле, как показано выше =) В реальности дерево будет выглядеть примерно вот так (картинка из интернета):
А иногда и ещё сложнее!
— А как посмотреть, в какой ветке ты находишься?
— О, для этого есть специальная команда. Например, в Mercurial это «hg sum»: она показывает информацию о том, где ты находишься. Вот пример ее вызова:
D:vcs_projecttest>hg sum parent: 3:66a91205d385 tip Try to fix bug with device branch: default
В данном примере «parent» — это номер коммита.
Мы ведь можем вернуться на любой коммит в коде. Вдруг мы сейчас не на последнем, не на актуальном? Можно проверить. Тут мы находимся на версии 3. После двоеточия идет уникальный номер ревизии, ID кода.
Потом мы видим сообщение, с которым был сделан коммит. В данном случае разработчик написал «Try to fix bug with device».
И, наконец, параметр «branch»! Если там значение default — мы находимся в основной ветке. То есть мы сейчас в trunk-е. Если бы были не в нём, тут было бы название бранча. При создании бранча разработчик даёт ему имя.
Оно и отображается в этом пункте.
Отдельно хочу заметить, что бранчевание на релиз — не единственный вариант работы с VCS. Есть и другой подход к разработке — когда транк поддерживают в актуальном и готовом к поставкам состоянии, а все задачи делают в отдельных ветках. Но его мы в этой статье рассматривать не будем.
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Источник: okiseleva.blogspot.com