Время на прочтение
7 мин
Количество просмотров 45K
Для расширения функциональности Bitrix24 удобно использовать приложения. В данной статье описано создание с нуля локального serverless приложения.
Для установки нашего приложения нам понадобится собственно портал bitrix24, в котором мы обладаем правами администратора или правом установки и редактирования приложений.
Если такого портала нет — создать его можно здесь.
Панель управления приложениями доступна по адресу https://<your-portal-name>.bitrix24.com/marketplace/local/
.
Выбираем пункт Для личного использования
. После нажатия кнопки Добавить
мы попадаем в диалог создания приложения.
Здесь нам нужно будет остановится, так как добавлять пока нечего. Оставим вкладку браузера открытой и приступим к созданию нашего приложения.
Официальная javascript-библиотека
Создадим папку с произвольным названием и в ней единственный пока файл index.html
со следующим содержанием (исходный код):
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Bitrix24 app tutorial</title>
<!-- подключаем библиотеку BX24 -->
<script src="https://api.bitrix24.com/api/v1/"></script>
</head>
<body>
<script>
/**
* передаем методу `init` в качестве параметра callback-функцию
* - наше приложение
*/
BX24.init(app);
function app() {
const initDate = BX24.getAuth();
console.log("ititDate: ", initDate);
}
</script>
</body>
</html>
Помещаем файл index.html
в zip-архив и указываем этот архив в качестве значения поля Загрузите архив с вашим приложением (zip)*
в диалоге создания приложения.
Затем нажимаем кнопку «Сохранить»
Посмотрим, что у нас получилось.
Кликаем по Перейти к приложению
и видим… пустое место на месте нашего приложения.
Все необходимое для нас на данном этапе находится сейчас в консоли разработчика.
Мы видим, что наше приложение успешно получило данные необходимые для авторизации.
Официальная javascript-библиотека c promise
Использование callback-функций имеет свои преимущества, но не всем нравится или не всегда подходит к ситуации.
Поэтому попробуем получить тот же результат в promise-стиле. Для этого изменим наш index.html
(исходный код)
<body>
<script>
/**
- * передаем методу `init` в качестве параметра callback-функцию
- * - наше приложение
- */
- BX24.init(app);
+ * оборачиваем метод `init` в promise
+ */
+ var bx24Promise = new Promise(function(resolve, reject) {
+ try {
+ BX24.init(resolve);
+ } catch (err) {
+ resolve(err);
+ }
+ });
+
+ bx24Promise
+ .then(function() {
+ app();
+ })
+ })
+ .catch(function(err) {
+ console.error(err);
+ });
После этого переходим https://<your-portal-name>.bitrix24.com/marketplace/local/list/
.
Переходим к редактированию нашего приложения. Измененный файл index.html
помещаем в zip-архив и обновляем его в нашем приложении.
Смотрим результат — все работает.
Если откроем файл index.html
в браузере локально, то увидим, что обработка ошибок тоже работает.
Неофициальная библиотека BX24
Если вы планируете писать приложение на typescript (можно использовать и с javascript) и/или обладаете умеренным авантюризмом, то можно попробовать использовать сторонние библиотеки для авторизации.
Например эту.
В этом случае наш index.html
нужно будет изменить следующим образом (исходный код):
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Bitrix24 app tutorial</title>
<!-- подключаем библиотеку BX24 -->
- <script src="https://api.bitrix24.com/api/v1/"></script>
+ <script src="https://unpkg.com/bx24@latest/lib/index.js"></script>
</head>
<body>
<script>
- /**
- * оборачиваем метод `init` в promise
- */
- var bx24Promise = new Promise(function(resolve, reject) {
- try {
- BX24.init(resolve);
- } catch (err) {
- resolve(err);
- }
- });
+ var bx24 = new BX24();
- bx24Promise
- .then(function() {
- app();
+ bx24.getAuth()
+ .then(function(auth) {
+ console.log(auth);
})
- .catch(function(err) {
- console.error(err);
- });
-
- function app() {
- const initDate = BX24.getAuth();
- console.log("ititDate: ", initDate);
- }
</script>
</body>
</html>
Опять архивируем, опять обновляем наше приложение, опять смотрим, опять все работает.
Инструменты разработки
Полагаю, что к этому времени вы уже достаточно устали от процедуры архивирования и обновления приложения.
Попробуем сделать процесс разработки чуть более удобным и быстрым.
Для этого нам понадобится nodejs .
Проверить его наличие на компьютере можно выполнив:
node -v
В папке нашего проекта инициализируем npm:
npm init -y
Установим необходимые пакеты:
npm i axios react react-dom bx24
npm i -D parcel-bundler express
Можно аналогично создать проект с помощью create-react-ap
или angular-cli
.
Состояние проекта после всех изменений можно посмотреть здесь.
Создадим в корне нашего проекта файл server.js
const express = require('express');
const app = express();
const port = process.env.PORT || 3000;
const www = process.env.WWW || './dist';
app.use(express.static(www));
console.log(`serving ${www}`);
app.get('*', (req, res) => {
res.sendFile(`index.html`, { root: www });
});
app.post('*', (req, res) => {
res.sendFile(`index.html`, { root: www });
});
app.listen(port, () => console.log(`listening on http://localhost:${port}`));
Этот файл нам нужен для запуска сервера. Встроенные в create-react-app
и angular-cli
серверы не подойдут, так как сервер стороннего приложения должен отвечать на POST запросы. Для всех, кроме 127.0.0.1
есть еще требования к наличию https
.
Создадим папки src
и public
В папку public
перенесем index.html
и изменим его содержимое на:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Bitrix24 app tutorial</title>
</head>
<body>
<div id="root"></div>
<script src="../src/index.js">
</script>
</body>
</html>
В папке src
создадим файлы
// src/index.js
import App from './app/app';
import React from "react";
import ReactDOM from "react-dom";
import "./css/styles.css";
const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);
// app/app.js
import React, { Component } from "react";
import getCurrentUser from "./services/get-current-user.service";
class App extends Component {
constructor(props) {
super(props);
this.state = {
loading: true
};
getCurrentUser().then(currentUser => {
this.setState({
user: currentUser,
loading: false
});
});
}
render() {
if (!this.state.loading) {
return (
<div className="App">
<h1>
Hello {this.state.user.LAST_NAME} {this.state.user.NAME}
</h1>
<h2>Start editing to see some magic happen!</h2>
</div>
);
} else {
return (
<div>Загрузка...</div>
)
}
}
}
export default App;
// app/services/get-current-user.service.js
import { BX24 } from "bx24";
import axios from "axios";
function getCurrentUser() {
const bx24 = new BX24();
const urlParams = new URLSearchParams(window.location.search);
const baseUrl = `
${urlParams.get("PROTOCOL") === 0 ? "https" : "http"}://${urlParams.get("DOMAIN")}
`;
const currentUserPromise = new Promise((resolve, reject) => {
bx24.getAuth().then(auth => {
axios({
method: "get",
url: baseUrl + "/rest/user.current?auth=" + auth.ACCESS_TOKEN
}).then(response => {
resolve(response.data.result);
});
});
});
return currentUserPromise;
}
export default getCurrentUser;
Если package.json
еще не создан, выполним:
npm init -y
Добавим скрипты в package.json
:
"scripts": {
//
"start": "node server.js",
"watch": "parcel watch ./public/index.html"
}
Далее так как и команда start
и команда watch
не заканчиваются, их нужно запускать параллельно. Для этого в двух командных строках запускаем
npm run watch
и
npm run start
Завершим настройку среды разработки редактированием нашего приложения в Bitrix24.
Перейдем в диалог редактирования нашего приложения и укажем в поле
Укажите ссылку*
значение http://127.0.0.1:3000/
Перейдите к просмотру вашего приложения:
Вы должны увидеть приветствие с именем текущего пользователя:
Если использовать официальную библиотеку, то отличаться будут только два файла:
// src/app/serviced/get-current-user.service.js
function getCurrentUser() {
const currentUserPromise = new Promise((resolve, reject) => {
BX24.init(function() {
BX24.callMethod("user.current", {}, function(res) {
resolve(res.answer.result);
});
});
});
return currentUserPromise;
}
export default getCurrentUser;
и
<!-- public/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Bitrix24 app tutorial</title>
<script src="https://api.bitrix24.com/api/v1/"></script>
</head>
<body>
<div id="root"></div>
<script src="../src/index.js">
</script>
</body>
</html>
Итоговый код проекта для использования официальной библиотеки здесь.
Ознакомиться со всеми возможными методами и возможностями API можно здесь.
Исходный код можно увидеть здесь.
И последнее замечание. Описанные выше способы и методы не являются набором лучших практик. Это скорее предложение к конструктивному обсуждению.
UPD: желающих высказаться о 1С-Битрикс или Битрикс24 прошу сделать небольшое интеллектуальное усилие и осознать, что статья не о Битрикс24 и совсем не о 1С-Битрикс.
Это если в Питере прохожий объясняет другому, как пройти к Петропавловской крепости и тут третий вмешивается с репликой:
«Да тиран был ваш Петр I. Тиран и деспот. И усы у него дурацкие».
Если есть конструктивные замечания к коду в СТАТЬЕ или к подходам или к используемым паттернам — добро пожаловать.
Содержание
- Мобильное приложение 3.x
- Мобильное приложение
- Создание мобильного приложения
- Регистрация в программе для разработчиков
- Форма заявки на компиляцию
- Вкладка «Общие»
- Вкладка «Графические ресурсы»
- Вкладка «App Store Connect»
- Вкладка «Google Play»
- Статусы публикации приложения
- Комментарии к заявке
- Конструктор мобильных приложений
- Офлайн-режим в BitrixMobile
- Настройка в конструкторе приложений
- Итоговая файловая структура офлайн-ресурсов
- Офлайн-страница
- Обращение к ресурсам через API
- Контекст офлайн-страниц
- Запросы и кэширование данных
- Работа с базой данных
- Тестирование
- Пример приложения
- Отладка приложения на BitrixMobile
- Push-уведомления
- Идентификатор приложения
- Токены
- Уведомления
- Тестирование
- Генерация ключей для push-уведомлений (Android)
- Гарантии доставки push-уведомлений
- API
- BXMobileApp.UI.Slider — управление слайдером
- UI.Slider.setState
- UI.Slider.setStateEnabled
- BXMobileApp.UI.Photo — показ фото или фото ряда
- UI.Photo.show
- BXMobileApp.UI.Document — просмотр документов
- UI.Document.open
- BXMobileApp.UI.DatePicker — контрол выбора даты
- UI.DatePicker.show
- UI.DatePicker.hide
- BXMobileApp.UI.SelectPicker — контрол выбора значений
- UI.SelectPicker.show
- BXMobileApp.UI.BarCodeScanner — сканер bar-кодов
- UI.BarCodeScanner.open
- BXMobileApp.UI.Table — управление списками
- Формирование источников данных для нативных списков
- Пример 1
- Пример 2
- Пример 3
- BXMobileApp.UI.Page — управление страницей (экраном)
- UI.Page.isVisible
- UI.Page.reload
- UI.Page.close
- UI.Page.captureKeyboardEvents
- BXMobileApp.PageManager — менеджер страниц
- PageManager.loadPageBlank
- PageManager.loadPageStart
- PageManager.loadPageModal
- PageManager.setWhiteList
- BXMobileApp.UI.Page.TextPanel — нативная панель ввода текста
- UI.Page.TextPanel.show
- UI.Page.TextPanel.hide
- UI.Page.TextPanel.setParams
- UI.Page.TextPanel.setUseImageButton
- UI.Page.TextPanel.setText
- UI.Page.TextPanel.focus
- UI.Page.TextPanel.clear
- UI.Page.TextPanel.showLoading
- BXMobileApp.UI.Page.TopBar — навигационная панель
- UI.Page.TopBar.hide
- UI.Page.TopBar.show
- UI.Page.TopBar.addRightButton
- UI.Page.TopBar.setColors
- UI.Page.TopBar.updateButtons
- BXMobileApp.UI.Page.TopBar.title — управление заголовком
- UI.Page.TopBar.title.setText
- UI.Page.TopBar.title.setDetailText
- UI.Page.TopBar.title.setImage
- UI.Page.TopBar.title.setCallback
- UI.Page.TopBar.title.show
- UI.Page.TopBar.title.hide
- BXMobileApp.UI.Page.SlidingPanel — скользящая панель
- UI.Page.SlidingPanel.show
- UI.Page.SlidingPanel.hide
- BXMobileApp.UI.Page.LoadingScreen — экран загрузки
- UI.Page.LoadingScreen.show
- UI.Page.LoadingScreen.hide
- UI.Page.LoadingScreen.setEnabled
- BXMobileApp.UI.Page.Scroll — управление скроллингом
- UI.Page.Scroll.setEnabled
- BXMobileApp.UI.Page.Refresh — контрол обновления
- UI.Page.Refresh.setParams
- UI.Page.Refresh.setEnabled
- UI.Page.Refresh.start
- UI.Page.Refresh.stop
- BXMobileApp.UI.ActionSheet — выпадающее меню
- UI.ActionSheet.show
- BXMobileApp.UI.Menu — контекстное меню
- UI.Menu.show
- UI.Menu.hide
- BXMobileApp.UI.NotificationBar — локальные уведомления
- BXMobileApp.UI.Badge — управление бейджами
- UI.Badge.setIconBadge
- UI.Badge.setButtonBadge
Мобильное приложение 3.x
С помощью нового продукта «1С-Битрикс: Мобильное приложение» можно создавать свои мобильные приложения с использованием Javascript и HTML5, что существенно дешевле и значительно быстрее нативной разработки.
Внимание! «Мобильное приложение» на данный момент не допускает добавление сторонних плагинов.
Системные требования
Минимальные версии систем:
- iOS 9.0 или более поздняя версия. Совместимо с iPhone, iPad и iPod touch.
- Android 4.4 и выше
Максимальные размеры приложений:
- iOS — не более 500 Mb
- Android — не более 100 Mb
В данной главе рассказывается как разрабатывать свои мобильные приложения.
Мобильное приложение
Внимание! Продажа (а так же поддержка и дальнейшее развитие) модуля Мобильное приложение (mobileapp) прекращена. Инструкция рабочая для уже приобретённых и активных лицензий.
C чего начать?
- Установить приложение для разработчиков из Google Play или AppStore. При запуске приложения появляется форма для ввода некого адреса, которого пока нет.
- Далее на установке «1С-Битрикс: Управление сайтом» необходимо:
- Установить модуль Мобильная платформа.
- Выбрать место расположения мобильного приложения. Например, это будет папка
/myfirst_app/
. - Создать файлы
/myfirst_app/left.php
и/myfirst_app/index.php
. - Шаблон сайта не должен отличаться от тех шаблонов, которые создаются для обычных сайтов. Единственное отличие — это присутствие в header.php следующего:
if (CModule::IncludeModule("mobileapp")) CMobile::Init();
Т.е чтобы создать шаблон мобильного приложения, нужно вызвать метод CMobile::Init() в стандартном шаблоне сайта. С помощью этого метода инициализируются нужные константы, подключаются нужные JS-скрипты, соответствующие платформе клиента (iOS или Android), создаются нужные объекты и т.п.
- Далее в настройках сайта назначить созданный шаблон сайта для папки
/myfirst_app/
. Рекомендуется поставить сортировку подключения шаблонов 0 или 1. - И последний шаг — создать в папке
/myfirst_app/
файл config.php. При обращении к файлу должен возвращаться JSON.
Файл должен быть следующего содержания:<? header("Content-Type: application/x-javascript"); $config = array( "appmap" => array( "main"=>"/myfirst_app/index.php", "left"=>"/myfirst_app/left.php" ) ); echo json_encode($config); ?>
где:
main
— стартовая страница приложения;
left
— страница, которая загружается в левую часть слайдера.
- После этого появится адрес, который нужно ввести в форме приложения для разработки п.1 — http://my_site/myfirst_app/.
Меню приложения
Теперь приложение может подключаться к сайту и показывать контент. После подключения уже разработчик должен обеспечить корректную навигацию по приложению. Поэтому, необходимо меню. Его часто располагают в левой части слайдера.
Согласно содержанию config.php, в качестве страницы для левой части слайдера загружается /myfirst_app/left.php
.
Давайте расположим в этом файле компонент bitrix: mobileapp.menu — компонент меню:
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php"); $arParams = array( "MENU_FILE_PATH" => SITE_DIR . "myfirst_app/.mobile_menu.php", ); $APPLICATION->IncludeComponent( 'bitrix:mobileapp.menu', 'mobile', $arParams, false, Array('HIDE_ICONS' => 'Y')); ?> <script type="text/javascript"> app.enableSliderMenu(true); </script> <? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/footer.php") ?>
На вход компоненту отдаем параметр MENU_FILE_PATH
— путь к файлу меню.
Разместим этот самый файл меню по нужному пути.
<? IncludeModuleLangFile(__FILE__); $arMobileMenuItems = array( array( "type" => "section", "text" =>"Раздел меню", "sort" => "100", "items" => array( array( "text" => "Новый пункт меню!", "data-url" => SITE_DIR."myfirst_app/test.php", "class" => "menu-item", "id" => "main", "data-pageid"=>"main_page" ) ) ) ); ?>
Структура меню проста. Есть секции. Каждый пункт меню снабжается нужными атрибутами:
text
— название пункта;data-url
— куда будем переходить при клике по пункту;class
— css-класс пункта меню;id
— идентификатор;data-pageid
— идентификатор, который учитывается приложением. При клике на пункт страница прогрузится и закешируется. Таким образом, в дальнейшем она всегда будет открываться мгновенно, но за актуальностью контента на этой странице придется следить.
В итоге получим вот такое меню:
Что такое app?
В исходном коде страницы меню есть вызов функции app.enableSliderMenu(true) — разблокировка слайдера. Что за объект app? Это объект библиотеки BitrixMobile 2.0, который как раз и позволяет управлять приложением. При вызове в шаблоне приложения CMobile::Init() объект app становится доступным. Этот объект содержит множество полезных функций, которые описаны далее в курсе и в файле /bitrix/js/mobileapp/bitrix_mobile.js
Страницы, таблицы
Разместим нашу страницу /myfirst_app/test.php
, на которую ссылается созданный пункт меню:
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php"); ?> <script type="text/javascript"> function openTable() { app.openBXTable({ url: "/myfirst_app/list.php", TABLE_SETTINGS: { alphabet_index: false, // Выключим алфавитный индекс showtitle: true, //Покажем тайтл cache: false,// не кэшируем name: "Разделы", // callback: function (data) { alert(JSON.stringify(data)); } } }); } //добавить кнопку app.addButtons( { menuButton: { type: 'plus', style: 'custom', callback: function () { app.menuShow(); //app.openNewPage("/myfirst_app/test2.php"); } } } ); //добавить меню app.menuCreate({ items: [ { name: "Открыть страницу", action: function () { // alert("Hello"); app.openNewPage("/myfirst_app/test2.php"); } }, { name: "bitrix", url: "http://bitrix.ru", icon: 'settings' } ] }); //title app.setPageTitle({ title: "MyFirstApp" }); //pull-down-to-refresh app.pullDown({ enable: true, callback: function () { document.location.reload(); }, downtext: "Тяни...", pulltext: "Отпускай...", loadtext: "Жди..." }); </script> <button style="width:100%;height:50px" onclick="openTable();">Table</button> <? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/footer.php") ?>
Далее необходимо создать /myfirst_app/list.php
с таким содержанием:
<? require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php"); $data = Array( "data"=>Array( "company"=>Array( Array( "ID"=>1, //идентификатор записи "NAME"=>"Google", //имя для отображения "URL" => "http://google.ru", "IMAGE"=>"http://www.mintfo.com/wp-content/uploads/2012/08/New-blue-logo-Google-revamps-mainpage-favicon-300x300.png", "TAGS" => "Заграничный поисковик", "SECTION_ID"=>"milk"//принадлежность к секции ), Array( "ID"=>2, "NAME"=>"Bitrix", "SECTION_ID"=>"meat", "IMAGE"=>"http://www.incr.ru/img/bitrix-logo.png", "TAGS"=>"Отечественная CMS", "URL"=>"http://bitrix.ru" ), Array( "ID"=>3, "NAME"=>"Yandex", "SECTION_ID"=>"meat", "IMAGE"=>"http://blogs.computerra.ru/wp-content/uploads/2012/10/yandex-browser-logo-289x300.jpg", "TAGS" => "Свой домашний браузер", "URL"=>"http://yandex.ru" ) ), ), "names"=>Array("company"=>"Компании") ); $data = $APPLICATION->ConvertCharsetArray($data, "windows-1251","utf-8"); $APPLICATION->RestartBuffer(); echo json_encode($data); die();
Запустим приложение и перейдем по пункту Новый пункт меню — увидим страницу с кнопкой + на панели с заголовком Потяни,чтобы-обновить и кнопкой Table. Нажмем на кнопку Table — откроется таблица c данными.
События
В мобильном приложении есть события, которые позволяют гибко решать множество задач. Обрабатывать эти события просто. Например:
BX.addCustomEvent("onOpenPageAfter", function(){ setTimeout(function(){ app.closeController(); },2000); });
Размещая этот код, мы как бы говорим странице: «После открытия закройся обратно через 2 секунды.»
Таким образом, мы получили скелет приложения — навигацию и первую страницу. За основу также можно взять уже готовое решение Мобильный интернет-магазин (модуль eshop_app).
Создание мобильного приложения
В данном разделе рассказывается, как создать аккаунты в программе для разработчиков и даны рекомендации по всем пунктам заполнения данных в Форме заявки на компиляцию.
Регистрация в программе для разработчиков
Остановимся более подробно на создании аккаунтов на Google Play и Apple Developer Center.
Регистрация в программе для разработчиков
Итак, регистрация в программе для разработчиков — для чего это нужно? Регистрация в программе разработчиков дает возможность публикации ваших приложений в магазинах приложений Google Play и AppStore.
- Google Play
Чтобы стать участником программы для разработчиков Google Play, нужно иметь аккаунт Google. Зарегистрироваться можно по адресу.
Далее Ваш аккаунт нужно зарегистрировать в Google Play. Сделать это можно по следующему адресу.
- Apple Developer Center
Для того, чтобы стать участником программы для разработчиков Apple Developer Center, нужно иметь аккаунт AppleID. Зарегистрироваться можно по адресу.
После этого, аккаунт нужно зарегистрировать в Apple Developer Center. Сделать это можно по следующему адресу, войдя под своим AppleID (или ссылка Account в правом верхнем углу на сайте Apple Developer Center).
Поздравляем! Вы теперь участник программы разработчиков.
Внимание! Сроки регистрации могут варьироваться и зависеть от предыдущих попыток заявителя получить регистрацию программ, загруженности отдела поддержки разработчиков Google и Apple пр. Рабочий день — день, в который одновременно работают государственные учреждения в США и России.
Форма заявки на компиляцию
После того, как прошли процедуру посвящения в программу разработчиков, приступаем к заполнению Формы заявки на компиляцию. Сама форма не сложна, но есть наиболее часто встречающиеся ошибки в ее заполнении. Давайте рассмотрим их.
Вкладка «Общие»
Лицензионный ключ
Сборка приложения производится только при активном лицензионном ключе «1С-Битрикс: Мобильное приложение». В случае, если срок действия лицензионного ключа истек, сборка производится не будет. Чтобы избежать это, своевременно продлевайте срок действия лицензионного ключа.
Название приложения
Используется для отображения в магазинах приложений Google Play и App Store. Имеется ограничения по количеству символов:
- Google Play — максимально 30 символов.
- App Store — максимально 50 символов.
Рекомендации:
Название приложения играет важную роль в поиске и обнаружении приложения пользователями. Простое и легко запоминающееся название может способствовать более успешному поиску. Название должно отражать суть работы приложения, быть понятным и уместным. Рекомендуется использовать как можно более короткие и актуальные названия.
- Название должно быть коротким. Оптимальным образом на страницах приложения в App Store и Google Play, выглядят названия приложений длиной не более 25 символов. В то же время длина названия не единственный фактор, который стоит учитывать. Обратите внимание на то, что на отображение названия может повлиять место переноса названия на новую строку. Простое название приложения выглядит лучше, чем длинное и сложное.
- Используйте простые названия. Например, Вы решили дать своему приложение следующее название — «Мое приложение — самое лучшее и самое полезное приложение для всех». Это название является слишком длинным. Лучше назвать приложение просто «Мое приложение». Все остальное можно добавить в описание приложения.
- Используйте уникальное название. Не используйте в названии похожие с имеющимися уже приложениями. Например, Вы решили дать название своему приложение имя «Фонарик». Приложение с таким названием очень много, и по названию сложно понять чем они отличаются друг от друга. Выделиться можно, если дать оригинальное названия — «Оригинальный фонарик», «Фонарик — стробоскоп» и тд. Так же, если название приложения содержит текст описания совместимости, например, «Мое приложение для iPad», данный текст не принимается во внимание при определении соответствия названия требованиям недопустимости названий-дубликатов и соблюдения авторских прав. Иными словами, например, если в App Store уже имеется приложение с названием «Мое приложение», использовать название «Мое приложение для iPad» для другого приложения будет недопустимо.
- Помните об авторском праве. Убедитесь, что название приложения не нарушает законов о товарном знаке или права третьих лиц. Например, название «1С-Битрикс Новости» будет недопустимо, поскольку «1С-Битрикс» является зарегистрированной торговой маркой. Если Вы будете использовать в названии своего приложения, имя которого является чужой торговой маркой или уже используется в App Store или Google Play, приложение будет удалено из магазинов приложений App Store или Google Play.
- Изменение названия размещенного приложения. Название размещенного приложения можно изменить только при следующем обновлении двоичного файла приложения до новой версии. В противном случае, чтобы изменить название приложения, потребуется изъять его из магазина, а затем снова предоставить.
Краткое название (например, MyShop)
Используется для отображения названия приложения на устройствах.
Рекомендации:
- Не выбирайте слишком длинные названия. Большинство приложений с длинными названиями на устройствах будут заканчиваться точками и терять ясность названия приложения. Чтобы избежать такое, разработчикам рекомендуется использовать не более 10 символов типа w, и не более 13 символов типа i. Символами считаются набор цифр и букв, знаки препинания, а так же спецсимволы. Пробел тоже считается символом.
- Краткое название должно напоминать полное имя. Выбирая краткое название для Вашего приложения помните, пользователь должен найти установленное приложение на своем устройстве. Например, в магазинах приложений App Store и Google Play Ваше приложение называется «Програбли: бизнес в Интернете без ошибок», то краткое название «Програбли» ассоциируются с полным названием, и не нарушают правила публикации приложения.
Адрес подключения (с протоколом)
Укажите корректный адрес приложения в формате: <протокол>://<домен>/<имя_папки>
.
Контактный email
Укажите контактный email уполномоченного лица, с которым можно связаться в случае возникновения вопросов у наших разработчиков, или при необходимости получения дополнительной информации.
Описание приложения
Данный пункт необходим в случае, если публикацию сборки в магазинах приложений Google Play и App Store помогают оформлять наши разработчики.
Используется для описания приложения в магазинах приложений Google Play и App Store.
Рекомендации:
- В описании должно быть понятно пользователю как работает Ваше приложение, и зачем оно нужно.
- Описание не должно быть более 4000 символов для Apple Store (рекомендовано 700) и 500 символов для Google Play.
- Избегайте технических деталей.
- Не пренебрегайте абзацами. Варьируйте длину предложения — это делает текст более выразительным. Используйте разрывы линии и маркеры, для того, чтобы увеличить четкость.
Дополнительная информация
В данном поле можно указать определенные условия сборки. Например, сборка должна быть только для телефонов, или только в портретном режиме. Либо, другую, необходимую информацию, для наших разработчиков.
Платформа
Укажите, на какой платформе необходима Вам сборка. На данный момент, сборки могут быть собраны на платформах iOS и Android. В течение срока действия лицензионного ключа, вы можете запросить, по мере необходимости, сборку либо на обе платформы, либо на конкретную платформу.
Буду публиковать сам
Данный способ подходит тем, кто уже публиковал самостоятельно свои сборки в магазинах приложений App Store и Google Play, и имеет представления о Сертификатах (Certificates), Идентификаторах приложений (Identifiers), о Профилях (Provisioning Profiles), сертификатах PKCS12, и знаком с сервисами Google..
В первую очередь, нашим разработчикам необходима информация о созданном уникальном идентификаторе приложения (Bundle ID).
Для возможности сборки Вашего приложения на платформе iOS, нашим разработчикам необходимо прислать: сгенерированные аккаунтом для разработчиков iOS Certificates,
сертификат .p12 и iOS Provisioning Profiles для публикации (есть еще для разработчиков, их высылать не надо).
На основе этих сертификатов и Provisioning Profiles, наши разработчики соберут бинарный файл для публикации и передадут его Вам.
Если Вам необходимо будет использование push-уведомлений на платформе iOS, нашим разработчикам также нужен сгенерированный сертификат для push-уведомлений (Apple Push Service).
Если Вы планируете использование push-уведомлений в Вашем приложении на платформе Android, то Вам необходимо прислать нашим разработчикам сгенерированные ключи сервиса Google Cloud Messaging.
Пошаговая инструкция:
- войдите в консоль с помощью Вашего оплаченного аккаунта по адресу: https://console.cloud.google.com;
- выберите Create Project, укажите Project name, нажмите Create;
- перейдите в созданный Project, откройте меню -> API Manager, на вкладке Google APIs в разделе Mobile APIs найдите и нажмите на Google Cloud Messaging -> Enable;
- перейдите в раздел Credentials -> Create credentials -> API key -> Server key -> Name любое, IP address пустой -> Create;
- пришлите нам Key, который был создан в п.4;
- откройте меню -> Home, разверните поле с заголовком Project: <имя Вашего проекта> и пришлите нам также Project ID и Project number.
Примечание: Если Вы не планируете использовать push-уведомления в текущей версии сборки, но планируете использовать push-уведомления в дальнейшем, то для подключения сервиса push-уведомлений необходимо будет выпускать обновление приложения.
Вкладка «Графические ресурсы»
Иконки приложения
Важно!
- Весь графический материал должен быть только в формате PNG!
- Весь графический материал не должен иметь альфа-каналы!
- Проверьте формат графического материала, чтобы он не был другого формата. Например, изображение может быть формата jpg, но с переименованным расширением png.
Иконки используются в сборке приложения, и при оформлении заявки в магазинах приложений Google Play и App Store. Для сборки на платформе iOS необходима иконка размером 1024×1024 пикселей, для сборки на платформе Android иконка должна иметь размер 512×512 пикселей.
Рекомендации:
- Иконка должна соответствовать Вашему приложению и не вводить пользователей в заблуждение.
- Иконка должна быть квадратной. Устройства автоматически закругляют картинки под нужный угол.
- Иконка не должна иметь эффект глянца или тени. Устройства автоматически добавляют эффекты иконкам.
- Не увеличивайте изображения, если изначально картинка имеет маленькое разрешение.
- Иконка должна быть достаточно простой, чтобы одинаково хорошо смотреться и на экранах ультравысокой четкости Retina Display, и на странице Вашего приложения в магазинах приложений Google Play и App Store, и даже в меню настроек. Не пытайтесь втиснуть много деталей в ограниченное пространство. Зачастую, это может плохо маcштабироваться и выглядеть на экранах.
- Старайтесь не использовать текст. Если вы вообще можете обойтись без текста, то так и поступайте. Попробуйте использовать только символ или логотип для иконки.
Стартовые экраны
Стартовый экран — это окно, которое отображается до появления основного окна приложения. Обычно это — логотип компании. Не рекомендуется делать какие-либо надписи на стартовых экранах, так как стартовый экран появляется максимум на пару секунд, надпись просто не успеют прочесть. Также на устройствах, использующих платформу Android, из-за большого количества разрешений экранов, устройство может «подрезать под экран» по краям стартовый экран, и надпись может попасть в зону «подрезания» устройством.
Стартовые экраны должны соответствовать указанным размерам:
Стартовый экран (640×1136, iPhone 5)
Стартовый экран (640×960, iPhone Retina)
Стартовый экран (750 x 1334, iPhone6)
Стартовый экран (1242×2208, iPhone6+)
Стартовый экран (768×1024, iPad Portrait, iOS7)
Стартовый экран (1024×768, iPad Landscape, iOS 7)
Стартовый экран (1536×2008, iPad Retina Portrait, Android Portrait)
Стартовый экран (1536×2048, iPad Retina Portrait, iOS 7)
Стартовый экран (2048×1496, iPad Lanscape, Android Lanscape)
Стартовый экран (2048×1536, iPad Lanscape, iOS 7)
Рекомендации:
- Неправильный стартовый экран. Текст, или логотип слишком близко к краям изображения. Некоторые устройства «подрезают« края, и надпись, или логотип могут попасть в зону «подрезания» устройством.
- Правильный стартовый экран. По возможности, старайтесь не использовать текст в Стартовых экранах. Надпись просто не успеют прочесть.
Иконка уведомления
Иконка уведомления для клиентских приложений отображается на телефонах с ОС Android 5+ в виде белого квадрата. Примерно так:
и так:
Причина этого: неправильно подготовленное изображение иконки.
Требования к изображению:
- прозрачный фон (именно из-за отсутствия прозрачности иконка выглядит как белый квадрат),
- формат PNG,
- размер 24х24.
Правильно подготовленная иконка даёт такой вид уведомлений:
и
Вкладка «App Store Connect»
Логин
Пароль
Версия
Логин (APPLE ID)
Нужен для нескольких основных целей, связанных с разработкой приложений на платформе iOS и публикации сборки в App Store. Во-первых, нужен для сборки приложения, так как аккаунт проверяется уже на этапе создания двоичного файла для публикации. Во-вторых, аккаунт разработчика Apple Developer Center нужен для создания Сертификатов (Certificates), Идентификаторов (Identifiers), Профилей (Provisioning Profiles). Все это обеспечивает управление системой сертификации ваших приложений, дающих право публикации Вашего приложения в App Store.
Примечание: Как зарегистрировать аккаунт разработчика Apple Developer Center описано в документации Apple Developer Program.
Пароль
Пароль, который Вы использовали при регистрации APPLE ID. Вы можете изменить Ваш основной пароль, на временный. После публикации приложения в App Store, Вы можете вернуть Ваш основной пароль. В этом случае, у нас не будет доступа к Вашей учетной записи, но, в случае обновления приложения, нам потребуется пароль от Вашей учетной записи снова.
Версия( XX.XX.XX, X.X…)
Номер добавляемой версии приложения. Отображается в App Store для информирования клиентов. Нумерация должна следовать типичным правилам присвоения версий программному обеспечению (например, 1.0, 1.0.1, 1.1).
Название
приложения
Название приложения в магазине приложений — то, которое будет отображаться в App Store. Его длина не может быть меньше двух символов, и не должно превышать 30 символов.
Указывается такое же Название приложения, как из вкладки Общие.
Рекомендации:
Название приложения играет важную роль в поиске и обнаружении приложения пользователями. Простое и легко запоминающееся название может способствовать более успешному поиску. Название должно отражать суть работы приложения, быть понятным и уместным. Рекомендуется использовать как можно более короткие и актуальные названия.
- Название должно быть коротким. Оптимальным образом на страницах приложения в App Store и Google Play, выглядят названия приложений длиной не более 25 символов. В то же время длина названия не единственный фактор, который стоит учитывать. Обратите внимание на то, что на отображение названия может повлиять место переноса названия на новую строку. Простое название приложения выглядит лучше, чем длинное и сложное.
- Используйте простые названия. Например, Вы решили дать своему приложение следующее название — «Мое приложение — самое лучшее и самое полезное приложение для всех». Это название является слишком длинным. Лучше назвать приложение просто «Мое приложение». Все остальное можно добавить в описание приложения.
- Используйте уникальное название. Не используйте в названии похожие с имеющимися уже приложениями. Например, Вы решили дать название своему приложение имя «Фонарик». Приложение с таким названием очень много, и по названию сложно понять чем они отличаются друг от друга. Выделиться можно, если дать оригинальное названия — «Оригинальный фонарик», «Фонарик — стробоскоп» и тд. Так же, если название приложения содержит текст описания совместимости, например, «Мое приложение для iPad», данный текст не принимается во внимание при определении соответствия названия требованиям недопустимости названий-дубликатов и соблюдения авторских прав. Иными словами, например, если в App Store уже имеется приложение с названием «Мое приложение», использовать название «Мое приложение для iPad» для другого приложения будет недопустимо.
- Помните об авторском праве. Убедитесь, что название приложения не нарушает законов о товарном знаке или права третьих лиц. Например, название «1С-Битрикс Новости» будет недопустимо, поскольку «1С-Битрикс» является зарегистрированной торговой маркой. Если Вы будете использовать в названии своего приложения, имя которого является чужой торговой маркой или уже используется в App Store или Google Play, приложение будет удалено из магазинов приложений App Store или Google Play.
- Изменение названия размещенного приложения. Название размещенного приложения можно изменить только при следующем обновлении двоичного файла приложения до новой версии. В противном случае, чтобы изменить название приложения, потребуется изъять его из магазина, а затем снова предоставить.
Краткое
название
Краткое название размещается под иконкой, используется для отображения названия приложения на устройствах.
Указывается такое же Краткое название, как из вкладки Общие.
Рекомендации:
- Не выбирайте слишком длинные названия. Большинство приложений с длинными названиями на устройствах будут заканчиваться точками и терять ясность названия приложения. Чтобы избежать такое, разработчикам рекомендуется использовать не более 10 символов типа w, и не более 13 символов типа i. Символами считаются набор цифр и букв, знаки препинания, а так же спецсимволы. Пробел тоже считается символом.
- Краткое название должно напоминать полное имя. Выбирая краткое название для Вашего приложения помните, пользователь должен найти установленное приложение на своем устройстве. Например, в магазине приложений App Store Ваше приложение называется «Програбли: бизнес в Интернете без ошибок», то краткое название «Програбли» ассоциируются с полным названием, и не нарушают правила публикации приложения.
Copyright
Название компании
Copyright
Имя лица или название организации, которым принадлежат эксклюзивные права на приложение. Указывается после года получения прав (например, 2016, Bitrix Inc.).
Название компании
Если Вы участвуете в программе Apple Developer Program как компания, то можно указать, какое название компании использовать. Параметр company name (название компании) играет в магазине важную роль при перемещениях между приложениями и их группировке. Название юридического лица отображается в графе seller (продавец) Ваших приложений. Название компании отображается в магазине вместе с Вашими приложениями.
Например, Apple – это название компании. При щелчке названия компании отображаются все ее приложения, представленные в магазине:
А Apple Distribution International – название продавца.
Внимание! Указать название компании, отличное от юридического лица, можно только один раз, при размещении первого приложения.
Имя, Фамилия,
Номер телефона (+7….)
E-Mail
Укажите Имя, Фамилию, контактный e-mail и телефон сотрудника Вашей организации, с которым можно связаться в случае возникновения вопросов у команды проверки приложений или при необходимости получения дополнительной информации.
Телефонный номер укажите в международном формате: +код страны (код города) номер телефона
.
+7 — Код России и Казахстана
+380 — Код Украины
+375 — Код Белоруссии
Логин и пароль
демо-пользователя
При наличии в Вашем приложении формы авторизации необходимо указать имя пользователя. Данная учетная запись будет использована при проверке приложения и должна действовать до полной проверки и публикации приложения.
Укажите также пароль для учетной записи демо-пользователя с полным доступом. В случае не полного доступа к функциям приложения, модераторы App Store укажут на это, и вернут приложение с указанием, на изменение метаданных.
Основная и дополнительная
категории. Ключевые слова
Основная категория
Один из важных аспектов доступности приложения — это категория, в которой оно отображается в магазине приложений App Store. Категории позволяют пользователям просматривать коллекции приложений. Постарайтесь приложить все усилия, чтобы выбрать категорию, которая наилучшим образом описывает основные функции Вашего приложения. Неправильный выбор категорий для приложения может послужить поводом возврата приложения модераторами App Store для изменения неправильно указанных категорий.
Примечание: Более подробно про категории в App Store и их описание можно прочитать в документации Apple.
Дополнительная категория
В App Store Connect приложение можно поместить в две разные категории, повышая его шансы быть замеченным пользователями.
Ключевые слова
Одно или несколько ключевых слов, описывающих приложение. Список связанных поисковых терминов, разделенных запятыми. Требуется указать как минимум одно ключевое слово длиной более двух символов. Допустимый общий объем текста — до 100 байт (примерно до 100 символов). Поиск приложения выполняется по его названию и названию компании, поэтому эти значения не нужно дублировать в списке ключевых слов. Применение названий других приложений или компаний в качестве ключевых слов запрещено.
Адрес поддержки (url)
Создайте на своем веб-сайте систему поддержки для приложения. Обеспечьте пользователям возможность без труда связаться с Вами напрямую по вопросам, касающимся приложения, а также оставить отзыв и запрос дополнительного функционала. Чтобы обеспечить безпроблемное представление, избегайте использования ссылок на блоги или страницы, содержимое которых является преимущественно динамическим. Убедитесь, что все упомянутые веб-страницы доступны, когда приложение будет готово для продажи в магазинах приложений App Store и Google Play.
Политика
конфеденциальности (url)
Способ сообщить пользователям, что именно вы о них знаете, как будете это использовать и хранить. При наличие регистрации в Вашем приложении, обязательно укажите ссылку на политику конфиденциальности. Если на Вашем сайте уже есть страница с текстом политики конфиденциальности, можно указать его.
Описание
Что нового
Геолокация
Описание (для магазина)
Локализованное подробное описание возможностей и функциональности приложения. Объем описания не должен превышать 4000 символов. Описание должно быть простым текстом с разбиением по строкам при необходимости. HTML-форматирование не допускается и не распознается. Рекомендуется проверить описание на предмет орфографических и грамматических ошибок.
Что нового
При добавлении новой версии предоставляются сведения об этой версии, дополняющие общее описание приложения в магазине.
Сообщение запроса прав на использование геолокации
При использовании в приложении данных о местоположении, у пользователей будет запрашиваться разрешение на использование геолокации. Данная фраза это текст-объяснение, зачем вам нужно разрешение на использование геолокации.
Вкладка «Google Play»
Логин
Пароль
Версия
Логин (***@gmail.com)
Необходим для подключения push-уведомлений и публикации приложений.
Пароль
Пароль, который Вы использовали при регистрации Google Play. Вы можете изменить Ваш основной пароль, на временный. После публикации приложения Вы можете вернуть Ваш основной пароль. В этом случае, у нас не будет доступа к Вашей учетной записи, но, в случае обновления приложения, нам потребуется пароль от Вашей учетной записи снова.
Версия( XX.XX.XX, X.X…)
Номер добавляемой версии приложения. Отображается в Google Play для информирования клиентов. Нумерация должна следовать типичным правилам присвоения версий программному обеспечению (например, 1.0, 1.0.1, 1.1).
Название
(для магазина)
Название должно быть уникальным и понятным. Подчеркните особенности приложения, избегая стандартных формулировок. Название должно быть коротким: длинные названия могут обрезаться на некоторых устройствах. Максимальный размер 30 символов.
Указывается такое же Название приложения, как из вкладки Общие.
Рекомендации:
Название приложения играет важную роль в поиске и обнаружении приложения пользователями. Простое и легко запоминающееся название может способствовать более успешному поиску. Название должно отражать суть работы приложения, быть понятным и уместным. Рекомендуется использовать как можно более короткие и актуальные названия.
- Название должно быть коротким. Оптимальным образом на страницах приложения в App Store и Google Play, выглядят названия приложений длиной не более 25 символов. В то же время длина названия не единственный фактор, который стоит учитывать. Обратите внимание на то, что на отображение названия может повлиять место переноса названия на новую строку. Простое название приложения выглядит лучше, чем длинное и сложное.
- Используйте простые названия. Например, Вы решили дать своему приложение следующее название — «Мое приложение — самое лучшее и самое полезное приложение для всех». Это название является слишком длинным. Лучше назвать приложение просто «Мое приложение». Все остальное можно добавить в описание приложения.
- Используйте уникальное название. Не используйте в названии похожие с имеющимися уже приложениями. Например, Вы решили дать название своему приложение имя «Фонарик». Приложение с таким названием очень много, и по названию сложно понять чем они отличаются друг от друга. Выделиться можно, если дать оригинальное названия — «Оригинальный фонарик», «Фонарик — стробоскоп» и тд. Так же, если название приложения содержит текст описания совместимости, например, «Мое приложение для iPad», данный текст не принимается во внимание при определении соответствия названия требованиям недопустимости названий-дубликатов и соблюдения авторских прав. Иными словами, например, если в Google Play уже имеется приложение с названием «Мое приложение», использовать название «Мое приложение для Android» для другого приложения будет недопустимо.
- Помните об авторском праве. Убедитесь, что название приложения не нарушает законов о товарном знаке или права третьих лиц. Например, название «1С-Битрикс Новости» будет недопустимо, поскольку «1С-Битрикс» является зарегистрированной торговой маркой. Если Вы будете использовать в названии своего приложения, имя которого является чужой торговой маркой или уже используется в App Store или Google Play, приложение будет удалено из магазинов приложений App Store или Google Play.
- Изменение названия размещенного приложения. Название размещенного приложения можно изменить только при следующем обновлении двоичного файла приложения до новой версии. В противном случае, чтобы изменить название приложения, потребуется изъять его из магазина, а затем снова предоставить.
Краткое
название
Используется для отображения названия приложения на устройствах, под иконкой.
Указывается такое же Краткое название, как из вкладки Общие.
Рекомендации:
- Не выбирайте слишком длинные названия. Большинство приложений с длинными названиями на устройствах будут заканчиваться точками и терять ясность названия приложения. Чтобы избежать такое, разработчикам рекомендуется использовать не более 10 символов типа w, и не более 13 символов типа i. Символами считаются набор цифр и букв, знаки препинания, а так же спецсимволы. Пробел тоже считается символом.
- Краткое название должно напоминать полное имя. Выбирая краткое название для Вашего приложения помните, пользователь должен найти установленное приложение на своем устройстве. Например, в магазинах приложений Google Play Ваше приложение называется «Програбли: бизнес в Интернете без ошибок», то краткое название «Програбли» ассоциируются с полным названием, и не нарушают правила публикации приложения.
Краткое
описание
Краткое и функциональное описание Вашего приложения. Выводится для смартфонов и планшетов.
Категория
Один из важных аспектов доступности приложения — это категория, в которой оно отображается в Google Play. Категории позволяют пользователям просматривать коллекции приложений. В Google Play можно выбрать только одну категорию. Постарайтесь приложить все усилия, чтобы выбрать категорию, которая наилучшим образом описывает основные функции Вашего приложения.
Примечание:Более подробно про категории в Google Play и их описание можно прочитать в документации.
Описание
Более подробное описание (для магазина), которое должно донести пользователю, как работает приложение, о его основных функциях и преимуществах и зачем оно нужно.
В мобильной версии появляется, если после краткого описания нажать «ЧИТАТЬ ДАЛЬШЕ».
- В мобильной версии Google Play:
- В веб-версии Google Play:
Статусы публикации приложения
У каждой заявки на публикацию есть статусы отдельно по каждой платформе. На странице списка приложений можно видеть соответствующие колонки.
После создания заявки присваивается статус Ожидает обработки. Как только начнется работа с заявкой, статусы начинают меняться и обо все изменениях автор заявки получает уведомления на свою почту.
Что означает каждый статус?
- Ожидает обработки
Пока ваш запрос на сборку приложения находится в очереди на обработку. Максимальное время ожидания – до 2 рабочих недель. На время ожидания может повлиять длинная очередь на сборку приложений или иные факторы. Чаще всего все происходит в течение 4-5 дней.
- Проверка заявки
Ваша заявка обрабатывается. Если все данные в заявке заполнены корректно, предоставлены все аккаунты для магазинов приложений, не требуется дополнительных данных и сервер вашего приложения доступен, то заявка скоро будет переведена в статус Публикация.
- Приостановлено, ожидаются исправления
Возможные причины приостановки проверки приложения:
- Некорректные данные для авторизации/неоплаченные аккаунты в Apple Developer Center или Google Developer Console.
- Неточности в заполнении заявки на сборку.
- Необходимость предоставления дополнительных данных (тестовых аккаунтов, информации по заполнению профиля приложения в AppStore или Google Play).
После исправления Вам нужно перейти в список ваших приложений и из контекстного меню выбрать пункт Продолжить публикацию (#PLATFORM#). Тогда разработчик продолжит работу с вашей заявкой.
- Публикация
Ваша заявка проверена и ваше приложение в процессе сборки и отправки в магазин приложений. Пока от вас ничего не требуется. Сроки публикации в AppStore для приложений на платформе iOS определить нельзя, все зависит от проверяющих Apple. В Google Play нет предварительной модерации и приложение оказывается доступным в день публикации.
- Публикация завершена
Конечный статус. Очередная версия вашего приложения опубликована в магазине приложений.
- Не удалось опубликовать
По каким-то определенным причинам публикация приложения невозможна.
Как запустить публикацию очередной версии приложения?
Все очень просто. Вам нужно перейти в список своих приложений и из контекстного меню запустить процесс публикации отдельно для каждой платформы.
Тоже самое нужно сделать, если процесс публикации был прерван проверяющим по каким-либо причинам.
Комментарии к заявке
Вы можете контактировать с проверяющими ваше приложение прямо на сайте, без необходимости переписки по e-mail.
На страницу обсуждения также можно перейти из контекстного меню в списке приложений.
После чего откроется диалог с проверяющим.
О каждом комментарии на e-mail автора заявки уходит уведомление.
Конструктор мобильных приложений
Конструктор мобильного
приложения
В обновлении модуля Мобильная платформа версии 14.5.1 появился новый функционал под названием Конструктор мобильного приложения.
Это большой шаг к упрощению процесса создания мобильных приложений на платформе «1C-Битрикс».
Какие задачи решает Конструктор мобильного приложения:
- Создание базового макета серверной части мобильного приложения на платформе BitrixMobile.
- Настройка параметров нативных элементов приложения.
- Настройка параметров мобильного приложения по платформам — Android и iOS.
Рассмотрим подробнее каждый из пунктов.
Создание серверной части
мобильного приложения
В административной части сайта нужно перейти в раздел Конструктор мобильных приложений (Сервисы > Мобильное приложение > Конструктор мобильных приложений).
Далее создаем приложение, нажав кнопку Создать приложение, появляется форма создания.
В форме создания приложения вам предлагается указать следующее:
- Название приложения.
- Код приложения (используем только латиницу и знаки подчеркивания).
- Название папки приложения, которая будет создана в корне сайта (только латиница и знаки подчеркивания).
- Шаблон приложения — можно создать новый, указав латиницей идентификатор, выбрать из существующих или ничего не делать.
Если все данные введены корректно, кнопка Создать станет активной — нажмите на нее.
После создания приложения у вас в корне сайта появляется папка с файлами нужной структуры, создается шаблон сайта с подключенной мобильной платформой и назначается на эту папку. В дальнейшем всю разработку будем вести именно в созданной папке. В данном случае, это http://<мой_сайт>/mobile_app/.
Проверим работоспособность созданного макета на сервере. Для этого установим и запустим мобильное приложение для разработчиков BitrixMobile из Google Play или AppStore.
Введем адрес приложения в формате http://<домен>/<имя_папки> и нажмем подключиться. Если все хорошо, то увидим следующее:
Макет создан, можно приступить к настройке нативных элементов интерфейса.
Настройка параметров приложения
и вида нативных элементов
Итак, после создания приложения открывается редактор, в котором мы увидим разбитые на группы параметры (справа) и легкое превью (слева).
В верхней панели располагается селектор для переключения между приложениями и табы для переключения между конфигурациями.
В панели можно добавить еще одно приложение или добавить конфигурацию к уже созданному приложению. По умолчанию к приложению создается Общая конфигурация, которая будет применяться как для Android, так и для iOS.
Параметры в редакторе разделяются по нескольким типам:
- цвет;
- изображение;
- число;
- строка;
- флаг;
- значение из списка;
Некоторые из них включатся в себя соответствующими контролы:
Результат изменения некоторых параметров отображается в превью.
Пока есть три экрана:
- Загрузка — отображает параметры экрана загрузки
- Главный экран — параметры фона
- Списки
Важно! Чтобы не искать параметры в группах, можно просто кликнуть на элемент превью — редактор переключится на нужную группу параметров и подсветит их.
Изображения
В настройке параметров типа изображение есть возможность множественной загрузки и выбора уже ранее загруженных изображений.
Каждое отдельное приложение имеет свой банк изображений, что позволяет применять эти изображения в нескольких конфигурациях в рамках одного приложения.
Некоторые изображения снабжены дополнительным параметром растягивания с режимами crop/stretch/repeat:
Изменение любого параметра сопровождается авсохранением и можно сразу увидеть сделанные изменения в мобильном приложении для разработчика.
Отдельные параметры
для отдельной платформы
В верхней панели можно добавлять и удалять конфигурации, а также добавить конфигурацию для Android и, подключаясь приложением для разработки, можно увидеть именно Android-конфигурацию, а не общую.
Примечания
С момента выпуска этого конструктора рекомендуется формировать параметры приложения именно через него. Теперь не нужно разбираться в структуре параметров и искать в документации их названия — все будет в конструкторе. Конструктор создает в папке вашего приложения файл settings.php, на который мы будем ориентироваться при сборке.
Важно! Обратите внимание на раздел Дополнительно — в нем есть невизуальные настройки, которые включают в себя параметры push-уведомлений и возможность отключения верхней панели и слайдера в итоговом приложении.
Офлайн-режим в BitrixMobile
В главе рассказывается, как сделать офлайн-режим работы приложений, созданных на мобильной платформе BitrixMobile.
Настройка в конструкторе приложений
Создание офлайн приложения
Для создания макета офлайн-приложения нужно:
- Перейти в раздел Сервисы > Конструктор мобильных приложений и нажать кнопку Создать приложение.
- Заполните поля формы, выберите шаблон публичной части приложения Обычное приложение и выставите опцию Добавить шаблон и настройки офлайн приложения:
- Макет приложения создан — можно переходить к настройке.
Раздел Офлайн
Данный раздел настроек конструктора предназначен для конфигурирования будущего приложения. Он содержит следующие параметры:
- Режим запуска приложения
- Только при наличии сети — приложение будет запускаться по классической схеме — со страницами с дальнего сервера.
- Только офлайн — в этом режиме приложение будет стартовать только указанными в настройках стартовыми офлайн-ресурсами (главная страница, левое меню, правое меню).
- Смешанный — этот режим позволяет запускать приложение с разными вариантами в зависимости от наличия интернета. Если есть активное интернет-соединение — приложение будет запускаться с дальнего сервера, нет — будет запускать офлайн-страницы, указанные в настройках.
- Офлайн файлы — это список файлов, которые будут доступны в офлайн-режиме. Это могут быть: файлы изображений, html-страницы, файлы скриптов и стилей.
Добавление файлов осуществляется в формате
ключ-значение
:ключ
— имя, которое будет дано файлу в файловой структуре на стороне приложение;значение
— путь к файлу на сервере.
Внимание: в процессе разработки приложения не забывайте дополнять этот список файлами, которые используются для офлайн-доступа. В противном случае, файлы не будут включены в итоговый bundle и при тестировании приложение будет работать некорректно.
- Главная страница — это файл из списка Офлайн файлы, стартовая офлайн-страница приложения. Рекомендуется указывать именно html-файл. Эта страница будет загружаться в качестве основной, если режим запуска выставлен Только офлайн, или в случае отсутствия сети — в режиме запуска Смешанный.
- Страница левой части слайдера — это файл из списка Офлайн файлы, стартовая страница в левой части слайдера приложения. Рекомендуется указывать html-файл.
Для активации левого слайдера нужно вызвать следующий код в теле страницы:
BXMSlider.setEnabled(BXMSlider.state.LEFT, true)
- Страница правой части слайдера — это файл из списка Офлайн файлы, стартовая офлайн-страница правой части слайдера приложения. Рекомендуется указывать html-файл.
Для активации правого слайдера нужно вызвать следующий код в теле страницы:
BXMSlider.setEnabled(BXMSlider.state.RIGHT, true)
Итоговая файловая структура офлайн-ресурсов
После создания первичной структуры приложения в папке приложения появится папка offline
. В ней содержатся файлы следующей структуры A:
/myapp/offline/index.html /myapp/offline/menu.html /myapp/offline/script.js /myapp/offline/style.css
Можно добавить свои файлы и новая структура файлов будет выглядеть, например, вот так:
/myapp/offline/mydir/another_script.js /myapp/offline/mydir/another_style.css /myapp/offline/somedir/images/img.png /myapp/offline/index.html /myapp/offline/menu.html /myapp/offline/script.js /myapp/offline/style.css
Обозначим дополненную структура файлов буквой B.
Важно: Есть одна особенность: структура файлов при разработке будет отличаться от структуры файлов, которые будут помещены в приложение.
Так, структура файлов B в приложении будет иметь вид:
another_script.js another_style.css img.png index.html menu.html script.js style.css
Т.е. все файлы будут располагаться на одном уровне. При обращении к этим файлам нужно учитывать этот момент.
Офлайн-страница
Основными ресурсами для мобильных браузеров, конечно же, являются html-страницы. Нужно помнить о правилах оформления html-страниц для мобильных браузеров.
Мета тег viewport
В отличие от классического приложения на BitrixMobile, где управление масштабированием и размерами страницы осуществляется в PHP, в офлайн-приложении мета-тег viewport
не выставляется автоматически. Т.е. размеры контента, масштабирование страницы придется выставлять в каждом файле самостоятельно, включая мета-тег viewport
в <head> страницы. Например, вот так:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <meta name="format-detection" content="telephone=no"> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, width=320"> </head> ...
Примечание: Более подробно ознакомиться с viewport-атрибутами и рекомендациями по его конфигурированию можно в официальной документации по платформам iOS и Android.
Важно! Платформа BitrixMobile iOS использует WKWebView для отображения веб-контента. С апреля 2020 года компания Apple отказалась от поддержки UIWebView в пользу WKWebView с современным API WebKit. В WKWebView была изменена работа с пользовательскими схемами и для обращения к офлайн-ресурсу в BitrixMobile необходимо обязательно использовать схему bxlocal://
.
Подключение ядра платформы BitrixMobile
Опять же, на офлайн-страницах автоматически не подключается ядро мобильной платформы. Это нужно сделать самостоятельно.
Для начала нужно подключить базовый скрипт Cordova __deviceload__/cordova.js, используя схему bxlocal://
:
<head> <meta charset="UTF-8"> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <meta name="format-detection" content="telephone=no"> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, width=290"> <!--Include mobile platform--> <script type="text/javascript" src="bxlocal://__deviceload__/cordova.js"></script> </head>
На офлайн-страницах не будут доступны javascript-библиотеки платформы «1C-Битрикс» в том виде, в котором они доступны на обычных страницах на удаленном сервере. Но будет доступен bundle из нескольких javascript-библиотек, которые нужно обязательно подключить для работы с основным API. Чтобы его использовать нужно подключить скрипт bitrix_mobile_core.js, используя схему bxlocal://
:
<head> <meta charset="UTF-8"> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <meta name="format-detection" content="telephone=no"> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, width=290"> <!--Include mobile platform--> <script type="text/javascript" src="bxlocal://__deviceload__/cordova.js"></script> <script type="text/javascript" src="bxlocal://bitrix_mobile_core.js"></script> <!----> </head>
Теперь на странице можно использовать весь API платформы BitrixMobile, который описан ниже в данном курсе в разделе API.
В bitrix_mobile_core.js входят:
- Основная библиотека:
/bitrix/js/main/core/core.js
- Библиотека для работы с ajax-запросами:
/bitrix/js/main/core/core_ajax.js
- Библиотека для работы с базой данных SQLite:
/bitrix/js/main/core/core_db.js
- Мобильные библиотеки:
/bitrix/js/mobileapp/bitrix_mobile.js
и/bitrix/js/mobileapp/mobile_lib.js
Подключение скриптов и стилей
Как уже было указано в уроке Итоговая файловая структура офлайн-ресурсов, все файлы офлайн ресурсов располагаются в приложении на одном уровне (в одной папке). Поэтому подключать js- и css-файлы можно просто, указав имя файла в атрибуте src/href
со схемой bxlocal://
:
<head> <meta charset="UTF-8"> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <meta name="format-detection" content="telephone=no"> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, width=290"> <!--Include mobile platform--> <script type="text/javascript" src="bxlocal://__deviceload__/cordova.js"></script> <script type="text/javascript" src="bxlocal://bitrix_mobile_core.js"></script> <!----> <script type="text/javascript" src="bxlocal://script.js"></script> <link href="bxlocal://style.css" rel="stylesheet" type="text/css"> </head>
Обращение к изображениям в css-файлах и javascript-файлах также осуществляется по простому названию файла. Он будет браться относительно текущего расположения файла.
Использование API BitrixMobile
Здесь нет ограничений. Все так же, как и раньше. Но для работоспособности всего набора функций нужно на странице объявить версию API, которую вы будете использовать. Сейчас это 17 API. Также нужно определить версию платформы ios или android. Это можно сделать через определение user-agent браузера прямо javascript. В примере ниже мы просто установили platform=»ios» и appVersion=17:
<head> <meta charset="UTF-8"> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <meta name="format-detection" content="telephone=no"> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, width=290"> <!--Include mobile platform--> <script type="text/javascript">var appVersion = 17;var platform = "ios";</script> <script type="text/javascript" src="bxlocal://__deviceload__/cordova.js"></script> <script type="text/javascript" src="bxlocal://bitrix_mobile_core.js"></script> <!----> <script type="text/javascript" src="bxlocal://script.js"></script> <link href="bxlocal://style.css" rel="stylesheet" type="text/css"> </head>
Обращение к ресурсам через API
Для обращения к офлайн-ресурсу используется схема bxlocal://
или через виртуальную директорию __bxoffline__
. Используя эту схему, вы сообщаете платформе, что хотите обратится к локальному контенту.
Еще одна из важных особенностей офлайн-приложения на BitrixMobile — свобода в использовании офлайн-ресурсов:
- Доступ к офлайн-страницам
- Старт приложения из офлайн-страниц. Страницы указываются в конструкторе.
- Открытие офлайн-страницы из другой офлайн-страницы.
Например, через простую ссылку:
<a href="bxlocal://detail.html">Детальная страница</a> <a href="http://mysite.com/__bxoffline__/detail.html">Детальная страница</a>
или через
BXMobileApp.PageManager
с передачей параметров:<script> BXMobileApp.PageManager.loadPageBlank({ url: "bxlocal://detail.html", data:{key:"value"}, title: "Детальная страница" }); </script>
- Открытие офлайн-страницы со страницы на удаленном сервере. Точно также как и в п.2.
- Открытие страницы на удаленном сервере с офлайн-страницы:
<script> BXMobileApp.PageManager.loadPageBlank({ url: "/mobile_app/detail.php", data:{key:"value"}, title: "Детальная страница" }); </script>
- Открытие страницы на удаленном сервере с офлайн-страницы.
- Доступ к офлайн-изображениям:
<img src="bxlocal://myimage.png">
- Доступ к контенту других файлов (только для Android).
Например, можно добавить файл
data.json
c содержимым:{ "key1":"value1", "key2":"value2", "key3":"value3" }
Данные из этого файла можно получить через ajax-запрос. В разных ситуациях это делается по-разному:
- Если вы пытаетесь получить контент офлайн-файла со страницы на удаленном сервере, то нужно использовать виртуальную директорию
__bxoffline__
:BX.ajax.get("/__bxoffline__/data.json",{},function(data){ console.log(data); });
- Если запрос осуществляется с офлайн-страницы, то можно использовать как предыдущий вариант, так и упрощенный:
BX.ajax.get("data.json",{},function(data){ console.log(data); });
- Если вы пытаетесь получить контент офлайн-файла со страницы на удаленном сервере, то нужно использовать виртуальную директорию
Контекст офлайн-страниц
Офлайн-ресурсы в приложении загружаются в контексте сервера, а не в контексте файловой структуры.
Например, если вы попытаетесь загрузить условную офлайн-страницу detail.html
:
<script> BXMobileApp.PageManager.loadPageBlank({ url: "bxlocal://detail.html", data:{key:"value"}, title: "Детальная страница" }); </script>
то адресом этой страницы будет:
http://mysite.com/__bxoffline__/detail.html
Т.е. как-будто страница была загружена с удаленного сервера. Это дает возможность использовать сущности, привязанные к домену вашего сайта — cookies, хранилище в формате ключ-значение
localstorage и локальные базы данных indexedDB и SQLite.
Запросы и кэширование данных
Как уже было упомянуто в уроке Подключение ядра платформы BitrixMobile, в офлайн-режиме доступны javascript-библиотеки платформы «1С-Битрикс» и ядро мобильной платформы. Соответственно, для запросов можно использовать BX.ajax
, а для кэширования — BX.database
.
В офлайн-приложениях важно кэшировать данные, чтобы можно было отобразить контент пользователю в те моменты, когда данные либо загружаются с дальнего сервера, либо их загрузка в принципе невозможна (нет Интернета или недоступен сервер).
Работа с базой данных
Создание базы данных:
var db = new BX.dataBase({ name: "MyDatabase", displayName: "MyDatabase", capacity: 1024 * 1024 * 4, version: "1.2" });
Функции для типичных операций:
db.createTable(params)
— создание своей таблицы;db.dropTable(params)
— удаление таблицы;db.addRow(params)
— добавление записи в таблицу;db.getRows(params)
— получение данных из таблицы;db.updateRows(params)
— апдейт таблицы;db.deleteRows(params)
— удаление записей из таблицы.
Примеры использования
- Свой запрос:
var queryData = { query: "SELECT * FROM MYTABLE WHERE ID=? AND CODE=?", values: [12, "some_code"] }; db.query( queryData, function (res) { //code }, function (e) { //code } );
- Создание таблицы:
var createTableParams = { tableName: "mytable", fields: [ {name: "id", unique: true}, "name", "data" ], success: function (res) { console.log("success"); }, fail: function (e) { console.log("some error"); console.log(e); } }; db.createTable(createTableParams);
- Добавление записи в таблицу:
db.addRow( { tableName: "mytable", insertFields: { id: 10, name: "newRecord", data: "sadasd" }, success: function (res) { console.log("success"); }, fail: function (e) { console.log("some error"); console.log(e); } });
- Обновление таблицы:
db.updateRows({ tableName: "mytable", updateFields: { data: "Very important data!" }, filter: { id: 10 }, success: function (res) { alert("Success") }, fail: function (e) { alert("Error!"); } });
- Получение данных:
db.getRows({ tableName: "mytable", filter: { id: 10 }, success: function (res) { //res.items - массив записей console.log(res); if (res.items.length > 0) console.log("Success"); }, fail: function (e) { console.log(e); } });
Тестирование
После разработки своего приложения следует протестировать его работу в разных режимах: с Интернетом и без него.
Главное что нужно проверить:
- Запуск приложения в онлайне.
- Работа приложения в онлайне.
- Выключение Интернета, когда приложение уже запущено.
- Запуск приложения без доступа в Интернет.
Пример приложения
В качестве примера можно использовать готовое демо-приложение News (Скачать, zip, 86,2 Кб).
В этом демо-приложении есть примеры работы с базой данных, запросами и с локальными ресурсами.
Как посмотреть пример
- В административной части сайта перейдите в Конструктор мобильных приложений (Сервисы > Конструктор мобильных приложений) и создайте приложение с кодом
news
и с папкойdenonews
. В форме создания отметьте галку Добавить шаблон и настройки офлайн приложения. - Затем скопируйте содержимое папки
demonews
из zip-архива в папкуdemonews
, которую создал конструктор в корне вашего сайта. - Вернитесь в Конструктор (в раздел Офлайн) и добавьте в список офлайн-файлов недостающие файлы из папки
/demonews/offline/
. Реальные имена файлов должны совпадать с их именами в левой колонке: - Установите на мобильное устройство Приложение для разработчиков BitrixMobile (Google Android или Apple iOS).
- На странице Конструктора нажмите на кнопку Подключиться. Следуйте инструкциям в открывшемся окне.
Обратите внимание, что подключиться к сайту http://localhost/ вы не сможете, нужно использовать ip-адрес.
Также можно посмотреть видео (длительность 30 мин.) с докладом «Новые возможности мобильной платформы для разработки своих приложений. Офлайновые приложения, пуш нотификации, события» с зимней партнерской конференции «1С-Битрикс» 2016 года.
Отладка приложения на BitrixMobile
Приложение для разработчиков BitrixMobile распространяется через официальные магазины приложений GooglePlay и AppStore. К сожалению, с приложениями из магазина нельзя использовать стандартные средства удаленной отладки компонента браузера, которые описаны здесь: Remote Debugging on Android with Chrome и Safari Web Inspector Guide.
Для отладки приложений, написанных на HTML5/JS, можно использовать Weinre — WEb INspector REmote. Этот инструмент представляет из себя усеченную версию Web Inspector (отладчика WebKit-based браузеров).
Установка и запуск Weinre
Для начала нужно установить на компьютер NodeJS.
Далее нужно проделать следующие шаги:
- Выполнить в терминале вашей ОС установку weinre:
sudo npm install -g weinre
Примечание: для ОС Windows использовать
sudo
не нужно. - Запустить weinre следующей командой, заменив в ней ip-адрес на адрес вашей машины, который вы сможете найти в настройка сети:
weinre --boundHost x.x.x.x --httpPort xxxx
Например:
weinre --boundHost 192.168.1.171 --httpPort 8081
- Теперь перейдите на страницу в браузере со следующим адресом: http://192.168.1.171:8081/, где будет доступна стартовая страница weinre:
Отладка приложения
Сервер weinre запущен. Теперь нужно инициализировать отладку на страницах приложения.
- Для этого в код страницы, которую нужно отладить, в блоке
<head>
нужно вставить следующее:<script src="http://192.168.1.171:8081/target/target-script-min.js#anonymous"></script>
- Далее нужно открыть приложение и в нем перейти на страницу, которую нужно отладить.
- Теперь на компьютере в браузере перейдите по ссылке http://192.168.1.171:8081/client/#anonymous и вы увидите список страниц приложения, которые можно инспектировать (блок Targets):
- Выберите страницу (кликните на нужную) и начните отладку. Можно инспектировать элементы, использовать javascript-консоль для отладки, просматривать содержимое локальных хранилищ и баз данных, просматривать http-запросы. Брэйкпоинт в данном отладчике не поддерживаются.
Push-уведомления
Взаимодействие с пользователем через уведомления — это одно из преимуществ мобильных приложений в целом. Уведомлениями можно привлечь клиента к своему сервису или магазину, сообщить о скидках, уведомить об изменении статуса заказа и многое другое. Кроме этого, можно легко определить, по каким уведомлениям переходит пользователь, понять, что ему интересно и персонализировать рассылки и контент.
Идентификатор приложения
Идентификатор приложения — это строковый код, который используется для отправки уведомлений через сервис BitrixCloudMessaging.
Чтобы получить такой идентификатор для вашего приложения, его требуется указать в поле Идентификатор приложения для отправки (Конструктор мобильных приложений > Дополнительно):
При сборке приложения наши специалисты зарегистрируют этот идентификатор в сервисе BitrixCloudMessaging для платформ iOS и Android. После этого вы сможете отправлять уведомления пользователям вашего приложения.
Токены
Токен — это идентификатор устройства, который регистрируется в сервисах Apple и Google для отправки уведомлений.
Получение токена и отправка на сервер
Для того, чтобы пользователь получал уведомления на свой смартфон, нужно узнать токен его устройства.
Получить токен, а затем отправить методом GET или POST на php-скрипт можно через javascript-код, который нужно разместить на стартовой странице своего приложения:
app.exec("getToken", { callback:function(token) { var platform = (window.platform == "ios"? "APPLE": "GOOGLE"); var config = { url: "myurl.php" , method: "POST", data: { device_name: (typeof device.name == "undefined" ? device.model : device.name), uuid: device.uuid, device_token: token, app_id: “MyAPPid”, device_type: platform, sessid: BX.bitrix_sessid() } }; BX.ajax(config); } });
Обратите внимание, в JS-скрипте используется объект device, существующий только в рамках мобильной платформы BitrixMobile. Данный объект используется для получения информации об устройстве.
Сохранение токена
В примере выше мы получили токен устройства и отправили его на php-скрипт myurl.php. Теперь его нужно сохранить для дальнейшего использования:
<?php use BitrixMainWebJson; require_once($_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/main/include/prolog_before.php"); $result = Array("status" => "failed"); if (!BitrixMainLoader::includeModule("pull")) { $result["error"] = "Module 'pull' is not installed"; } else { /** * @var $DB CAllDatabase * @var $USER CALLUser */ $data = null; $userId = $USER->GetID(); if (!$userId) { $userId = 0; } if ($_REQUEST["device_token"]) { $res = array("status" => "failed", "error" => "some unknown error"); $data = array( "DEVICE_TOKEN" => $_REQUEST["device_token"], "DEVICE_ID" => $_REQUEST["uuid"], "DEVICE_TYPE" => $_REQUEST["device_type"], "APP_ID" => $_REQUEST["app_id"], "DATE_AUTH" => ConvertTimeStamp(getmicrotime(), "FULL"), "USER_ID" => $userId ); $dbres = CPullPush::GetList(Array(), Array("DEVICE_ID" => $data["DEVICE_ID"])); $arToken = $dbres->Fetch(); $status = "failed"; if ($arToken["ID"]) { CPullPush::Update($arToken["ID"], $data); $status = "updated"; } else { if ($res = CPullPush::Add($data)) { $status = "registered"; } } $result = array( "token_status" => $status ); } } $result["data"] = $data != null ? $data : array(); header("Content-Type: application/x-javascript"); echo Json::encode($result); die();
Обратите внимание, что токен сохраняется с идентификатором приложения. При отправке уведомлений на устройство с этим токеном нужно использовать именно этот идентификатор приложения. Как видно из примера, каждый токен обязательно привязывается к пользователю сайта. Если стоит задача отправлять уведомления анонимным пользователям, то можно использовать «фиктивный» идентификатор, либо использовать идентификатор специально созданного пользователя или идентификаторы нескольких специально созданных пользователей для группировки токенов.
Обновление токена
Токены устройств со временем могут меняться или истекать.
Например, при обновлении операционной системы на устройстве токен может поменяться. Поэтому рекомендуется периодически удалять неактивные токены и обновлять существующие. Иными словами, при каждом запуске приложения следует повторять операцию обновления.
Уведомления
Отправка уведомлений
Для каждого сервиса логика отправки уведомлений разная, поэтому механизм отправки нужно реализовать самостоятельно. Для отправки уведомлений используется класс CPushManager модуля Push&Pull.
Пример кода отправки:
if (CModule::IncludeModule("pull")) { $arMessages = array(); $message = Array( "USER_ID" => 2, //Идентификатор пользователя "TITLE" => "Title", //заголовок, только для Android "APP_ID" => "MyAppID", //Идентификатор приложения "MESSAGE" => “У нас сегодня акция! Не пропусти!”, "EXPIRY" => 0, //время жизни уведомления на сервере Apple и Google "PARAMS"=>array("PARAMS"=>array("tst"=>"1")), "BADGE" => 1 //счетчик на иконке приложения ); $arMessages[] = $message; $manager = new CPushManager(); $manager->SendMessage($arMessages); }
Важным является ключ PARAMS. Данные по этому ключу помогут обработать открытие уведомления пользователем.
Внимание! Если один пользователь авторизован в мобильном приложении на нескольких устройствах, то push’и будет отправлены на все устройства для которых в b_pull_push указан USER_ID
этого пользователя. Выполнить отправку на какое то определенное устройство по его device_token нет возможности.
Обработка уведомлений
После получения уведомления на свое устройство пользователь может проигнорировать его, а может перейти по нему в приложение, в этом случае вы можете обработать этот переход. Например, можно открыть пользователю нужную страницу или показать определенное сообщение, зафиксировать переход по уведомлению у себя на сервере и многое другое.
На стартовой странице нужно разместить javascript-код следующего вида:
var lastNotification = BXMobileApp.PushManager.getLastNotification();
В переменной lastNotification будет объект данных уведомления, по которому пользователь перешел в приложение. В объекте будет ключ params, который вы отправляли через метод CPushManager::SendMessage().
Тестирование
Протестировать свои наработки можно в приложении BitrixMobile для разработчиков. Для работы с уведомлениями нужно использовать идентификатор BitrixMobile.
Генерация ключей для push-уведомлений (Android)
Для работы push-уведомлений на платформе BitrixMobile нужно при публикации Android-приложения предоставить 3 ключа: Идентификатор приложения, Ключ сервера и Идентификатор отправителя.
Для этого необходимо:
-
Авторизоваться под аккаунтом разработчика и перейти в Google Firebase. и далее в консоль:
- Начните добавление Firebase в свое приложение нажав на кнопку с иконкой [dw]Андройда[/dw][di][/di].
-
[dw]Зарегистрируйте[/dw][di]
[/di] приложение. - Скачайте файл конфигурации:
- Откроется страница сервиса Добавление Firebase в приложение для Android, где нужно зарегистрировать приложение.
Название пакета Android можно выбрать как составное из названия вашего домена, написанное наоборот, и названия вашего приложения. Например, домен вашего сайта example.com, а приложения
MyApp
, тогда название пакета Android будетcom.example.myapp
. - После регистрации приложения можно сразу перейти к обзору проекта кликом по крестику:
- Далее выбрать в меню [dw]Настройки проекта[/dw][di][/di].
- Во вкладке General у нужного приложения получаем Идентификатор приложения:
- Далее нужно разрешить использование API сообщений с помощью команды Manage API на закладке Cloud masaging:
- В новом окне разрешите использование сообщений по кнопке [dw]Enable[/dw][di][/di].
- После этого станут доступными Ключ сервера и Идентификатор отправителя:
Полученные Идентификатор приложения, Ключ сервера и Идентификатор отправителя необходимо будет ввести при заявке на публикацию Android-приложения на платформе BitrixMobile.
Гарантии доставки push-уведомлений
Сервис push-уведомлений гарантирует отправку уведомлений в сервисы Google Gloud Messaging и Apple Push Notification Service, но не гарантирует 100% получение уведомления пользователем от этих сервисов.
Почему уведомление может не дойти до получателя?
Причины по которым Google Сloud Messaging и Apple Push Notification Service не доставляют уведомления:
- Пользователь находился в офлайн или у него были проблемы с сетью.
Каждое уведомление имеет «время жизни» и указывается разработчиком при отправке. Если за «время жизни» уведомления пользователь так и не вышел в сеть, то данное уведомление никогда не будет доставлено. - Зарегистрированный токен устройства устарел и более не является актуальным для сервисов Google Сloud Messaging и Apple Push Notification Service.
Токены устройств, которые сохраняются разработчиком для последующей отправки уведомлений, могут стать неактуальными в любой момент. Разработчик приложения должен позаботиться об обновлении токенов в базе данных. Если пользователь долгое время вообще не открывал приложение, то велика вероятность, что его токен перестанет быть актуальным и он больше не будет получать уведомления.
Токен также станет неактуальным по причинам:- переустановка приложения,
- обновления операционной системы или какого-либо обновления сервиса отправки уведомлений (Google Сдoud Messaging и Apple Push Notification Service), которое требует повторной регистрации устройства.
- Пользователь выключил уведомления для приложения.
- Пользователь перевел устройство в режим экономии энергии, что может ограничить активность устройства в плане работы с сетью и подключении к сервисам уведомлений.
В Android 6.0 появился Doze Mode — режим, при котором сервисы и приложения «засыпают» на время блокировки устройства, в этом режим уведомления также могут доставлены с опозданием или не доставлены вообще. - Размер push-уведомления превысил ограничения (4кб для iOS и 8кб для Android).
- В момент отправки уведомления пользователь находится в приложении. Уведомления доставляются на устройства пользователя, только если приложение выгружено из памяти или находится в фоне.
- Слишком много уведомлений в очереди для одного устройства (iOS). Более подробную информацию вы можете узнать здесь.
- В момент отправки не доступны сервисы Google Сloud Messaging и Apple Push Notification Service
- Ошибки в работе сервисов Google Сloud Messaging и Apple Push Notification Service.
API
Ниже представлен справочник по API платформы BitrixMobile.
BXMobileApp.UI.Slider — управление слайдером
Каждое приложение на платформе BitrixMobile имеет свой слайдер, который может состоять из трех зон для контента:
- Левая часть;
- Правая часть;
- Центральная часть.
- У боковых частей слайдера нет своего стека навигации, и они могут содержать только одну страницу.
- Все вызываемые функции объекта BXMobileApp.PageManager будут осуществлять действия в стеке навигации центральной части.
- Открыта левая часть.
- Открыта правая часть.
- Обе части слайдера закрыты.
BXMobileApp.UI.Slider.state.LEFT (1)
— открыта левая часть;BXMobileApp.UI.Slider.state.RIGHT (2)
— открыта правая часть;BXMobileApp.UI.Slider.state.CENTER (0)
— обе части слайдера закрыты.- state — состояние слайдера, которое нужно разблокировать/заблокировать;
- enabled — флаг блокировки состояния:
true
— разблокирован;false
— заблокирован.
- поддержка «ночного» режима;
- закрытие кнопкой и «смахиванием»;
- поддержка жестов: масштабирование двойным нажатием с удержанием и последующим сдвигом, увеличение 2 пальцами;
- функция шаринга.
- поддержка жестов: масштабирование двойным нажатием с удержанием и последующим сдвигом, увеличение 2 пальцами;
- url — путь до картинки;
- description — сопроводительный текст к картинке.
- поддержка жестов: прокрутка, масштабирование двойным нажатием с удержанием и последующим сдвигом, увеличение 2 пальцами;
- функция шаринга;
- автоматическое кэширование документа на устройстве. Сброс закешированных документов возможен в настройках приложения.
- только скачивание. Открытие скачанного документа возможно только с помощью сторонних программ!
- url — ссылка на документ.
- filename — имя файла (необязательный ключ).
- start_date — начальное значение даты, времени или даты и времени. Если не задается, отображается текущая дата (время);
- min_date — позволяет задать минимально возможную для выбора дату;
- max_date — позволяет задать максимально возможную для выбора дату;
- format — формат даты и времени. В этом формате нужно передавать start_date, min_date и max_date. В этом формате пикер вернет выбранную дату в функцию обратного вызова;
- callback — обработчик события выбора даты и времени. Первым аргументом в обработчик передается выбранная дата в формате format;
- type — тип пикера. Используются следующие типы отображения:
- datetime — дата и время;
- time — время;
- date — позволяет задать максимально возможную для выбора дату.
Центральная часть слайдера
Центральная часть содержит свой собственный стек навигации с одной и больше страницами, которые можно добавлять и удалять. К каждой странице в стеке навигации центральной части можно добавлять нативные элементы: кнопки, заголовки, панели и т.д.
Левая и правая части слайдера
Эти части слайдера используются как основные элементы навигации в приложении, они могут скрываться и «жить» на фоне приложения. Javascript все это время работает на этих страницах, поэтому рекомендуется использовать эти страницы как постоянное пространство, в котором можно размещать javascript-код для периодического обновления данных в приложении, long-polling соединений, а также web-страницу с меню, списками или любыми другими компонентами, которые помогают быстро перемещаться по приложению.
Важные моменты:
UI.Slider.setState
Описание
Функция изменяет состояние слайдера. Слайдер может быть в одном из 3-х состояний:
Синтаксис
BXMobileApp.UI.Slider.setState(sliderState)
Аргументы | Описание |
sliderState |
Состояние слайдера. Возможные значения: |
Пример
//Открытие левой части слайдера BXMobileApp.UI.Slider.setState(BXMobileApp.UI.Slider.state.LEFT); //Открытие правой части слайдера BXMobileApp.UI.Slider.setState(BXMobileApp.UI.Slider.state.RIGHT);
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Slider.setStateEnabled
Описание
Функция блокировки/разблокировки состояний слайдера. По умолчанию левая и правая части слайдера заблокированы.
Синтаксис
BXMobileApp.UI.Slider.setStateEnabled(state, enabled);
Аргументы | Описание |
|
Пример
//Блокируем открытие правой части слайдера BXMobileApp.UI.Slider.setStateEnabled(BXMobileApp.UI.Slider.state.RIGHT, false); //Блокируем открытие левой части слайдера BXMobileApp.UI.Slider.setStateEnabled(BXMobileApp.UI.Slider.state.LEFT, false);
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Photo — показ фото или фото ряда
Объект предназначен для работы с нативным контролом показа фото, с возможностью масштабирования и шаринга.
UI.Photo.show
Описание
Функция для показа фото через нативный контрол. Изображение(-я) открывае(ю)тся в отдельном окне. Допускается два варианта использования: Одиночный и Множественный.
В зависимости от платформы в просмотрщике доступен разный набор функций.
iOS:
Android:
Синтаксис
BXMobileApp.UI.Photo.show(params);
Аргументы | Описание |
photos |
Массив объектов с описанием изображения: Структура объекта описания изображения: |
Пример одиночного варианта
BXMobileApp.UI.Photo.show({"photos":[ { "url":"http://mysite.com/sample.jpg", "description": "description text" } ]});
Видео
iOS | Antroid |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Пример режима множественного просмотра изображений
BXMobileApp.UI.Photo.show({"photos":[ { "url":"http://mysite.com/sample.jpg", "description": "description text" }, { "url":"/sample2.jpg", "description": "description text 2" } ... ]});
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Document — просмотр документов
Объект для управления документами.
UI.Document.open
Описание
Функция для отображения или скачивания документов (.doc,.pdf,.txt,.txt и т.п.).
В зависимости от платформы доступен разный набор функций и реализовано разное поведение.
iOS:
Android:
Синтаксис
BXMobileApp.UI.Document.open(params);
Аргументы | Описание |
params |
Объект с описанием документа: Ключи для описания документа: |
Пример
BXMobileApp.UI.Document.open({"url":"/mysite.com/text.txt"});
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.DatePicker — контрол выбора даты
Контрол предоставляет возможность выбрать время и дату, а результат выбора возвращается в заданную функцию обратного вызова в заданном формате.
Внимание: В современных версиях Android и iOS этот контрол уже встроен, достаточно задать атрибут type="date"
в теге <input>
. Однако, это не заработает на Android ниже версии 4.4 (за исключением устройств от Samsung), для этих случаев и создан аналогичный контрол в BitrixMobile.
UI.DatePicker.show
Описание
Функция для показа контрола выбора даты и времени.
Синтаксис
BXMobileApp.UI.DatePicker.show();
Для показа контрола выбора дат нужно предварительно задать параметры через:
BXMobileApp.UI.DatePicker.setParams(pickerParams);
Аргументы | Описание |
pickerParams |
Объект описания пикера: Ключи описания пикера: Внимание! Формат даты должен соответствовать переданному типу пикера. |
Примеры
Пример отображения для выбора только времени:
//Отображение пикера времени, с заданным начальным временем: BXMobileApp.UI.DatePicker.setParams({ type: "time", start_date: "09:12", format: "h:mm", callback: function (d) { app.alert({title:"time", text:JSON.stringify(d)}); } } ); BXMobileApp.UI.DatePicker.show();
Пример для отображения контрола выбора только даты:
//Отображение пикера даты, с заданной начальной датой: BXMobileApp.UI.DatePicker.setParams({ type: "date", start_date: "29.06.1998", format: "dd.MM.yyyy", callback: function (d) { app.alert({title:"date", text:JSON.stringify(d)}); } } ); BXMobileApp.UI.DatePicker.show();
Пример пример отображения контрола для выбора даты и времени:
//Отображение пикера даты и времени, с заданной начальной датой и временем. В iOS год не отображается для выбора, но передается, с выбранной датой и временем: BXMobileApp.UI.DatePicker.setParams({ type: "datetime", start_date: "29.06.1998, 09:12", format: "dd.MM.yyyy, h:mm", callback: function (d) { app.alert({title:"datetime", text:JSON.stringify(d)}); } } ); BXMobileApp.UI.DatePicker.show();
Пример с ограничением выбора даты:
//Задаем минимально возможную для выбора дату. В данном примере задана дата - 09.01.2014. На платформе iOS, в случае выбора даты меньше, чем 09.01.2014, пикер отобразит минимально возможную дату, а именно 09.01.2014: BXMobileApp.UI.DatePicker.setParams({ type: "date", format: "dd.MM.yyyy", min_date: "09.01.2014", callback: function (d) { app.alert({title:"datetime", text:JSON.stringify(d)}); } }); BXMobileApp.UI.DatePicker.show();
Пример:
//Задаем максимально возможную для выбора дату. В данном примере задана дата - 02.03.2015. На платформе iOS, в случае выбора даты больше, чем 02.03.2015, пикер отобразит максимально возможную дату, а именно 02.03.2015: BXMobileApp.UI.DatePicker.setParams({ type: "date", format: "dd.M.yyyy", max_date: "02.03.2015", callback: function (d) { app.alert({title:"datetime", text:JSON.stringify(d)}); } }); BXMobileApp.UI.DatePicker.show();
Пример:
//Использование изначально заданной даты и времени, с ограничением выбора по установленной максимальной дате и времени (начально заданная дата и временя, должны быть одинакового формата с максимально возможной для выбора датой и временем). В данном примере заданы дата и время - 01.03.2015, 09:12. На платформе iOS, в случае выбора даты и времени больше, чем 01.03.2015, 09:12, пикер отобразит максимально возможную дату и время, а именно 01.03.2015, 09:12: BXMobileApp.UI.DatePicker.setParams({ type: "datetime", start_date: "01.03.2015, 09:12", format: "dd.MM.yyyy, h:mm", max_date: "02.03.2015, 09:00", callback: function (d) { app.alert({title:"datetime", text:JSON.stringify(d)}); } }); BXMobileApp.UI.DatePicker.show();
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.DatePicker.hide
Описание:
Функция для скрытия контрола выбора даты и времени.
Синтаксис:
BXMobileApp.UI.DatePicker.hide();
BXMobileApp.UI.SelectPicker — контрол выбора значений
Объект контрола выбора значений. Интерфейсно схож с контролом обычного <select>
.
UI.SelectPicker.show
Описание
Функция для вызова контрола выбора значений. Работает в двух режимах — Одиночном и Множественном.
Синтаксис
BXMobileApp.UI.SelectPicker.show(pickerParams);
Аргументы | Описание |
pickerParams |
Объект параметров. Может содержать ключи:
|
Примеры
Пример с одиночным выбором:
var items = ["Отлично!", "Хорошо!", "Очень плохо!"]; BXMobileApp.UI.SelectPicker.show({ callback: function (data) { app.alert({title:"Selected", text:JSON.stringify(data)}); }, values: items, });
Пример с множественным выбором:
var items = ["Отлично!", "Хорошо!", "Очень плохо!"]; BXMobileApp.UI.SelectPicker.show({ multiselect:true, callback: function (data) { app.alert({title:"Selected", text:JSON.stringify(data)}); }, values: items, default_value: items [1], });
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.BarCodeScanner — сканер bar-кодов
Объект бар-код сканера. Сканер умеет считывать штрих и qr-коды разных форматов.
UI.BarCodeScanner.open
Описание
Функция открывает barcode-сканнер.
Синтаксис
BXMobileApp.UI.BarCodeScanner.open(params);
Аргументы | Описание |
params |
Объект с параметрами страницы: Ключи объекта-аргумента:
Поддерживаемые форматы: iOS — QR_CODE, DATA_MATRIX, UPC_E, UPC_A, EAN_8, EAN_13, CODE_128, CODE_39. Android — QR_CODE, DATA_MATRIX, UPC_E, UPC_A, EAN_8, EAN_13, CODE_128, CODE_39, ITF, RSS14, PDF417, RSS_EXPANDED. |
Пример
BXMobileApp.UI.BarCodeScanner.open({ callback:function(data) { if (data.text) { app.alert({title:"Barcode", text:"Format: " + JSON.stringify(data.format) + "Barcode: " + JSON.stringify(data.text)}); } else { app.alert({ text: "MOB_SCAN_ERROR", button:"OK" }); } } });
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Table — управление списками
Списки — нативные элементы, интерфейс которых приближен к интерфейсу списков платформы.
Назначение и описание
Назначение:
- Вывод данных с вложенной структурой (каталог с товарами, папки с документами, отделы и сотрудники и т.д.);
- Вывод данных с линейной структурой (мероприятия, список дел, план упражнений на день и т.д.);
- Отображение списка для выбора значений пользователей.
Элементы списка можно отображать с разделением по секциям или алфавиту. Данный элемент интерфейса позволяет увеличить производительность при отображении списочных данных за счет заложенных механизмов кэширования и lazyload’а для картинок, и функции фильтрации загруженного списка.
Описание:
Функция возвращает объект нативного списка
Синтаксис
var myTable = new BXMobileApp.UI.Table(params, table_id);
Аргументы | Описание |
params
|
Объект с параметрами списка: Ключи описания списка:
|
table_id
|
Идентификатор списка |
Функции и пример
Функции
- show — отображает список.
- clearCache — очистка кэша списка на стороне приложения.
Пример
var table = new BXMobileApp.UI.Table({url: "/my_site/list.php"}, "table"); table.show();
Формирование источников данных для нативных списков
Описание:
Как источник списки используют данные в формате json. Данные должны отдаваться сервером по url, который был указан при создании списка.
Синтаксис:
var table = new BXMobileApp.UI.Table( {url: "<адрес источника данных>"},"table");
Структура данных для списков
- Структура первого уровня:
- data — содержит категории данных. Каждая категория данных представляется собой массив элементов списка.
- sections — содержит списки секций для каждой категории данных.
- names — содержит наименование категорий.
Схематичное представление:
{ "data":{ // data сожержит категории данных "category_code": //ключ категории данных, значением этого ключа является массив элементов этого списка [ { NAME: "element1", URL: "url1", IMAGE: "1.png", SECTION_ID: "id1" }, { NAME: "element2", URL: "url2", IMAGE: "2.png", SECTION_ID: "id2" } .... ], "category_code2":[ // ключ другой катеории ..... ] }, "sections":{ // sections содержит списки секций для каждой категории данных "category_code": //ключ категории данных, значением этого ключа является массив секций списка данной категории [ { NAME: "section_name1", ID: "id1" }, { NAME: "section_name2", ID: "id2" } .... ], "category_code2" [ .... ] }, "names"{ //содержит наименование категорий "category_code": "category_name", "category_code2": "category_name2", } }
- Структура элемента списка:
- ID — идентификатор записи.
- NAME — имя для отображения.
- TABLE_URL — адрес списка, на который будет осуществлен переход при выборе этого элемента списка.
- IMAGE — картинка к записи.
- TAGS — дополнительная информация к записи.
- URL — адрес, на который будет осуществлен переход во внешнем браузере.
Пример 1
Источник данных
Источник данных — list.php:
<? $data = Array( "data"=>Array( //data содержит категории данных "company"=>Array( //category_code - ключ категории данных, значением этого ключа является массив элементов этого списка Array( "ID"=>1, //идентификатор записи "NAME"=>"ПроГрабли", //имя для отображения "TABLE_URL" => "/demo_api/list_nest.php", // адрес списка, на который будет осуществлен переход при выборе этого элемента списка "IMAGE"=>"http://prograbli.ru/bitrix/templates/new_posts/images/pg-logo.png", //картинка к записи "TAGS" => "Про бизнес в интернете без ошибок", //дополнительная информация к записи ), Array( "ID"=>2, "NAME"=>"Bitrix", "IMAGE"=>"/demo_api/img/bitrixico.png", //картинка к записи (локальная) "TAGS"=>"Отечественная CMS", "URL"=>"http://bitrix.ru" // адрес страницы, на которую будет осуществлен переход при выборе этого элемента списка ), Array( "ID"=>3, "NAME"=>"Digital Workplace", "IMAGE"=>"/demo_api/img/digitalwork.png", "TAGS" => "Социальный интранет: Эксперты", "URL"=>"http://www.digitalworkplace.ru" ) ), ), "names"=>Array("company"=>"Компании") //содержит наименование категорий ); echo json_encode($data); ?>
Открытие списка с:
использованием поля для поиска и заголовком
Пример:
//Задаем параметры отображения списка var params = { url: "/my_site/list.php", table_settings: { searchField: true, showtitle: true, name: "Список", // } }; var simple_table = new BXMobileApp.UI.Table(params, "tableId"); simple_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
единичной выборкой (markmode)
Открытие списка с использованием единичной выборки, и отработкой события данной выборки. Обязательное указание флага multiple:false
.
Пример:
//задаем параметры отображения списка var params = { url: "/my_site/list.php", table_settings: { markmode: true, multiple: false, callback: function (data) { app.alert({title:"Markmode", text:JSON.stringify(data)}); } } }; var markmode_table = new BXMobileApp.UI.Table(params, "tableId"); markmode_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
множественной выборкой (markmode_multiple)
Открытие списка с использованием с множественной выборки.
Пример:
//задаем параметры отображения списка var params = { url: "/my_site/list.php", table_settings: { markmode: true, multiple: true, } }; var markmode_multiple_table = new BXMobileApp.UI.Table(params, "tableId"); markmode_multiple_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
заданной множественной выборкой (selected)
Открытие списка с использованием множественной выборки и заданными, выбранными элементами списка.
Пример:
//задаем параметры отображения списка var params = { url: "/demo_api/list.php", table_settings: { markmode: true, multiple: true, selected:({company:[1,2]}), } }; var selected_markmode_table = new BXMobileApp.UI.Table(params, "tableId"); selected_markmode_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Текст внизу списка (footer)
Задается текст внизу списка.
Пример:
//задаем параметры отображения списка var params = { url: "/my_site/list.php", table_settings: { footer: "Table Footer" } }; var footer_table = new BXMobileApp.UI.Table(params, "tableId"); footer_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Пример 2
Источник данных
Источник данных — list2.php:
<? $data = Array( "data"=>Array( "company"=>Array( Array( "ID"=>1, "NAME"=>"Bitrix", "IMAGE"=>"/demo_api/img/bitrixico.png", "TAGS"=>"Отечественная CMS", "URL"=>"http://bitrix.ru", ), Array( "ID"=>2, "NAME"=>"Digital Workplace", "IMAGE"=>"/demo_api/img/digitalwork.png", "TAGS"=>"Социальный интранет: Эксперты", "URL"=>"http://www.digitalworkplace.ru" ), Array( "ID"=>4, "NAME"=>"1С-Битрикс: Демонстрационный магазин", "URL" => "https://www.1c-bitrix.ru/products/mobile/demo.php", "IMAGE"=>"https://www.1c-bitrix.ru/images/ecommerce/features/mobile/demo.png", "TAGS" => "Демонстрационное мобильное приложение", ), Array( "ID"=>5, "NAME"=>"1С-Битрикс: Администрирование", "IMAGE"=>"https://www.1c-bitrix.ru/images/ecommerce/features/mobile/unnamed.png", "TAGS"=>"Приложение для администраторов и менеджеров", "URL"=>"https://www.1c-bitrix.ru/products/mobile/adm.php" ), Array( "ID"=>6, "NAME"=>"1С-Битрикс: Разработка приложения", "IMAGE"=>"https://www.1c-bitrix.ru/images/ecommerce/features/mobile/dev.png", "TAGS" => "Приложение для разработки собственных мобильных приложений", "URL"=>"https://www.1c-bitrix.ru/products/mobile/#tab-develop-link" ), Array( "ID"=>7, "NAME"=>"Облачный сервис «Инспектор сайта»", "IMAGE"=>"https://www.1c-bitrix.ru/images/ecommerce/features/mobile/inspector1.png", "TAGS" => "Мониторинг доступности и работоспособности сайта", "URL"=>"https://www.1c-bitrix.ru/products/cms/new/#tab-monitor-link" ), Array( "ID"=>8, "NAME"=>"Мобильное приложение «Мой город»", "IMAGE"=>"https://www.1c-bitrix.ru/images/solutions/gov/mobile_map_ios.png", "TAGS" => "Приложение для решения «Сайт государственной организации»", "URL"=>"https://www.1c-bitrix.ru/solutions/gov/site.php#tab-mobile-link!mob" ), Array( "ID"=>9, "NAME"=>"Мобильное приложение для «Битрикс24»", "IMAGE"=>"http://www.bitrix24.ru/images/content/b24-ios7.png", "TAGS" => "Бесплатное приложение для iOS и Android", "URL"=>"http://www.bitrix24.ru/features/apps.php" ), Array( "ID"=>10, "NAME"=>"Управление сайтом", "IMAGE"=>"https://www.1c-bitrix.ru/images/box/bus_154_170.png", "TAGS" => "1С-Битрикс: Управление сайтом", "URL"=>"https://www.1c-bitrix.ru/products/cms/" ), Array( "ID"=>11, "NAME"=>"Корпоративный портал", "IMAGE"=>"https://www.1c-bitrix.ru/images/box/cp141.png", "TAGS" => "1С-Битрикс: Корпоративный портал", "URL"=>"https://www.1c-bitrix.ru/products/intranet/" ) ), ), "names"=>Array("company"=>"Компании") ); echo json_encode($data); ?>
Алфавитный указатель для списка (alphabet_index)
Открытие списка с использованием вертикального алфавитного указателя. Массив объектов разделяется по группам, отсортированные по алфавиту от имени объекта. В качестве разделителя используются секции, имя секции задается первой буквой группы.
Пример:
//Задаем параметры отображения списка var params = { url: "/my_site/list2.php", table_settings: { alphabet_index: true, } }; var alphabet_index_table = new BXMobileApp.UI.Table(params, "table"); alphabet_index_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Пример 3
Источник данных
Источник данных — list3.php:
<? $data = Array( "data"=>Array( "company"=>Array( Array( "ID"=>1, "NAME"=>"Bitrix", "IMAGE"=>"/demo_api/img/bitrixico.png", "TAGS"=>"Отечественная CMS", "URL"=>"http://bitrix.ru", "SECTION_ID"=>"site", ), Array( "ID"=>2, "NAME"=>"Digital Workplace", "SECTION_ID"=>"site", "IMAGE"=>"/demo_api/img/digitalwork.png", "TAGS"=>"Социальный интранет: Эксперты", "URL"=>"http://www.digitalworkplace.ru" ), Array( "ID"=>9, "NAME"=>"Мобильное приложение для «Битрикс24»", "SECTION_ID"=>"bitrix", "IMAGE"=>"http://www.bitrix24.ru/images/content/b24-ios7.png", "TAGS" => "Бесплатное приложение для iOS и Android", "URL"=>"http://www.bitrix24.ru/features/apps.php" ), Array( "ID"=>10, "NAME"=>"Управление сайтом", "SECTION_ID"=>"bitrix", "IMAGE"=>"https://www.1c-bitrix.ru/images/box/bus_154_170.png", "TAGS" => "1С-Битрикс: Управление сайтом", "URL"=>"https://www.1c-bitrix.ru/products/cms/" ), Array( "ID"=>11, "NAME"=>"Корпоративный портал", "SECTION_ID"=>"bitrix", "IMAGE"=>"https://www.1c-bitrix.ru/images/box/cp141.png", "TAGS" => "1С-Битрикс: Корпоративный портал", "URL"=>"https://www.1c-bitrix.ru/products/intranet/" ) ), ), "sections"=>Array( // sections содержит списки секций для каждой категории данных "company"=>Array( //ключ категории данных, значением этого ключа является массив секций списка данной категории Array( "NAME"=>"Bitrix", //наименование секции "ID"=>"bitrix" // строковый идентификатор секции для привязки к ней элементов списка ), Array( "NAME"=>"Сайты", "ID"=>"site" ) ) ), "names"=>Array("company"=>"company") ); echo json_encode($data); ?>
Открытие списка с секциями (use_sections)
Открытие списка с использованием разделительных секций. Массив объектов, отсортированные по заданному идентификатору секции. В качестве имени секции используется наименование секции.
Пример:
//Задаем параметры отображения списка var params = { url: "/my_site/list3.php", table_settings: { use_sections:true, } }; var section_table = new BXMobileApp.UI.Table(params, "table"); section_table.show();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Page — управление страницей (экраном)
Объект предназначен для управления конкретной страницей в стеке навигации. Для каждой страницы можно создать свои нативные элементы интерфейса: кнопки, панели, заголовки, меню и другое.
UI.Page.isVisible
Описание:
Функция проверяет, видит ли пользователь текущую страницуэкран в данный момент.
Синтаксис:
BXMobileApp.UI.Page.isVisible(params);
Аргументы | Описание |
params |
Объект с параметрами: Ключи описания параметров:
|
Пример:
BXMobileApp.UI.Page.isVisible( { 'callback' : function(data) { if (data && data.status == 'visible') { //пользователь видит текущую страницуэкран в данный момент } else { //пользователь не видит текущую страницуэкран в данный момент } } });
UI.Page.reload
Описание:
Функция перезагружает текущий экран.
Синтаксис:
BXMobileApp.UI.Page.reload();
Пример:
//перегружаем текущий экран BXMobileApp.UI.Page.reload();
UI.Page.close
Описание:
Функция закрывает текущий экран, возвращаясь к предыдущему (имитирует нажатие кнопки Назад).
Синтаксис:
BXMobileApp.UI.Page.close(params);
Аргументы | Описание |
params |
Объект параметров закрытия текущего экрана: Ключи описания параметров закрытия текущего экрана:
|
Пример:
//закрываем текущий экран BXMobileApp.UI.Page.close();
UI.Page.captureKeyboardEvents
Описание:
Функция включает или выключает генерацию событий показа/скрытия клавиатуры (onKeyboardWillShow
, onKeyboardWillHide
, onKeyboardDidHide
, onKeyboardDidShow
).
Синтаксис:
BXMobileApp.UI.Page.captureKeyboardEvents(enable_status);
Аргументы | Описание |
enable_status |
По умолчанию — false. |
Пример:
//Включаем слежение за клавиатурой BXMobileApp.UI.Page.captureKeyboardEvents(true); //Регистрирует обработчик события появления клавиатуры BX.addCustomEvent("onKeyboardDidShow", function(){ //клавиатура появилась, здесь можно что-то делать });
BXMobileApp.PageManager — менеджер страниц
Объект BXMobileApp.PageManager предназначен для управления страницами/экранами в рамках стека навигации.
Стек навигации начинается со «стартовой» страницы, с которой нельзя вернуться назад. В стек навигации можно добавлять неограниченное число новых страниц. С каждой добавленной страницы можно перейти назад (программно или через нажатие соответствующей кнопки в панели навигации) — будет осуществлен возврат к предыдущей странице в стеке навигации.
В разных платформах стек навигации ведет себя по-разному в силу архитектурных особенностей.
Особенности на Android:
- По страницам можно перемещаться свайпом;
- После ухода со страницы путем нажатия Назад страница удаляется из стека и из памяти. При повторном добавлении страницы в стек она будет загружаться заново.
Особенности на iOS:
- Перемещаться свайпом можно только к предыдущей странице;
- После ухода со страницы путем нажатия Назад страница удаляется из стека, но не удаляется из памяти. На этой странице будет продолжать работать javascript и при повторном добавлении этой страницы в стек навигации будет взята именно страница из памяти. Перезагрузка страницы при повторном добавлении не осуществляется.
PageManager.loadPageBlank
Описание
Функция добавляет новый экранстраницу к текущей навигационной цепочке с переданным адресом, заголовком и параметрами.
Синтаксис
BXMobileApp.PageManager.loadPageBlank(params);
Аргументы | Описание |
params |
Объект с параметрами страницы: Обязательные:
Необязательные:
|
Пример
//Открытие страницы с заголовком “Demo” BXMobileApp.PageManager.loadPageBlank({ url: "/demo_api/index_demo.php", title: "Demo", });
На открываемой странице нужно получать параметры так:
BXMobileApp.UI.Page.params.get({ callback: function(data) { //using data } });
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
PageManager.loadPageStart
Описание
Функция загружает страницу в качестве стартовой в навигационной цепочке. Перед этим очищается вся цепочка открытых экранов и очищается история переходов.
Синтаксис
BXMobileApp.PageManager.loadPageStart(params);
Аргументы | Описание |
params |
Объект с параметрами страницы: Обязательные:
Необязательные:
|
Пример
BXMobileApp.PageManager.loadPageStart({ url: "/demo_api/index_demo_start.php", title: "Стартовая", page_id: "demo_page_start", });
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
PageManager.loadPageModal
Описание
Функция открывает страницу в модальном окне. Это означает, что создается еще один стек навигации поверх существующего. При закрытии этого окна осуществляется возврат к родительскому экрану.
Синтаксис
BXMobileApp.PageManager.loadPageModal(params);
Аргументы | Описание |
params |
Объект с параметрами страницы: Обязательные:
Необязательные:
|
Пример
BXMobileApp.PageManager.loadPageModal({ url: "/demo_api/index_demo_start.php", title: "Модальная", });
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
PageManager.setWhiteList
Описание
Функция позволяет выставить список дополнительных доменов, которые могут быть открыты внутри приложения. Эта функция может быть использована для реализации авторизации в социальных сетях или оплаты заказов через внешние платежные системы. Функция должна вызываться при каждом запуске приложения, и для использования «белого списка» должна быть вызвана хотя бы один раз на любой странице.
Внимание: Нужно учитывать, что некоторые сайты могут автоматически перенаправлять с указанной страницы на другой адрес, например на тот же домен, но с другим протоколом или на поддомен. Такие адреса также необходимо добавить в «белый список». Формат: <протокол>://<домен>
Синтаксис
BXMobileApp.PageManager.setWhiteList(string);
Аргументы | Описание |
string |
Входящий строковый параметр — список шаблонов, перечисленных через точку с запятой:
|
Примеры
// Доступ к example.com: BXMobileApp.PageManager.setWhiteList("http://example.com") // Доступ по ssl к example.com (https://): BXMobileApp.PageManager.setWhiteList("https://example.com") // Доступ для всех поддоменов example.com, * - можно указать как для всех протоколов, поддоменов, так и для всех ссылок домена: BXMobileApp.PageManager.setWhiteList("http://*.example.com/") // Доступ для любого протокола, любого поддомена: BXMobileApp.PageManager.setWhiteList("*://*.example.com") // Доступ только адреса внутри /path: BXMobileApp.PageManager.setWhiteList("*://*.example.com/path") // Несколько путей: BXMobileApp.PageManager.setWhiteList("*://*.example.ru/*;*://*.example.com/*")
BXMobileApp.UI.Page.TextPanel — нативная панель ввода текста
Нативная панель для ввода текста и обработки этого текста. Располагается внизу экрана и статична относительно web-контента.
Назначение:
- Написание комментариев или отзывов;
- Написание сообщений в чате;
Внимание! Нативная панель ввода текста может быть только одна на страницу.
UI.Page.TextPanel.show
Описание
Функция отображает текстовую панель.
Синтаксис
BXMobileApp.UI.Page.TextPanel.show(params);
Аргументы | Описание |
params |
Объект с параметрами панели ввода текста: Ключи описания параметров панели ввода текста:
|
Пример
//Отобразится текстовая панель, с параметрами по умолчанию BXMobileApp.UI.Page.TextPanel.show();
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.hide
Описание:
Функция скрывает текстовое поле..
Синтаксис:
BXMobileApp.UI.Page.TextPanel.hide()
Пример:
BXMobileApp.UI.Page.TextPanel.hide();
Видео:
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.setParams
Описание. Синтаксис
Описание:
Функция задает параметры для текстовой панели ввода.
Синтаксис:
BXMobileApp.UI.Page.TextPanel.setParams:(params);
Пример и видео 1
//Задаем текст, внутри текстового поля, который пропадет после получения фокуса, и переименовываем название кнопки, заданной по умолчанию var params = { placeholder: "Какой-то текст...", button_name: "Отправить", }; BXMobileApp.UI.Page.TextPanel.setParams(params); //Показываем текстовую панель со своими параметрами BXMobileApp.UI.Page.TextPanel.show();
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Пример и видео 2
//Использование параметра plusAction var params = { placeholder: "Text here...", button_name: "Send", plusAction: function() { app.alert({title:"plusAction", text:"Дополнительные действия"}); } }; BXMobileApp.UI.Page.TextPanel.setParams(params); //Показываем текстовую панель со своими параметрами BXMobileApp.UI.Page.TextPanel.show()
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.setUseImageButton
Описание. Синтаксис
Описание:
Функция делает кнопку Отправить в виде изображения.
Синтаксис:
BXMobileApp.UI.Page.TextPanel.setUseImageButton(use);
Аргументы | Описание |
use |
Флаг, для отображения кнопки в виде изображения:
По умолчанию — false. |
Пример и видео
Пример
BXMobileApp.UI.Page.TextPanel.show(); //передаем true, чтобы показать кнопку "Отправить" в виде изображения. BXMobileApp.UI.Page.TextPanel.setUseImageButton(true);
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.setText
Описание. Синтаксис
Описание:
Функция устанавливает текст в текстовом поле.
Синтаксис:
BXMobileApp.UI.Page.TextPanel.setText(text)
Аргументы | Описание |
text |
Текст, который нужно отобразить в поле |
Пример и видео
Пример
// отображаем нужный текст в текстовом поле; BXMobileApp.UI.Page.TextPanel.show(); BXMobileApp.UI.Page.TextPanel.setText('Мой текст!');
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.focus
Описание. Синтаксис
Описание:
Функция устанавливает фокус в текстовом поле.
Синтаксис:
BXMobileApp.UI.Page.TextPanel.focus();
Пример и видео
Пример
//Покажем текстовую панель с заданным текстом с курсором в конце нашего текста. Клавиатура будет автоматически показана BXMobileApp.UI.Page.TextPanel.show(); BXMobileApp.UI.Page.TextPanel.setText('Мой текст!'); BXMobileApp.UI.Page.TextPanel.focus();
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.clear
Описание. Синтаксис
Описание:
Функция для очистки текстового поля.
Синтаксис:
BXMobileApp.UI.Page.TextPanel.clear();
Пример и видео
Пример
BXMobileApp.UI.Page.TextPanel.clear();
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TextPanel.showLoading
Описание. Синтаксис
Описание:
Кнопка Отправить в виде загрузчика.
Синтаксис:
BXMobileApp.UI.Page.TextPanel.showLoading: function(shown){};
Аргументы | Описание |
shown |
Флаг, для отображения кнопки в виде загрузчика:
|
Пример и видео
Пример
//Передаем true, чтобы показать кнопку "Отправить" в виде изображения, false - чтобы убрать. BXMobileApp.UI.Page.TextPanel.showLoading(true);
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Page.TopBar — навигационная панель
Навигационная панель располагается вверху экрана в центральной части слайдера. Панель статична относительно веб-страницы.
Назначение:
- Вывод активных заголовков страницы;
- Вывод нативных кнопок страницы.
Каждая страницы в стеке навигации имеет свой персональный вид навигационной панели (заголовок и кнопка). При переходе от страницы к странице данные в навигационной панели меняются автоматически.
UI.Page.TopBar.hide
Описание. Синтаксис
Описание:
Функция скрывает навигационную панель.
Синтаксис:
BXMobileApp.UI.Page.TopBar.hide();
Пример и видео
Пример
//Cкрываем навигационную панель BXMobileApp.UI.Page.TopBar.hide();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.show
Описание. Синтаксис
Описание:
Функция отображает верхнюю панель.
Синтаксис:
BXMobileApp.UI.Page.TopBar.show();
Пример и видео
Пример
//Показываем скрытую навигационную панель. BXMobileApp.UI.Page.TopBar.show();
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.addRightButton
Описание
Функция добавляет правую кнопку на навигационную панель.
Синтаксис
BXMobileApp.UI.Page.TopBar.addRightButton: function(buttonObject){};
Аргументы | Описание |
buttonObject |
Объект с параметрами правой кнопки на навигационной панели: Ключи описания параметров кнопки:
|
Пример
//Отображаем правую кнопку на навигационной панели, с кнопкой и текстом на ней, при нажатии на которую будет показано сообщение. var params = { callback:function(){ app.alert({title:"addRightButton", text:"Вы нажали правую кнопку!"}); }, name:"Right Text", type:"text" }; BXMobileApp.UI.Page.TopBar.addRightButton(params);
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.setColors
Описание
Цветовая настройка навигационной панели.
Синтаксис
BXMobileApp.UI.Page.TopBar.setColors(params);
Аргументы | Описание |
buttonObject |
Параметры настройки цветов панели уведомления:
|
Пример
BXMobileApp.UI.Page.TopBar.setColors( { background:"#fb0000", titleText: "#ffffff", titleDetailText: "#ffffff" });
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.updateButtons
Описание
Функция обновляет правую кнопку на навигационной панели.
Синтаксис
BXMobileApp.UI.Page.TopBar.updateButtons: function(buttonObject){};
Аргументы | Описание |
buttonObject |
Объект с параметрами правой кнопки на навигационной панели. Ключи описания параметров кнопки:
|
Пример
//Обновляем правую кнопку на навигационной панели, при нажатии на которую будет показано сообщение. var params = { button1:{ callback:function(){ app.alert({title:"updateButtons", text:"Вы обновили правую кнопку!"}); }, type:"refresh" } }; BXMobileApp.UI.Page.TopBar.updateButtons(params);
BXMobileApp.UI.Page.TopBar.title — управление заголовком
Объект позволяет управлять активным заголовком страницы, который отображается в навигационной панели.
UI.Page.TopBar.title.setText
Описание. Синтаксис
Описание:
Функция задает текст заголовка на верхней панели.
Внимание! Для отображения всего заголовка (с картинкой и детальным текстом) обязательно должен быть задан основной текст.
Синтаксис:
BXMobileApp.UI.Page.TopBar.title.setText(text)
Аргументы | Описание |
text |
Основной текст заголовка |
Пример и видео
Пример
//Задаем текст к заголовку BXMobileApp.UI.Page.TopBar.title.setText('Title Text Test Navigation');
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.title.setDetailText
Описание. Синтаксис
Описание:
Функция задает дополнительный текст заголовка.
Синтаксис:
BXMobileApp.UI.Page.TopBar.title.setDetailText(text);
Аргументы | Описание |
text |
Текст детального заголовка |
Пример и видео
Пример
//Задаем дополнительный текст к заголовку BXMobileApp.UI.Page.TopBar.title.setDetailText('Detail Text');
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.title.setImage
Описание. Синтаксис
Описание:
Функция задает изображение к заголовку на верхней панели.
Синтаксис:
BXMobileApp.UI.Page.TopBar.title.setImage(imageUrl);
Аргументы | Описание |
imageUrl |
Путь до изображения. Возможен вариант указания полного пути к картинке со стороннего сервера: |
Пример и видео
Пример
//Задаем изображение к заголовку var url = '/my_site/img.png'; BXMobileApp.UI.Page.TopBar.title.setImage(url);
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.title.setCallback
Описание. Синтаксис
Описание:
Функция для установки javascript-обработчика нажатия на заголовок в навигационной панели. Используется только после применения.
Синтаксис:
BXMobileApp.UI.Page.TopBar.title.setCallback(callback);
Аргументы | Описание |
callback |
Обработчик события нажатия на заголовок. |
Пример и видео
Пример
//По нажатию на заголовок, выводим сообщение BXMobileApp.UI.Page.TopBar.title.setCallback(function() { app.alert({title:"setCallback", text:"Вы нажали на Заголовок!"}); });
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.title.show
Описание. Синтаксис
Описание:
Функция отображает заголовок в навигационной панели.
Синтаксис:
BXMobileApp.UI.Page.TopBar.title.show(params);
Пример и видео
Пример
//Задаем текст заголовка BXMobileApp.UI.Page.TopBar.title.setText('Title Text Test Navigation'); //Отображаем заголовок в навигационной панели. BXMobileApp.UI.Page.TopBar.title.show();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.TopBar.title.hide
Описание. Синтаксис
Описание:
Функция для скрытия заголовка в навигационной панели.
Синтаксис:
BXMobileApp.UI.Page.TopBar.title.hide: function(){};
Пример и видео
Пример
//Скрываем заголовок на навигационной панели BXMobileApp.UI.Page.TopBar.title.hide();
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Page.SlidingPanel — скользящая панель
Скользящая панель — это дополнительный элемент интерфейса, который предназначен для размещение кнопок, выполняющих быстрые действия на текущем экране или странице. Панель располагается под навигационной панелью.
Скользящая панель имеет два режима поведения:
- Статичный — при скроллировании страницы панель остается на месте;
- Скользящий — при скроллировании страницы вниз панель скрывается.
Скользящая панель может быть только одна на страницу.
UI.Page.SlidingPanel.show
Описание
Функция отображает скользящую панель.
Синтаксис
BXMobileApp.UI.Page.SlidingPanel.show(params);
Аргументы | Описание |
params |
Объект параметров скользящей панели: Ключи описания параметров скользящей панели:
|
Пример
//Создаем скользящую панель с тремя кнопками разных типов и обработчиками событий при нажатии на каждую кнопку. BXMobileApp.UI.Page.SlidingPanel.show({ hidden_sliding_panel: true, scroll_backlash: 20.0, buttons: { id_button1: { name: "Только текст", type: "right_text", callback: function () { app.alert({title:"SlidingPanel", text:"Только текст"}); } }, id_button2: { name: "Текст", type: "basket", callback: function () { app.alert({title:"SlidingPanel", text:"Иконка и текст"}); } }, id_button3: { name: "", type: "menu", callback: function () { app.alert({title:"SlidingPanel", text:"Только иконка"}); } } } });
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.SlidingPanel.hide
Описание. Синтаксис
Описание:
Функция для скрытия панели.
Синтаксис:
BXMobileApp.UI.Page.SlidingPanel.hide();
Пример и видео
Пример
//Скрываем дополнительную кнопочную панель BXMobileApp.UI.Page.SlidingPanel.hide();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Page.LoadingScreen — экран загрузки
Экран загрузки — это нативный элемент, который застилает веб-контент с индикатором загрузки в середине. Его можно увидеть при загрузке/перезагрузке страницы.
Предназначен для отображения потенциально длительных процессов запроса и обработки данных или скрытия процесса динамического перестроения интерфейса страницы.
UI.Page.LoadingScreen.show
Описание. Синтаксис
Описание:
Функция для показа экран загрузки на странице.
Синтаксис:
BXMobileApp.UI.Page.LoadingScreen.show();
Пример и видео
Пример
//Отображаем экран загрузки на странице BXMobileApp.UI.Page.LoadingScreen.show();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.LoadingScreen.hide
Описание. Синтаксис
Описание:
Функция для скрытия экрана загрузки на странице.
Синтаксис:
BXMobileApp.UI.Page.LoadingScreen.hide();
Пример и видео
Пример
//Скрываем экран загрузки на странице BXMobileApp.UI.Page.LoadingScreen.hide();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.LoadingScreen.setEnabled
Описание
Функция включает или отключает возможность автоматического показа / скрытия загрузочного экрана в текущей странице.
Синтаксис
BXMobileApp.UI.Page.LoadingScreen.setEnabled(enabled);
Аргументы | Описание |
enabled |
Флаг, управляющий автоматическим показом загрузочного экрана:
|
Пример
//запрещаем автоматический показ загрузочного экрана BXMobileApp.UI.Page.LoadingScreen.setEnabled(false);
BXMobileApp.UI.Page.Scroll — управление скроллингом
Объект для управления скроллингом страницы.
UI.Page.Scroll.setEnabled
Описание:
Функция разрешает/запрещает скроллинг на странице.
Синтаксис:
BXMobileApp.UI.Page.Scroll.setEnabled(enabled);
Аргументы | Описание |
enabled |
Флаг,определяющий использования скроллинга на странице:
|
Пример:
//запрещаем использование скроллинга на странице BXMobileApp.UI.Page.Scroll.setEnabled(false);
BXMobileApp.UI.Page.Refresh — контрол обновления
Нативный контрол обновления, предназначен для отображения процесса обновления.
UI.Page.Refresh.setParams
Описание
Функция для установки параметров контрола обновления.
Синтаксис
BXMobileApp.UI.Page.Refresh.setParams(params);
Аргументы | Описание |
params |
Объект параметров контрола обновления: Ключи описания параметров скользящей панели:
|
Пример
//Задаем свои параметры для контрола обновлений, с сопроводительным текстом при обновлении, заданным максимальным временем отображения контрола и обработчика событий. var params = { timeout: "20", enabled: true, callback: function (){app.alert({title:"Pull to Refresh", text:"Pull to refresh!"})}, pullText: "Pull to refresh", releaseText: "Release to refresh", loadText: "Loading..." }; BXMobileApp.UI.Page.Refresh.setParams(params);
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.Refresh.setEnabled
Описание:
Функция активирует контрол обновление. Пользователь может потянуть страницу вниз и отработает js-функция обратного вызова (см. параметр callback). В функции обратного вызова можно совершать произвольные действия, по окончании которых анимацию обновления следует остановить (см. BXMobileApp.UI.Page.Refresh.stop).
Синтаксис:
BXMobileApp.UI.Page.Refresh.setEnabled(enabled);
Аргументы | Описание |
enabled |
Флаг задает состояние отображения контрола обновлений на странице:
|
Пример:
//Деактивация контрола BXMobileApp.UI.Page.Refresh.setEnabled(false);
UI.Page.Refresh.start
Описание. Синтаксис
Описание:
Функция стартует анимацию обновления, программно (без участия пользователя).
Синтаксис:
BXMobileApp.UI.Page.Refresh.start();
Пример и видео
Пример
//Старт анимации BXMobileApp.UI.Page.Refresh.start();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Page.Refresh.stop
Описание. Синтаксис
Описание:
Функция останавливает анимацию обновления.
Синтаксис:
BXMobileApp.UI.Page.Refresh.stop();
Пример и видео
Пример
//Останавливаем анимацию BXMobileApp.UI.Page.Refresh.stop();
Видео:
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.ActionSheet — выпадающее меню
Описание
Функция создает набор кнопок, представляющих несколько возможных вариантов выполнения действий.
Синтаксис
BXMobileApp.UI.ActionSheet(params, id);
Аргументы | Описание |
id |
Идентификатор выпадающего меню. |
params |
Объект параметров выпадающего меню: Ключи описания параметров выпадающего меню:
|
Пример
//Создаем выпадающее меню, с двумя кнопками и обработчиками событий при нажатии на данные кнопки. В данном примере “test” является идентификатором данного выпадающего меню. var actionSheet = new BXMobileApp.UI.ActionSheet( { title:"Продукты Bitrix", buttons: [ { title:"Управление сайтом", callback:function() { app.alert({ title: "Управление сайтом", button: "OK", text: "Профессиональная система управления веб-проектами, универсальный программный продукт для создания, поддержки и успешного развития" }); } }, { title:"Корпоративный портал", callback:function() { app.alert({ title: "Корпоративный портал", button: "OK", text: "Система управления внутренним информационным ресурсом компании для коллективной работы над задачами, проектами и документами, для эффективных внутренних коммуникаций. " }); } }, { title:"Мобильное приложение", callback:function() { app.alert({ title: "Мобильное приложение", button: "OK", text: "Это технология, позволяющая быстро разрабатывать мобильные приложения под iOS и Android для сайтов, созданных на платформе «1С-Битрикс»." }); } } ] }, "test");
UI.ActionSheet.show
Описание. Синтаксис
Описание:
Функция для отображения созданного выпадающего меню.
Синтаксис:
BXMobileApp.UI.ActionSheet.show();
Пример
//Создаем выпадающее меню с двумя кнопками и обработчиками событий при нажатии на данные кнопки. В данном примере “test” является идентификатором данного выпадающего меню. var actionSheet = new BXMobileApp.UI.ActionSheet( { title:"Продукты Bitrix", buttons: [ { title:"Управление сайтом", callback:function() { app.alert({ title: "Управление сайтом", button: "OK", text: "Профессиональная система управления веб-проектами, универсальный программный продукт для создания, поддержки и успешного развития" }); } }, { title:"Корпоративный портал", callback:function() { app.alert({ title: "Корпоративный портал", button: "OK", text: "Система управления внутренним информационным ресурсом компании для коллективной работы над задачами, проектами и документами, для эффективных внутренних коммуникаций. " }); } }, { title:"Мобильное приложение", callback:function() { app.alert({ title: "Мобильное приложение", button: "OK", text: "Это технология, позволяющая быстро разрабатывать мобильные приложения под iOS и Android для сайтов, созданных на платформе «1С-Битрикс»." }); } } ] }, "test"); //Отображаем созданное выпадающее меню. actionSheet.show();
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Menu — контекстное меню
Описание
Функция создает контекстное меню страницы.
Синтаксис
BXMobileApp.UI.Menu(params, id);
Аргументы | Описание |
params |
Объект параметров контекстного меню: Ключи описания параметров контекстного меню:
|
id |
Идентификатор контекстного меню. |
Пример
//Создаем контекстное меню, состоящее из трех пунктов. В данном примере “test” является идентификатором данного контекстного меню. var menu = new BXMobileApp.UI.Menu( { items: [ { name:"Управление сайтом", image: "/demo_api/img/upravlenie-saitom.png", url:"http://www.1c-bitrix.ru/products/cms/", }, { name:"Корпоративный портал", action:function() { app.alert( { title: "Корпоративный портал", button: "OK", text: "Система управления внутренним информационным ресурсом компании для коллективной работы над задачами, проектами и документами, для эффективных внутренних коммуникаций. " }); }, icon: 'check' }, { name:"Мобильное приложение", url:"/my_site/index2.php", arrowFlag:"true" } ] }, "test");
UI.Menu.show
Описание. Синтаксис
Описание:
Функция для отображения созданного контекстного меню.
Синтаксис:
BXMobileApp.UI.Menu.show();
Пример
//Создаем контекстное меню, состоящее из трех пунктов. В данном примере “test” является идентификатором данного контекстного меню. var menu = new BXMobileApp.UI.Menu( { items: [ { name:"Управление сайтом", image: "/demo_api/img/upravlenie-saitom.png", url:"http://www.1c-bitrix.ru/products/cms/", }, { name:"Корпоративный портал", action:function() { app.alert( { title: "Корпоративный портал", button: "OK", text: "Система управления внутренним информационным ресурсом компании для коллективной работы над задачами, проектами и документами, для эффективных внутренних коммуникаций. " }); }, icon: 'check' }, { name:"Мобильное приложение", url:"/my_site/index2.php", arrowFlag:"true" } ] }, "test"); //Отобразим данное контекстное меню путем нажатия на заголовок в навигационной панели, используя методы навигационной панели. Задаем основной текст заголовка, используя BXMobileApp.UI.Page.TopBar.title.setText();. Используя обработчик события нажатия на заголовок BXMobileApp.UI.Page.TopBar.title.setCallback();, отобразим созданное контекстное меню. Используем BXMobileApp.UI.Page.TopBar.title.show();, чтобы отобразить активный заголовок на навигационной панели. BXMobileApp.UI.Page.TopBar.title.setText('Заголовок'); BXMobileApp.UI.Page.TopBar.title.setCallback(function() { menu.show();//отображаем созданное контекстное меню }); BXMobileApp.UI.Page.TopBar.title.show();
Видео
iOS | Android |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Menu.hide
Описание:
Функция для программного скрытия контекстного меню.
Синтаксис:
BXMobileApp.UI.Menu.hide();
Пример:
//Скрываем контекстное меню. BXMobileApp.UI.Menu.hide();
BXMobileApp.UI.NotificationBar — локальные уведомления
Описание
Локальные уведомления используются для оповещения пользователя о каких-либо событиях, о протекании каких-либо процессов. Например, в интернет-магазине можно сообщать пользователю о смене статуса заказа, в чате можно показать новое сообщение от пользователя или оповестить о проблемах соединения с сервером.
Синтаксис
BXMobileApp.UI.NotificationBar(params);
Аргументы | Описание |
params
|
Параметры уведомления:
|
Важно! Параметр groupId служит для объединения уведомлений в одну группу. Уведомления, принадлежащие одной группе, не могут одновременно отображаться на экране. Соответственно, если было создано уведомление А и Б с одинаковым groupId, то при показе уведомления А будет автоматически скрыто уведомление Б, если оно отображается в данный момент.
Пример. Уведомление с лоудером
// Уведомление с лоудером var notifyBar = new BXMobileApp.UI.NotificationBar( { message: ‘Уведомление с лоудером’, useLoader: true, align:"center", color: "#76088c", autoHideTimeout:2000, hideOnTap:true, }); notifyBar.show(); //show - функция отображения панели уведомления. notifyBar.hide(); //hide - функция скрытия панели уведомления.
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Пример. Многострочное уведомление с картинкой
// Многострочное уведомление с картинкой new BXMobileApp.UI.NotificationBar( { message: ‘Демо нотификационной панели. Панель можно увеличить, уменьшить, добавить иконку, картинку, загрузчик, поменять цвет фона и текста. Также можно изменить прозрачность от 0 до 100%’, maxLines: 10, contentType: 'html', indicatorHeight:60, autoHideTimeout:10000, hideOnTap:true, textColor:"#ffffff", color:"#cc000000", imageURL: dataPath+"/img/addition-icon.png" }).show();
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
BXMobileApp.UI.Badge — управление бейджами
UI.Badge.setIconBadge
Описание. Синтаксис
Описание:
Счетчик на иконке приложения. Указывает на пропущенные уведомления в приложении.
Синтаксис:
BXMobileApp.UI.Badge.setIconBadge(number);
Аргументы | Описание |
params |
Объект с параметрами страницы:
|
Пример и видео
Пример
//Передаем бейджу на иконке приложения значение, равное 2 BXMobileApp.UI.Badge.setIconBadge(2);
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
UI.Badge.setButtonBadge
Описание. Синтаксис
Описание:
Счетчик на кнопках в приложении. Указывает на пропущенные уведомления.
Синтаксис:
BXMobileApp.UI.Badge.setButtonBadge(badgeCode, number);
Аргументы | Описание |
params |
Объект с параметрами страницы:
|
Пример и видео
Пример
//Назначаем кнопке с указанным badgeCode 'demobutton' бейдж со значением, равное 3 BXMobileApp.UI.Badge.setButtonBadge('demobutton', 3);
Видео
iOS |
Ваш браузер не поддерживает тег «video» — просмотр невозможен! |
Мы уже больше года рассказываем о приложениях для Битрикс24. Наши эксперты изучили и подготовили обзоры более 130 приложений! Если вы еще не видели эти обзоры, крайне рекомендуем ознакомиться, наверняка вы найдете для себя что-то интересное. Все обзоры приложений собраны тут. Сегодня мы решили копнуть глубже и рассказать не просто про готовые приложения, а про процесс разработки приложений для Битрикс24. Наша команда регулярно создает приложения, которые помогают решать различные задачи клиентов, так что нам есть, что рассказать.
Руководитель отдела веб-разработки — Вадим Солуянов согласился поделиться своим бесценным опытом разработки приложений для интеграции сторонних сервисов с Битрикс24. Так как материал получился очень объемным, мы разделим его на 4 части, поэтому рекомендуем подписаться на нас в социальных сетях, чтобы ничего не пропустить. Описание работы над приложением будет вестись от лица Вадима. Итак, поехали!
С чего начинается приложение?
Моя задача при написании данного текста — обобщить опыт разработки интеграций портала Битрикс24 со сторонними сервисами, выделить в приложениях и работе над ними общие моменты, функционал, необходимый любому приложению, чтобы считать его хорошо написанным. Вероятно, нет хороших приложений и плохих исключительно по причине широты выполняемых ими задач. Даже при работе над маленьким можно проявить все свои таланты и написать все грамотно, ничего не упустив. Так, что в дальнейшем и вы сами, и другие разработчики не смогут ни к чему придраться и сказать, что это так себе приложеньице.
Из сказанного получается, что в качестве примера можно взять простую задачу и на ней провести анализ самого процесса разработки, составных частей программы, выполняемых подзадач, необходимых для ее эксплуатации в дальнейшем. В качестве такого примера я возьму интеграцию СМС-провайдера с порталом Битрикс24. В голове я при этом буду удерживать конкретное приложение, конкретную интеграцию, подглядывать в его логи и код, но для общего анализа совсем не важно, чего с чем оно действительно интегрирует.
Еще немного о приложении. Существует несколько способов работы с порталом Битрикс24. Здесь речь пойдет о приложении с пользовательским интерфейсом и размещаемом на стороннем сервере. Таким образом, в интеграции будет участвовать как минимум три сервера: портала, нашего приложения и СМС-провайдера.
Итак, поставлю задачу.
СМС-провайдер предоставляет API для отправки СМС-ок, отслеживания текущего статуса конкретного СМС-сообщения, получения сведений об аккаунте и текущем балансе пользователя. С другой стороны, портал Битрикс24 имеет API для регистрации СМС-провайдера, смены статуса отправленного сообщения, а также дает зарегистрированному провайдеру команду на отправку конкретного СМС. Наша задача связать одно с другим так, чтобы, например, при смене статуса у сделки в CRM кому-то отправлялось СМС-уведомление, а при изменении его статуса у СМС-провайдера менялся соответственно статус сообщения на портале.
Выделим подзадачи из этой общей. В итоге получим такие точки входа в приложение:
- install — установка приложения,
- settings — настройка его параметров,
- handler — обработка команд на отправку СМС,
- task — периодическая проверка статуса СМС,
- statistic — сбор статистики по работе и ошибкам приложения.
Во-первых, установка. В принципе, Битрикс24 не требует подобной точки входа, приложение будет установлено и без нее, но было бы неплохо регистрировать где-то у себя сам факт установки. В дальнейшем появится и еще одна тому причина, но пока довольно и одной. При установке необходимо где-то зафиксировать, что на таком-то портале было установлено наше приложение в такой-то день и т.п. Сразу следует отметить одну особенность Битрикс24: на данную точку входа портал постучит не только при установке приложения, но и при обновлении с версии на версию. Поэтому, регистрируя факт установки, нам потребуется отличить первую установку от обновлений. Сделать это элементарно по наличию у нас записи об установке: если она есть, значит произошло обновление, если нет — установка. Отмечу также, что установка — это страница с пользовательским интерфейсом. Она может содержать какую-то информацию, а может лишь вызывать метод js-библиотеки, предоставляемой Битрикс24, который фиксирует факт установки. Допустим, что у нас будет лишь этот вызов: BX24.installFinish(). После чего портал перенаправит пользователя на основную страницу приложения, т.е в настройки.
Теперь настройки. В данном приложении они совершенно необходимы, поскольку для взаимодействия с СМС-провайдером нам потребуются авторизационные данные. Это может быть т.н. API Key или логин и пароль или, как предпочитают делать в последнее время, логин и API Key вместо пароля. Эти данные мы можем получить лишь от самого пользователя, установившего приложение. Отмечу сразу, что для нашей задачи не требуется спрашивать ключи от каждого пользователя портала, одной авторизации будет достаточно. Итак, необходимо вывести на странице форму с полями ввода, в которых указать текущие значения, если они уже есть. Будет также неплохо дать возможность здесь же сразу проверить их валидность, предоставив возможность отправки тестового СМС-сообщения.
Обработчик. При описании настроек я забыл упомянуть еще об одном, спрятанном в backend действии в случае, когда авторизационные данные первый раз получены и проверены на валидность. Это регистрация на портале СМС-провайдера. При его регистрации мы указываем среди прочего URL обработчика команды на отправку сообщения. И в данной точке входа (handler) мы получаем набор параметров, среди которых есть само сообщение, а также номер телефона, на который оно должно быть отправлено. Задача обработчика постучать с этими данными (используя авторизацию, сохраненную в настройках) к СМС-провайдеру, вызывая некий его метод send и получая ответ об успешной или неудачной постановке в очередь на отправку. Когда она успешна, то нам вернется уникальный идентификатор сообщения у провайдера.
Проверка статуса. Еще одно упущение в описании. Чтобы проверять статус доставки нам в обработчике необходимо где-то у себя фиксировать факт отправки вместе со всеми данными, которые нам потребуются, чтобы узнать текущий статус и, если он изменился, передать его на портал. И тут всплывает еще одна недоделка. Чтобы выполнить что-либо на портале, нам необходим access_token — авторизационный ключ, который подтвердит наши права на запрашиваемое действие. Когда портал стучится на такие точки входа как install, settings, handler, то в самом запросе присылает нам авторизационные данные того пользователя, что зашел в приложение, но в данном случае проверка запускается без кого-либо, через cron сервера, где расположено приложение. Получается, что нам необходимо еще и хранить где-то авторизационные данные пользователя. Авторизацию СМС-провайдера мы сохраняли в настройках, а авторизацию портала можно, конечно, хранить вместе с данными о сообщении, но все-таки лучше их вынести куда-то отдельно в привязке к порталу и пользователю на нем. Почему лучше? Это станет понятнее, когда речь зайдет о refresh_token’е.
Статистика. Если мы хотим не просто написать приложуху, выложить в открытый доступ и забыть о ее существовании, то нам потребуется собирать статистику. Во-первых, для того, чтобы видеть насколько востребовано приложение, во-вторых, для технической поддержки. Под статистикой я подразумеваю два хранилища данных: лог приложения, в котором фиксируются действия и данные в ключевых точках программы, фиксируются факты установки, удаления, успешной/неудачной отправки/доставки, ошибки и собственно статистика — собранные за день и сложенные в одну цифру интересующие нас факты… Упс. Удаление… Придется внести правки в изначальный список точек входа. Теперь он будет выглядеть так:
- install,
- settings,
- handler,
- event_handler — обработка событий портала,
- task,
- statistic.
Появилась еще одна — обработчик событий. Факт удаления нашего приложения мы можем узнать лишь подписавшись в портале на событие OnAppUninstall. Когда оно произойдет, портал стукнется на тот URL, что мы указали при подписке. Помимо того, что мы зафиксируем факт удаления, мы еще и почистим все хранилища (за исключением логов и статистики) от записей, привязанных к данному порталу, поскольку от них больше никакого проку.
Ну, вот теперь все точки входа в наше приложение вкратце описаны, выяснены действия, какие необходимо выполнить, и данные, которые необходимо где-то у себя хранить. Было бы неплохо их еще раз перечислить отдельно от описания точек входа. Итак:
Действия
- При установке подписаться на событие OnAppUninstall.
- Зафиксировать факт установки или обновления в логах.
- Сделать где-то запись о портале, на котором произошла установка, чтобы в дальнейшем мы могли отличать установку от обновления.
- Получить текущие данные по авторизации из хранилища, если есть, и вывести в виде формы пользователю.
- Проверить новые авторизационные данные и, если они валидны, сохранить у себя.
- При первом получении валидных данных зарегистрировать на портале СМС-провайдер.
- В случае получения невалидных данных вывести пользователю сообщение об этом.
- При получении запроса на отправку тестового СМС выполнить отправку.
- После отправки тестового СМС вывести пользователю результат отправки.
- В hanlder при получении запроса выполнить отправку.
- При отправке запомнить все необходимые данные для дальнейшей проверки статуса.
- При получении уведомления об удалении приложения (OnAppUninstall) зафиксировать данный факт в логах и очистить хранилище от записей, связанных с данным порталом, за исключением логов и статистики.
- Периодически проверять статусы отправленных сообщений. Например, раз в 10 минут.
- Раз в сутки запускать сбор статистики, суммируя факты интересующих событий, произошедших за предыдущие сутки.
- Раз в сутки очищать хранилище от: 1) логов, старее времени, в течение которого мы их собираемся хранить (надо заметить что в требованиях к приложениям Битрикс24 указывает на обязательное хранение rest-запросов к порталу в течение 3 суток); 2) данных о сообщениях, которые были успешно/неудачно доставлены, т.е. уже не требующие дальнейшей проверки статуса (их мы храним какое-то время на случай, если они потребуются для техподдержки).
Данные
- Сведения о портале.
DOMAIN — доменное имя портала
MEMBER_ID — уникальный идентификатор портала на сервере авторизации
LICENSE_TYPE — тип лицензии (напр., чтобы знать бесплатники пользуются или не только)
… — другие интересующие о портале данные
DATE_INSTALL — дата установки приложения
DATE_UPDATE — дата обновления версии приложения
VERSION — текущая установленная версия -
Логирование.
DOMAIN — домен портала (все-таки при техподдержке с ним работать удобнее)
MEMBER_ID — идентификатор портала (домен может быть переименован, но id — нет)
EVENT_TYPE — тип события (напр., факт установки — INSTALL)
EVENT_DATA — любые интересующие данные в виде текста
DATE_CREATE — дата и время события в понятном человеку написании
DATE_POINT — дата, время и миллисекунды для сортировки и получения точной последовательности событий (просто DATE_CREATE для этого не хватит, поскольку за одну секунду может произойти несколько событий) -
Хранение авторизации СМС-провайдера
Для простоты добавим поля к п.1 в те самые другие поля
API_LOGIN — логин у СМС-провайдера
API_KEY — АПИ ключ -
Отправленные сообщения
DOMAIN
MEMBER_ID
BX_USER_ID — униальный в рамках портала id пользователя
MESSAGE_ID — идентификатор сообщения на портале
EXT_MESSAGE_ID — идентификатор на стороне СМС-провайдера
STATUS — текущий статус у СМС-провайдера
DATE_CREATE — дата создания записи
DATE_UPDATE — дата обновления записи
VERSION — версия приложения -
Авторизация пользователя портала
DOMAIN
MEMBER_ID
BX_USER_ID — униальный в рамках портала id пользователя
ACCESS_TOKEN — собственно, тот токен, с которым будем стучаться на портал
REFRESH_TOKEN — токен для обновления access_token
REFRESH_DATE_END — последняя дата-время валидности refresh_token
VERSION — версия приложения -
Статистика
DOMAIN
MEMBER_ID
EVENT_TYPE — тип события
DAY_VALUE — количество событий за день
DATE_CREATE — дата, на которую собрана статистика
Хранилище данных требует пояснений. Например, почему всюду дублируется домен и id портала. Ну.., домен, потому что так удобнее просматривать и фильтровать записи при осуществлении технической поддержки, а MEMBER_ID… можно, конечно, привязку сделать по первичному ключу с данными из п.1 (Сведения о портале). Но и выборки придется делать всегда с джойном двух таблиц… Короче, я выбираю именно вариант с id портала в каждой таблице. Когда мы работаем с порталом, то у нас в наличии всегда именно member_id, он приходит с портала, и его же мы посылаем самим себе при обращении с фронта в бэк.
Далее VERSION. Зачем она нужна в сообщениях и пользователях? Все дело в версиях приложений Битрикс24. При установке приложения (такого, как наше) на портале лишь создается где-то запись об установке, запоминаются URL-ы к приложению и все. Таким образом, на разных порталах могут размещаться самые разные версии одного приложения. И, если при создании новой, вы создаете еще один экземпляр, при этом меняется URL, то вы вынуждены сохранять и экземпляр предыдущей версии, поскольку обновление приложения на портале не происходит автоматически. Он лишь сообщает о выходе новой версии, но только пользователь может дать команду на обновление. Создавать отдельные хранилища под каждую версию — это, конечно, идиотизм, который при смене версии приведет к необходимости перетаскивать данные из одного в другое. Таким образом, хранилище для всех версий одно и то же. Но что, если в новой версии вы добавили не существовавший ранее функционал и поля данных под него, а старая версия ничего о нем и них не знает? Она запустит обработку очереди сообщений и обработает и те, что были созданы уже новой версией, без дополнительного нового функционала. Вот для этого и VERSION, чтобы каждая версия занималась только своими данными.
И еще одно важное замечание по поводу версий. Во всех местах программы, где вы указываете путь к приложению, а это URL обработчика событий, это URL для атрибута action формы настроек, это URL отправки тестового СМС из фронта в бэк, всюду URL должен формироваться динамически, исходя из текущего расположения приложения. Иначе при выпуске новой версии вам придется лазить по всему коду и заменять. Даже, если вынесете эти URL-ы в конфигурационный файл, всегда можно что-то пропустить. Динамическое формирование URL-ов самое правильное.
Теперь REFRESH_DATE_END в таблице пользователей. Токен, с которым мы стучимся на портал, живет лишь один час, а затем требует обновления через refresh_token, но у того самого (пока еще) есть собственный lifetime размером в 30 дней. Чтобы не потерять возможность делать запросы от лица каждого пользователя, мы обязаны отслеживать момент окончания валидности и делать обновление. По данному полю мы определяем такую необходимость. Вот поэтому я и вынес авторизацию пользователей в отдельное хранилище, поскольку по нему придется периодически пробегать, обновляя токены. Ну и с точки зрения построения баз данных это правильнее. И еще замечание по токенам. Если приложение размещается не на вашем сервере, а может, даже и в этом случае, токены следует хранить в зашифрованном виде.
Итак, после перечисления всех данных мы обнаруживаем, что список наших действий необходимо дополнить пунктом 16.
16. Обновление refresh_token-ов, у которых срок жизни приближается к 30 дням, раз в сутки.
Ну вот, теперь и действия все прописаны и данные описаны. Можно переходить к следующему шагу и рассмотреть каждую точку входа подробнее. Примечание, я не стану говорить об архитектуре приложения, поскольку тут многое зависит и от языка программирования, и от сложившейся практики у конкретных разработчиков. Речь только о построении приложения без специфических языковых особенностей.
Продолжение следует…
#Руководства
- 7 июн 2018
-
7
Узнаём возможности фреймворка 1С-Битрикс, делаем первые шаги к его изучению и разбираемся, почему так много специалистов выбирают эту CMS.
Веб-разработчик, запустил более 20 крупных проектов, включая онлайн-франчайзинг «Позитроника», сайт фабрики «Яршинторг» и многие другие.
ВРЕМЯ ПРОСМОТРА
1 ч. 16 мин.
- 55% компаний в России используют 1С‑Битрикс — услуги разработчиков на этой платформе востребованы.
- Быстрое решение типовых задач и уже готовые решения от Битрикса. Например, онлайн-кассы легко интегрируются с платёжными системами и сервисами доставки.
- Много возможностей. Битрикс включает в себя блоги, форумы, каталоги разных видов, интеграцию с социальными сетями и многое другое. Также есть библиотеки, которые позволяют додумывать и создавать свои расширения.
- Сжатые сроки изучения. Чтобы начать работать с Битриксом, достаточно за 2,5–3 месяца пройти теорию — и можно сразу практиковаться, работая с реальными сайтами и наращивая свои знания.
- Универсальность. На Битриксе создаются и сайты-визитки, и крупные интернет-магазины.
- Документация на русском языке. Она есть в открытом доступе, её легко изучать.
- Большое комьюнити специалистов. Новичку всегда легко найти ответы на свои вопросы или дополнительную информацию, а значит, легче развиваться.
Представьте команду разработчиков, которая решила создать интернет-магазин. Она разработала сайт на чистом PHP, но потом взялась за новый. Тогда команда поняла, что часть функций и модулей уже написаны для первого сайта.
Фреймворк — структура, в которой отдельными модулями выделены, например, визуальная составляющая и функциональный код. Когда есть фреймворк, можно не писать сайт с нуля, а управлять им с помощью уже готовых блоков. Этот продукт представляет собой CMS — систему управления контентом на сайте.
Все сайты на Битриксе состоят из трёх компонентов:
- Модель — функции и классы, которые обращаются к базе данных.
- Представление — шаблон, с помощью которого на страницы выводится то содержимое, которое мы хотим увидеть, когда обращаемся к базам данных.
- Контроллер — сама страница сайта с компонентами.
Поработаем с демосайтом 1С-Битрикс. Перейдите по ссылке bitrixlabs.ru, нажмите «Создать демосайт», укажите «Интернет-магазин» и установите. После окончания установки увидите вот такую страницу. Это ваш первый интернет-магазин на 1С-Битрикс.
Здесь редактируется любой элемент. Например, наведите курсор на логотип и нажмите на «Изменить область».
В открывшемся окне замените логотип. Таким образом можно отредактировать все элементы на странице.
Система устроена так, что редактировать сайт может администратор или сам владелец бизнеса.
Цель разработчика на 1С-Битрикс — настроить работу сайта так, чтобы администратору сайта или владельцу бизнеса было легко вносить небольшие изменения: редактировать цены и описания товаров, размещать контент, управлять внешним видом и так далее.
Познакомимся с системой изнутри. На панели сверху выберите раздел «Администрирование».
Здесь располагаются виджеты для быстрого доступа к основной информации: скорости сайта, количеству продаж и так далее.
Этот раздел состоит из нескольких десятков элементов. Рассмотрим наиболее важные.
Здесь показана структура файлов, где можно редактировать их содержимое и так далее.
Здесь расположены товары и категории.
Чтобы перейти в конкретный товар, выберите категорию и нажмите на название. У товаров есть различные свойства, они уже прописаны в системе.
Переключаясь между вкладками, как на скриншоте снизу, можно менять описания, фото, цены, анонсы, прописывать метатеги и ключевые слова, добавлять или убирать товар из разделов сайта, отслеживать эффективность рекламы.
В демоверсии интернет-магазина на 1С-Битрикс в «Маркетинг» загружены все основные модули для решения маркетинговых задач: пульс конверсии,
А/В-тестирование, email-маркетинг и так далее.
Чтобы поставить подобный набор, к примеру, на WordPress, нужно найти хорошее решение, протестировать его, настроить под свой сайт. В Битриксе эти решения уже готовы — это удобно и для разработчиков, и для владельцев бизнеса.
Этот раздел доступен только для интернет-магазинов. Здесь есть вся информация по заказам, оплатам, поставкам, налогам и многое другое. А ещё — уже настроенная онлайн-касса.
Опросы, рассылки, соцсети, техподдержка, блоги — всё, что только можно, интегрируется с сайтом. Каждый пункт меню имеет свои настройки.
Тут легко посмотреть и проанализировать данные о посещаемости сайта и эффективности рекламных кампаний. На практике аналитикой в 1С-Битрикс практически не пользуются, потому что Google Analytics имеет больше возможностей.
Здесь находится каталог решений для 1С-Битрикс: различные модули, инструменты, готовые интернет-магазины. Разработчик может создать какое-либо решение для Битрикса и выставить его на продажу через маркетплейс.
Здесь представлен полный список настроек сайта: валюты, серверы, масштабирование, производительность, поиск по сайту и многое другое.
В категории настроек «Пользователи» настраиваются уровни доступа для разработчиков, контент-менеджеров и других специалистов, работающих над сайтом.
Благодаря встроенным решениям работу с Битриксом легко освоить. Рассмотрим несколько простых действий с системой.
Перейдите во вкладку «Сайт → Создать страницу».
Введите заголовок страницы и отметьте нужные пункты:
- Перейти к редактированию страницы — откроется окно редактора.
- Добавить пункт меню — новая страница появится в меню.
- Ограничить доступ к странице — страница будет создана, но не опубликована.
В следующем окне добавляются описание страницы и ключевые слова, Title и файлы robots — эти данные влияют на поисковую оптимизацию сайта.
Далее откроется окно редактирования страницы. Здесь размещают контент — текст, видео, фотографии, а также встроенные решения, сервисы и инструменты.
Чтобы открыть встроенные компоненты и сниппеты Битрикса, нажмите на указатель сбоку. Когда панель сниппетов скрыта, указатель находится там, куда направлена стрелка на скриншоте.
Разработчик будет работать с кодом PHP. Чтобы перейти в код, нажмите на иконку слева и выберите соответствующий вид редактора, как показано на скриншоте.
Мы разобрали базовые навыки работы с 1С‑Битрикс. Теперь рассмотрим, какие ошибки чаще всего допускают новички и почему.
- Переоценивать книги. Книга не даст обратной связи, не ответит на вопросы, не решит проблему.
- Думать, что одно решение подходит под разные задачи. Не все решения Битрикса стоит принимать как верные, всегда нужно учитывать нюансы конкретного интернет-магазина. В документации указано не всё, понимание этих нюансов приходит только с опытом.
- Терять время на неэффективное обучение. Чтобы стать хорошим разработчиком без посторонней помощи, потребуется 6–7 лет и очень много удачи.
Учись бесплатно:
вебинары по программированию, маркетингу и дизайну.
Участвовать
Мобильное приложение представляет собой просто браузер, который умеет открывать один сайт. По сути это мобильная версия сайта. Битриск позволяет создавать мобильные приложения, не вникая в нативные языки программирования, но есть ограничения
- Не все редакции битрикс это позволяют сделать
- Очень скудный функционал
- Документация очень сырая, мало примеров. Многие даже не описаны
- Проблемы с тестированием приложения
Но есть отдельные преимущества мобильного приложения.
- Не нужно открывать отдельно браузер и вводить урл ресурса, удобно кликнуть по иконке и перейти сразу к сайту
- Приложение имеет доступ ко всей информации устройства, а именно к фото, видео, файловой структуре, акселерометру, гео, марке и модели устройства, контактам и прочее. А главное посылать пуш уведомления. Все это делается с разрешения пользователя
Разработка мобильного приложения включает
- Создание полноценного обычного шаблона, как для обычной версии битрикс, со всеми компонентами, файлами стилей и скриптов
- Создание отдельной директории в корне сайта, где буду находиться все разделы и статичные страницы приложения
- Отправляем на компиляцию приложение в компанию битрикс, предоставляя иконки заставки и прочее
- Публикуем скомпилированное приложение в магазина google play и app store. Учетные записи разработчиков стоят денег.
Приступаем к разработке мобильного приложения на Битрикс.
Шаг первый
Нужно убедиться что установлен модуль мобильная платформа на вашем сайте. Это можно посмотреть в настройках установленных модулей. Настройки –> Модули
Шаг второй
Создаем заготовку для мобильно приложения
Сервисы –> Мобильное приложение –> Конструктор мобильных приложений –> Создать приложение
Заполняем поля:
- Название приложения
- Код приложения в нижнем регистре
- Папка приложения без слэшей в нижнем регистре (в корне сайта будет раздел с вашим приложением)
- Устанавливаем вариант обычного приложения
- Добавить шаблон и настройки офлайн приложения (галку пока не ставим)
- Шаблон приложения. Создаем новый шаблон и пишем его название (оставим по умолчанию NewMobileTemplate)
Шаг третий
Собираем основную заготовку нашего приложения в открывшемся конструкторе мобильного приложения битрикс, его основной каркас. Тут все просто и понятно. Заполняйте поля сами.
Указанная во втором шаге папка приложения уже появилась в корне сайта с некоторыми файлами внутри. Также присутствует индексный файл с подключением хидера и футера. Остальные файлы разберем по ходу пьесы.
Папка шаблона также создалась автоматически, но в директории bitrix->templates. Если вы работаете в папке local, необходимо её перенести туда. В папке шаблона стандартный набор файлов создаваемы для шаблона, с которыми мы в дальнейшем будем работать.
В плане работы шаблон мобильного приложения ничем не отличается от работы основного шаблона сайта.
Смотреть как выглядет приложение на десктопе можно по пути https://site.ru/appmobile/ включив отзывчивый дизайн в браузере. Директорию appmobile мы задали на втором шаге. Но верхняя панель навигации отображаться не будет.
Смотреть как выглядет приложение мы будем установив специальное приложение для вашего смартфона из магазина приложений. Приложение называется 1с-битрикс: разработка При запуске необходимо добавить приложение введя адрес https://site.ru/appmobile/
Все! Базовые настройки выполнены.
Дабы не было не понимания, скажу сразу, данный пост я писал для людей, которые только начинают знакомиться с CMS 1С-Битрикс. Можно сказать это краткий ликбез по принципу работы данной системы. Я опишу из каких компонентов она состоит, что за что отвечает и как формируется web страница. Рекомендую прочесть данный пост перед изучением официальной документации
- курс разработчика http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&INDEX=Y
- документация по API http://dev.1c-bitrix.ru/user_help/index.php
или как вариант после, для повторения основных моментов.
Начну с небольшого пролога, система 1С-Битрикс разработана на основе Bitrix Framework. Которая в свою очередь, вроде как основывается на Zend Framework, в официальной документации об этом сказано в скользь. Данный фреймворк построен по принципу Model-View-Controller, написан на PHP и использует в качестве СУБД следующие продукты: MySQL, Oracle, MS SQL.
CMS 1С-Битрикс платная, но есть бесплатная 30-дневная пробная версия, которую можно скачать на официальном сайте (в гугле не сложно найти).
Логически 1С-Битрикс можно разбить не следующие элементы:
- Модули
- Компоненты
- Шаблон
Сравнивая 1С-Битрикс с шаблоном проектирования Model-View-Controller, можно сказать что:
- Модуль в 1С-Битрикс это модель в MVC.
- Компонент в 1С-Битрикс это контроллер и представление в MVC (компонент с помощью API одного или нескольких модулей манипулирует данными, а шаблон компонента (представление) выводит данные на страницу).
- Шаблон в 1С-Битрикс это чистое представление в понятии MVC (от него зависит не содержимое сайта а его оформление).
P.S. Это деление условно, т.к. я считаю, что фреймворк Bitrix придерживается технологии MVC не достаточно строго.
Начнем с модулей…
Модули располагаются в /bitrix/modules/, задача каждого из них – предоставить API для выполнения той или иной функцию для CMS в целом, например: дать возможность хранить и выводить информациювроде статей, новостей, фотогалерей (модуль «информационные блоки»); организовать интернет-магазин(модуль «Интернет-магазин»); гибко управлять ценами на товар и связывать интернет-магазин с 1С:Предприятие и другими сервисами вроде Яндекс.Маркет (модуль «Торговый каталог»); датьвозможность организовать блог (модуль «Блоги»), форум (модуль «Форумы») и т.п. Предоставляемые модулями функции могут использовать как другие модули так и компоненты.
Помимо модулей, задача которых в расширение возможностей, существуют модули обеспечивающие работу самой CMS, например : модуль с именем «Главный модуль» – отвечает за общее функционирование системы и взаимодействие всех модулей; модуль «Управление структурой сайта» – предоставляет панель администратора и т.д..
Вообщем, если обобщить выше сказанное, возможности CMS 1С-Битрикс зависят от состава модулей. Состав может быть минимальным, имея только необходимые модули и немного функциональных, а может быть распухшим с набитыми кучей модулей на все случаи жизни. Поэтому в зависимости от поставленных задач CMS 1С-Битрикс продается в разных исполнениях – называемыми редакциями, перечислю их:
- Первый сайт (5 модулей)
- Старт (11 модулей)
- Стандарт (19 модулей)
- Малый бизнес (25 модуля)
- Эксперт (33 модуля)
- Бизнес (40 модулей)
- Веб-кластер (40 модулей)
- Бизнес веб-кластер (43 модулей)
Касаться технических сторон создания своих модулей я не буду, думаю web-разработчикам, которые только знакомятся с 1С-Битрикс знать о таких подробностях пока излишне. Вы всегда можете найти всю необходимую информацию в официальной документации (ссылки указанны в начале поста).
О компонентах…
Про компоненты я расскажу более подробно, править их вы будете намного чаще, чем модули. Хочу внести ясность и однозначность в понимание понятие «компонента» в данной системе. Если вы работали на других CMS, то может возникнуть путаница, традиционно модулями в CMS называют некиефункциональные расширения, которые можно устанавливать/удалить, скачивать и разрабатывать самому. Например, это может быть модуль вывода формы на e-mail подписку или модуль выводящий список популярных постов. В CMS 1С-Битрикс эту роль играют – компоненты. Список доступных компонентов вы можете увидеть в данной директории wwwbitrixcomponents. Где директория bitrix это пространство имен для данных компонентов, нам как бы говорят что они «битриксовые», т.е. идут с системой из коробки.
Реализация логики и способа отображения компонента содержится в двух файлах:
- В контроллере
wwwbitrixcomponentsbitrixимя_компонентаcomponent.php
- И в представление (так называемый шаблон компонента) —
wwwbitrixcomponentsbitrixимя_компонентаtemplatesимя_шаблона_компонентаtemplate.php .
Суть работы компонента хорошо описана в официальной документации, повторю их слова еще раз «компонент (т.е. его контроллер замечание от меня), с помощью API одного или нескольких модулей, манипулирует данными, шаблон компонента выводит данные на страницу».
Компонент в своем составе может иметь несколько шаблонов, один из которых будет активным(указывается при вызове компонента).
Помимо контроллера и представления, компонент имеет файлы, выполняющие более второстепенные задачи: файл – содержимого справки, логотип компонента для админпанели, файл-описание компонента для админпанели и т.п.
Типичная структура компонента выглядит так:
- help (директория, файлы справки компонента, т.е. всплывающие подсказки при настройке компонента)
- images (директория, изображения которые использует компонент)
- lang (директория, содержит подпапки с языковыми файлами)
- templates (директория с шаблонами, т.е. с представлениями)
- .description.php (файл с описанием компонента)
- .parameters.php (файл содержит описание входных параметров компонента, файл нужен только для конфигурирование компонента через окошко)
- component.php (файл (контроллер), основная логика компонента)
Зайдя в директорию любого компонента (wwwbitrixcomponentsпространство_именимя_компонента) вы всегда увидите схожую стркутуру, как продемонстрировано выше. Стоит добавить, что компонент все для своей работы хранит в своей папки, поэтому переносить компонент с одного web сайта на другой web сайт – значит просто скопировать папку.
Технически работу компонента можно представить следующим образом: в шаблоне сайта (footer.php или header.php, о них я расскажу позже) вызывается компонент с заданными шаблоном и параметрами:
1 2 3 4 5 6 7 |
<$APPLICATION->IncludeComponent( |
Далее CMS формирует массив с параметрами $arParams, который обрабатывает контроллер «component.php». Контроллер (component.php) согласно своей логике работы и полученного массива параметров формирует результат своей работы, т.е. массив $arResult, который далее использует шаблон компонента (templatesимя_шаблона_компонентаtemplate.php). Представление (или шаблон компонента) отображает результат работы в виде html кода, в задуманном оформление, в том месте где вы вызвали указанный выше код.
Параметры массива arParams=array() можно задать через запяту напрямую в коде (“ключ” => “значение”) или через окошко «параметры компонента». Хочу добавить, что если изменять параметры через окошко«параметры компонента», то они все равно сохраняются в коде, как содержимое массива arParams. Что бы вызвать это окно, первым делом нужно авторизоваться в системе как администратор, далее зайти на сам сайт, выбрать компоненты -> режим правки, далее кликнуть по нужному компоненту два раза.
Как пример, на пальцах. В желтом овале компонент «bitrix:search.form» (перед двоеточием пространство имен в котором данный компонент, после название компонента), по которому я тыкнул два раза. Далее откроется окошко «параметры компонента». Если мы изменим значение параметра (тот что в красном овале) и нажмем сохранить. То в соответствующем файле представления шаблона (footer.php или header.php, о них я расскажу позже), в коде вызова компонента (обозначил зеленой рамкой) измениться значение параметра (в красном кружке). И наоборот, изменения в коде, будут заметны через окошко.
Замечу еще, что шаблоны компонентов могут быть системными и пользовательскими. Системные это те, что уже идут в стандартной поставки и распологаются в дриектории «wwwbitrixcomponentsbitrixимя_компонентаtemplates». Если нам нужен свой шаблон для компонента, то мы должны создать пользовательским шаблон, и поместить его в папку со своим шаблоном сайта, т.е. по следующему адресу «wwwbitrixtemplatesимя_шаблона_сайтаcomponentsbitrixимя_компонентаимя_шаблона_компонента». Дальше, остается подключить наш пользовательский шаблон к компоненту, это можно сделать в визуальном редакторе шаблона (при двойном шелчке по нему) или подправить код его вызова (второй параметр $APPLICATION->IncludeComponent(…)).
Если при вызове или настройке компонента шаблон не указывается, то используется системный шаблон «.default».
В том случае если изменением шаблона компонента вам будем мало, допустим вы хотите выводить какую-то еще информацию в шаблоне, помимо той что может обеспечить логика компонента (component.php). То вы можете добавить в директорию пользовательского шаблона компонента файл – файлresult_modifier.php (в нем мы работаем с $arResult перед кешированием) и файл component_epilog.php (в нем работаем с $arResult после кеширования), таким образом вы дополняете нужную вам функциональность в компонент не изменяя его контроллер (т.е. component.php). Это хорошее правило, ведь все изменения в работе чего либо в CMS должны приходить и уходить вместе с шаблоном сайта, плюс к этому, системный компонент можно спокойно обновлять, до новых версий.
Есть правда и другой способ добавления функциональности, копируем тот компонент, который хотим изменить из wwwbitrixcomponentsbitrix в свое пространство именwwwbitrixcomponentsмое_прост_имен, далее делаем с ним что хотим, добавляем нужный функционал и вызываем его вместо прежнего компонента в шаблоне сайта (footer.php или header.php). Но в этом случае обновляться будет только системный компонент. Этот способ стоит использовать если предыдущий метод (использовать файлы result_modifier.php и component_epilog.php в шаблоне компонента) не помогает достичь нужную вам функциональность.
P.S. В документации написано, что файл result_modifier.php подключается и исполняется, только тогда когда шаблон не кешируется, но у меня, на реальной практики он почему-то исполняется в любом случае.
И наконец шаблоны …
Тут все просто, шаблон в CMS 1C-Битрикс складывается из двух частей, верхней и нижней, все что между ними это информационное наполнение сайта, т.е. контент. Храняться шаблоны в директорииwwwbitrixtemplates, каждая папка это отдельный шаблон. Среди папок вы всегда найдете «.default», это специальный «шаблон», он содержит шаблоны компонентов и файлы, общие для остальных шаблонов сайта. Трогать при интеграции макета мы его вряд ли будем.
Зайдя в директорию любого шаблона вы увидите следующую структуру:
- components (директория, содержит поддиректории с шаблонами компонент)
- images (директория, картинки данного шаблона)
- include_areas (директория, содержит файлы, которые включаются в шаблоне сайта)
- lang (директория, содержит языковые файлы)
- page_templates (директория, содержит файлы-шаблоны, они выводятся с помощью компонента «подключаемые области» (bitrix:main.include), при выводе в браузер данных шаблонов их содержимое наполняется в каждом отдельном разделе или подразделе с помощью файла index_inc.php)
- snippets (директория, содержит сниппеты – маленькие фрагменты html-кода для ускорения работы контент-менеджера по созданию часто встречающихся блоков кода)
- themes (директория, содержит подпаки с темами оформление данного шаблона, под темой понимается своя директория: с шаблонами компонент – components, директория – images с изображениями, файл с названием темы – description.php, изображение-превьюшки данной темы и файл стилей шаблона template_styles.css)
- header.php (файл, отвечающий за вывод верхней части шаблона, т.е. до контента)
- footer.php (файл, отвечающий за вывод нижний части шаблона, т.е. после контента)
- description.php (файл, содержит название и описание шаблона, которое выводиться в админпанели)
- .styles.php (файл, описания стилей для визуального редактора страниц)
- template_styles.css (файл, стили шаблона)
- styles.css (файл, стиль для контента и подключаемы областей, вообщем стиль контента сайта)
Обязательные файлы обеспечивающие минимум шаблона это:
- header.php
- footer.php
- description.php
- template_styles.css
- styles.css
Файл header.php – содержит html код с php вставками <? ?>, в которых вызываются компоненты и подключаются файлы, в footer.php все аналогично. В данных файлах задается верхняя и нижняя часть шаблона.
Стили задаются в template_styles.css и styles.css.
Файл description.php необходим для описания шаблона для админпанели.
После всего сказанного у вас может возникнуть вопрос, если в header храниться верхняя часть шаблона а в footer нижняя а между ними контент, то к чему относить левую и правую боковую панелью(sidebar) ? Разработчики предлагают как вариант такое решение
Оранжевым цветом обозначено то что относиться к header.php, зеленым к footer.php, а голубым к контенту. Вы можете выбрать какой-то свой вариант. Могут быть ситуации, когда одна из боковых панелей зависит от каждой страницы сайта, тогда её логично вынести из дизайна шаблона и считать её контентом.
О разделах, подразделах и наполнение информации…
Итак, мы рассматриваем CMS 1С-Битрикс как взаимодействие модулей, компонентов и шаблона. И с ними мы вроде как разобрались, осталось понять как сайт в системе 1С-Битрикс наполнить информацией. А если быть точнее, то, как наполнить структурированной информацией, т.е. как создать разделы, если нужно подразделы разделов и страницы разделов.
Вообщем, раздел в Битрикс это просто директория, которая располагается в /www. Называть ее можно по любому, т.к. имя раздела в данной CMS не зависит от имени папки. В директории-раздел должны быть как минимум следующие файлы:
- index.php – центральная страница раздела, это php скрипт, отвечающий за наполнение контентом. В данном файле могут вызываеться компоненты, подключаться файлы, а также можно просто хранить статичный текст.
- .section.php – файл содержит описание – имя данного раздела
Помимо этих двух основных, могут быть еще файл:
.положение.menu.php – Файл php, отвечает за то, что показывать компоненту «меню» («menu»), когда мы зайдем в данный раздел сайта. Технически – это файл с массивом $aMenuLinks, в котором каждый элемент содержит название и ссылку. Данный файл считывает компонент «menu» и выводит соответствующие пункты меню. Вместо «положение» вы должны указать какой компонент «menu» (их может быть несколько) будет читать этот файл, это может быть «top», «right», «left» и т.д. Как задается тип компонента? Смотрим код вызова компонента «menu» (в header.php или foter.php) и обращаем внимание на параметр ROOT_MENU_TYPE, его значение и укажет его тип или что он будет читать: .top.menu.php или.left.menu.php и т.д.
Если шаблон компонента «menu» позволяет показывать подкаталоги (выдвижное меню), то мы должны указать какой файл читать для подкаталогов в параметре CHILD_MENU_TYPE.
Если файла «.положение.menu.php» в директории раздела не будет, то движок Битрикс будет искать его вкаталоге сверху, пока не найдет. Меню же нужно знать что выводить.
P.S. Помимо index.php в разделе могут быть другие страницы.
В любом разделе (или директории) могут быть подразделы (директории в данной директории), содержимое их аналогичное. Также хочу сказать, что директория www также имеет свой набор index.php,.section.php и .положение.menu.php, ее можно рассматривать как главный раздел сайта.
Наполнять сайт структурированной информацией (создавать разделы, подразделы, их страницы с информацией) можно как через панель администратора (красный овал)
так и вручную, т.е. сами создаем папки, необходимые файлы в них, редактируем файл “.положение.menu.php” в www (иначе нашего нового раздела не будет в меню).
На этом, данный пост я закончу. Для разработчика, который только знакомиться с CMS 1С-Битрикс данной информации будет достаточно что-бы примерно понять, что эта за система, удобна она или нет, найти сходства с другими CMS или наоборот увидеть явные различия. Это даст первое приближение, более глубокое погружение вы получите уже изучая документацию и работая с данной CMS.
Назад в раздел
Считаем, что принято решение делать сайт на CMS и в качестве CMS был выбран битрикс. Дизайнер отрисовал картинку, верстальщик сделал html+css+js код и дальше начинает работу серверный программист. С чего начать проект? Как лучше организовать код? Об этом я хочу поговорить в данной статье. Здесь я не ставлю задачу объяснить каждую деталь подробно, не ставлю задачу показать прямо конкретные шаги, вроде выполните первое, выполните второе и т.д. Здесь я постараюсь обрисовать общую картину. Я хочу показать как должен быть устроен проект на битриксе с моей точки зрения. Если у вас есть какие то замечания, дополнения или уточнения, то пишите в комментарии. Было бы любопытно сравнить разные подходы к формированию структуры проекта.
Содержимое статьи
- 1 Создание проекта
- 1.1 Контроль версий
- 1.2 Автодополнение
- 1.3 Верстка
- 2 О папке local
- 3 Шаблон сайта
- 3.1 Зависимые области
- 4 Константы
- 4.1 Наименование констант
- 5 Модуль проекта
- 5.1 Автолоад классов
- 5.2 Обработчики
- 5.3 Класс обработчика
- 5.4 Хэлперы и части страниц
- 5.5 Итого по модулю проекта
- 6 Компоненты
- 7 Компонент vs Модуль
- 8 Общий взгляд
Создание проекта
Начну с банальностей. Любой проект начинается с папки, так что создайте папку в любом удобном для вас месте. Эта папка будет корнем сайта, то есть если вы редактируете файл index.php в этой новой папке, то это все равно что вы редактируете файл /index.php на сайте (после синхронизации естественно). Ну это я думаю и так понятно. Если вы пользуетесь IDE, то можете создать новый проект через меню редактора, но суть та же останется — будет создана новая папка.
Контроль версий
Далее, сразу после создания папки, пока папка пуста делайте из этой папки репозиторий для системы контроля версий. Зачем нужен контроль версий и что это такое вы можете прочитать тут. Я пользуюсь гитом (git), так что для старта репозитория просто выполняю git init в нужной папке. Вы можете создать репозиторий любым удобным для вас способом. Например можно поставить «tortoseGit» под винду, это визуальный интерфейс, он добавляет новые пункты в контекстное меню по правой кнопке мыши в папке. Мне он кажется довольно простым и удобным, просто кликая мышкой без консоли можно управлять репозиторием.
После создания репозитория добавьте в корень папки файл .gitignore, где сразу пропишите папку /bitrix/ и все остальные папки которые вы точно не будете трогать. Полную копию битрикса я предпочитаю не хранить локально, однако же иногда бывает полезно выкачать что-то из папки bitrix и посмотреть детально как оно там устроено. И вот эти временные файлы после прописывания папки /bitrix/ в .gitignore точно не попадут в коммит.
В дальнейшем, когда уже начнете писать код, стоит сосредоточиться на какой то одной задаче, выполнить ее и сделать коммит с комментарием о выполненной задаче. Не нужно делать коммит по итогу суток, недели или хуже того стартовый коммит, и коммит с уже завершенным проектом. В этом случае вся суть контроля версий теряется. Да, иногда я и сам забываю сконцентрироваться на задаче, особенно когда их много, но в этом случае стоит добить текущую задачу и сделать общий коммит где расписать каждую из выполненных задач. Например, «сделан глобальный шаблон», «левое меню», «список разделов каталога», «раздел новостей» и т.д.
Есть множество всяких красивых схем ветвления, отдельная ветка под разработку, рабочая ветка, ветки по фичам, тэги версий и т.д. Все это безусловно круто, но если вы не понимаете зачем это все нужно, то просто отправляйте все в одну ветку master последовательно и не заморачивайтесь с ветками вообще. Все эти схемы ветвления предназначены во первых для группы разработчиков, и во вторых для запущенного или близкого к релизу проекта. Если вы понимаете зачем нужны ветки и как ими пользоваться то этот раздел статьи вам не очень то и нужен 🙂
Автодополнение
В битриксе довольно много всякого функционала и соответственно много всяких API функций. Вызов API можно конечно делать и вручную, прямо писать каждый раз название функции, либо открывать документацию и копировать, но гораздо удобнее настроить автодополнение в IDE. Лично я пользуюсь phpstorm от jetbrains, поэтому покажу настройку автодополнения именно тут. Для настройки автодополнения нам понадобится папка /bitrix/modules/ в исходных кодах, то есть ставите где-то битрикс, активируете его, обновляете до последней доступной версии и скачиваете из поставленного битрикса папку /bitrix/modules/. Битрикс не обязательно должен быть активированным, от шифрования кода они уже давно отказались, так что я думаю пойдет /bitrix/modules/ даже от пробной версии, но честно говоря не проверял.
После того как скачаете папку /bitrix/modules/, откройте phpstorm. У вас будет примерно такая картинка перед глазами
Окно нового проекта
Сделайте двойной щелчок мыши слева по строке «External Libraries». Откроется окошко добавления внешней библиотеки. Нажмите в этом окошке плюсик и укажите путь до скачанной папки /bitrix/modules/. После индексации папки, везде во всех файлах будет работать автодополнение по основным функциям. Будет работать переход по ctrl+клик на название функции, можно быстро посмотреть что именно происходит внутри конкретных функций ядра.
Папку /bitrix/modules/ можно использовать одну и ту же для многих проектов. В битриксе изменения происходят довольно часто, но все же прям кардинально они очень редко что меняют. Названия классов и функций, аргументы функций и т.д. как правило остаются без изменений очень долгое время. Так что папку /bitrix/modules/ вполне достаточно обновлять раз в полгода по выходу мажорных версий.
Верстка
Верстальщик как правило присылает результат в виде папки с html файлами и дополнительными подпапками типа /css/, /images/, /fonts/, /js/ и т.д. То есть собственно страницы сайта которые уже можно открывать в браузере и всякие стили и скрипты для этих страниц. Сразу же закиньте все присланное верстальщиком в корень проекта. Если в верстке используется gulp, grunt, sass, postcss и т.д. и вы верстку не планируете трогать, то достаточно закинуть скомпилированный проект, если планируете править верстку с использованием сборщиков проекта, то вы я думаю и так знаете что делать. Итого без сборщика проекта в корне у вас будет лежать папка /project_name или /verstka/ или еще что в которой лежат html файлы + все что в этих файлах используется. Это очень удобно, можно будет сразу присылать заказчику ссылку на верстку и ссылку на интегрированную в битрикс страницу, типа было и стало, ну либо самому сравнивать если вы собственный проект разрабатываете. Кроме того можно будет сразу брать нужные html куски из верстки не закрывая и не переключаясь из IDE. В дальнейшем, по завершении интеграции эту папку естественно стоит удалить.
Прямо сразу после добавления папки с версткой сделайте стартовый коммит в репозиторий. В дальнейшем если верстальщик работает отдельно от вас, делает только верстку и битрикс совсем не знает (то есть в готовом шаблоне битрикса он ничего не сможет поправить) вы просто копируете новые правки от верстальщика с перезаписью файлов в эту же папку с версткой. И сразу будет виден список изменений, которые он сделал. Система контроля версий просто подсветит все правки, которые вы уже распихаете по нужным местам шаблона сайта и шаблонов компонентов.
О папке local
Вообще вся работа будет вестись в папке local. По большей части это «/local/templates», «/local/php_interface/», «/local/modules/» и «/local/components/». Да, иногда требуется править и страницы публичной части, то есть например /index.php, или /about/index.php, но там практически всегда будут только вызовы компонентов, бывают и особо сложные разделы где много чего прямо на публичных страницах приходится делать, но не часто.
Преимущество папки local в том, что вы точно знаете, что любой код который там лежит был написан именно под этот проект. В папке /bitrix/ сильно дофига служебных и просто не нужных файлов, всякие старые или демонстрационные шаблоны, dbconn.php который отвлекает от init.php и т.д.. В общем чтобы найти что-то в папке /bitrix/ придется приложить больше усилий, потратить больше внимания на каждую операцию. В системе контроля версий не нужно писать огромный .gitignore с перечислением всех служебных папок (попробуйте например добавить в контроль версий только /bitrix/php_interface/init.php и проигнорировать dbconn.php из этой же папки), мы просто весь /bitrix/ игнорируем, а весь /local/ храним в репозитории. Проще говоря папка local гораздо удобнее.
То есть для нового проекта обязательно создаем папку /local/. В ней вам гарантированно потребуется папка templates с шаблоном сайта.
Шаблон сайта
Для начала создайте папку с шаблоном /local/templates/template_name/, либо /local/templates/.default/ если она вам больше нравится. Далее смотрите папку с версткой и копируете оттуда вообще все за исключением html кода в папку с шаблоном. То есть из верстки нужно взять все стили, все скрипты, все картинки, все шрифты и т.д. и положить их в папку с шаблоном. Причем все относительные пути надо сохранять. То есть копируем с сохранением структуры. Если верстальщик грамотный, то ни одного абсолютного пути он не напишет, все картинки будут браться из папки «../images/», а не «/images/», то есть из рядом лежащей папки, вне зависимости от того на какой глубине они лежат.
Весь глобальный шаблон сайта на битриксе это по сути два файла header.php и footer.php в папке с шаблоном. Что должно быть в файле header.php на мой взгляд? Вот примерно такое
<?if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die();
/**
* @global CMain $APPLICATION
* @global CUser $USER
*/
$dir = $APPLICATION->GetCurDir();
$page = $APPLICATION->GetCurPage();
$show_left_sidebar = $APPLICATION->GetDirProperty("show_left_sidebar");
$assets = BitrixMainPageAsset::getInstance();
?><!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<?
/**
* CSS
*/
$assets->addCss(SITE_TEMPLATE_PATH . '/css/reset.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/owl.carousel.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/owl.theme.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/owl.transitions.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/animate.min.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/jquery.formstyler.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/fancybox/jquery.fancybox.css');
$assets->addCss(SITE_TEMPLATE_PATH . '/css/main.css');
/**
* JS
*/
//VENDOR
CJSCore::Init(array('jquery'));
$assets->addJs(SITE_TEMPLATE_PATH . '/vendor/owl.carousel.min.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/vendor/jquery.maskedinput.min.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/vendor/jquery.fancybox.pack.js');
//LOCAL
$assets->addJs(SITE_TEMPLATE_PATH . '/js/helpers.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/js/main.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/js/order.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/js/ajax.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/js/catalog.js');
$assets->addJs(SITE_TEMPLATE_PATH . '/js/blog.js');
/**
* BITRIX ->ShowHead()
*/
$APPLICATION->ShowMeta("robots", false);
$APPLICATION->ShowMeta("keywords", false);
$APPLICATION->ShowMeta("description", false);
$APPLICATION->ShowLink("canonical", null);
$APPLICATION->ShowCSS(true);
$APPLICATION->ShowHeadStrings();
$APPLICATION->ShowHeadScripts();
?>
<title><? $APPLICATION->ShowTitle() ?></title>
</head>
Практически на всех сайтах, которые меня просят доработать, в шаблоне я вижу либо старые варианты подключения скриптов и стилей $APPLICATION->AddHeadScript(‘src’), либо же вообще оставшееся от верстки подключение тэгами <link> и <script>. Между тем уже давно в битриксе есть штатное удобное подключение, получаем экземпляр класса BitrixMainPageAsset и дальше функциями addJs() и addCss() подключаем скрипты и стили. Если скрипты и стили подключены в шаблоне сайта, то они объединятся в один файл template_random.css и template_random.js (если это включено в настройках конечно же). Если скрипты и стили тем же классом Asset подключаются в любом другом месте, то они будут добавлены в отдельный файл page_random.css и page_random.js. То есть общие для всех страниц файлы кешируются отдельно от скриптов и стилей нужных для конкретной страницы.
По правильному нужно разбить стили, чтобы каждая конкретная страница в целом загружалась быстрее, однако я считаю, что можно и вообще все скрипты и стили, не важно используются они на этой странице или нет, подключать в шаблоне и не разделять на страничные и шаблонные. Бывают исключения конечно, если на какой то странице много скриптов, которые используются исключительно на этой странице, то такие скрипты или стили стоит все же отделить. Однако для большинства сайтов достаточно подключить все в общем шаблоне, эти лишние несколько килобайт или даже десятков килобайт погоды не сделают, страница будет грузится быстрее всего на несколько миллисекунд.
Пользоваться файлами style.css и script.js в папке с шаблоном компонента вообще не стоит. Да в целом это может быть удобно когда подключаешь компонент на странице, и автоматом подтягиваются все его стили, ни о чем больше думать не нужно. Однако для правок лазить по папкам всех шаблонов и искать эти кусочные стили дикий геморрой. Поэтому все стили для сайта должны лежать в папке с шаблоном, в подпапке /css/ например. Точно так же и со скриптами, все скрипты должны быть в папке /js/ шаблона. Название у папки может быть любое, главное чтобы не в корне сайта и не в папках с шаблонами компонентов.
Скрипты стоит подключать именно в файле header.php и именно функцией addJs(), даже если в верстке скрипты по модному вынесены в конец страницы. В битриксе, в настройках есть галочка которая переносит все скрипты в конец страницы, вне зависимости от того где они были подключены. Поэтому как то специально извращаться со скриптами не нужно. Гораздо удобнее помнить что вообще все внешние файлы, и css и js подключаются в файле header.php в тэге head.
Сторонние плагины и библиотеки желательно подключать отдельно, чтобы сразу было видно где скрипты написанные специально для этого сайта, а где скрипты которые не нужно трогать. Идеально если верстальщик все внешние скрипты и стили положил в отдельную папку /vendor/. В вышеприведенном коде все внешние скрипты подключены в отдельном блоке с комментарием //VENDOR, к сожалению в этом проекте верстальщик кинул все стили плагинов в общую папку стилей, поэтому css подключены общей кучей.
Еще момент по функции ShowHead(). В последнее время все стали верстать в манере html5, и соответственно мета тэг кодировки отличается от битриксовского. Чтобы полностью соответствовать верстке я заменил функцию ShowHead() на то что она собственно содержит. Только убрал в этой функции вывод одного мета тэга. В принципе можно и полный meta charset вызывать, такой же как в функции $APPLICATION->ShowHead(), и тогда можно собственно саму эту функцию и вызывать.
Зависимые области
Если на каких то страницах есть боковая панель слева или справа от основного контента, а на каких то страницах этой панели нет, то на мой взгляд панель надо включать в основной шаблон сайта. Не нужно писать html код панели прямо на самой странице. Например, если боковая панель должна быть в разделе «О компании», папка /about/, то не нужно писать html код в файле /about/index.php, в этом файле должно быть только основное содержимое страницы. Это касается не только боковых панелей, но и вообще любых областей сайта которые отображаются и пропадают в зависимости от раздела. Все такие области условно можно назвать зависимыми областями.
Как именно отображать зависимые области? Если речь идет только о главной странице, то достаточно просто хардкодом прописать в глобальном шаблоне условие $APPLICATION->GetCurDir() == ‘/’. Если область должна как то более гибко отображаться, то можно использовать свойство раздела битрикса. Свойство страницы в данном случае не подходят, так как на момент выполнения файла header.php свойство страницы еще не определено, а вот свойство раздела уже есть. Достаточно в настройках модуля управления структурой прописать отдельное свойство под каждую область и в дальнейшем просто включать и отключать область в нужных местах. Если область по умолчанию должна отображаться везде кроме главной страницы, плюс отключена на нескольких выбранных страницах, то определяем свойство раздела show_area_name = Y в корне сайта, и во всех подразделах область будет отображаться, чтобы значение по умолчанию не влияло на главную страницу прописываем в глобальном шаблоне проверку и на свойство и на папку одновременно.
В качестве примера можете посмотреть код шаблона выше, там еще до объявления DOCTYPE у меня собрано свойство show_left_sidebar и текущая директория. Использовать эти собранные переменные можно так:
<?if($show_left_sidebar == 'Y' && $dir != '/'):?>
<div class="row">
<div class="col-md-4 col-sm-6">
<?
$APPLICATION->ShowViewContent('leftSidebar');
?>
</div>
<div class="col-md-8 col-sm-6" id="article">
<?endif;?>
Вместо вызова ShowViewContent() можно поставить какую нибудь включаемую область или сразу вызывать нужные компоненты.
Константы
Вы практически наверняка будете использовать инфоблоки. Большая часть задач в битриксе решается на инфоблоках и каталог товаров, и новости, и какие сообщения об акциях и т.д. В компонентах одним из параметров передается инфоблок. Многие инфоблоки используются на разных страницах, или даже на одной странице в нескольких местах. Если вы вдруг по каким то причинам решите использовать другой инфоблок, то придется во всех местах где этот инфоблок используется исправлять параметры компонента. Но можно при старте проекта объявить константы по всем инфоблокам, плюс любые другие значимые данные, которые могут использоваться на разных страницах. И дальше во всех местах где используется ID инфоблока новостей, заменить его на константу с ID этого инфоблока.
Создайте файл /local/php_interface/init.php. Создайте файл /local/php_interface/include/constants.php. В файле /local/php_interface/init.php подключите файл /local/php_interface/include/constants.php через require или include. Таким образом файл констант у нас будет выполняться вообще всегда, при каждом открытии страницы. Что должно быть в файле с константами? Собственно сами константы. Объявляем константы так:
<?php
/**
* IBLOCK IDs
*/
define("IBLOCK_ID__CATALOG", 4);
define("IBLOCK_ID__OFFERS", 11);
define("IBLOCK_ID__VIDEO", 9);
...
остальные используемые инфоблоки
...
/**
* PATHS
*/
define('PATH_TO_BASKET', '/personal/order/make/');
define('PATH_TO_ORDER', '/personal/order/make/');
И дальше подставляем константы например в вызов компонента:
<?$APPLICATION->IncludeComponent(
"bitrix:catalog",
"catalog",
array(
"IBLOCK_TYPE" => "catalog",
"IBLOCK_ID" => IBLOCK_ID__CATALOG,
[...]
),
false
);?>
И теперь если вы например захотите протестировать импорт из 1с в другой каталог, то достаточно будет сделать импорт, и поменять значение в константе. Вообще весь сайт будет брать товары из другого инфоблока и сразу можно будет посмотреть результат.
В том случае когда над проектом работают несколько программистов на разных серверах, либо даже если только один программист собирается перенести функционал с тестового сервера на боевой могут возникнуть проблемы, так как ID инфоблоков могут различаться. Например инфоблоки были созданы в разном порядке, или достаточно всего один раз удалить инфоблок на одном из сайтов, чтобы все последующие инфоблоки даже созданные в верном порядке были под разными ID. При простом копировании вызова компонента будут вызываться разные инфоблоки, то есть например на тестовом выводятся новости из компонента с ID=3, а на боевом инфоблок новостей имеет ID=2. И соответственно при копировании вызова компонента будут не новости отображаться, а какая нибудь фотогалерея.
Чтобы решить проблему с разными ID инфоблоков на разных сайтах константы тоже пригодятся. Достаточно при старте страницы получить инфоблок по его символьному коду и засунуть в константу. Специально для этой цели я написал класс — Класс для получения инфоблока по коду. Здесь я полный листинг файла приводить не буду, там ничего особенного. Вкратце, что там происходит вообще. Если вы пользуетесь моим классом, то объявляем константу вот так
define('IBLOCK_ID__CATALOG', IBlockData::getByCode('CATALOG'));
Далее функция проверяет статическую переменную класса $byCode, если эта переменная пуста, то получает полный список инфоблоков, и записывает в эту переменную массив ID инфоблоков, где ключами массива являются коды инфоблоков. Далее функция смотрит элемент массива с ключом переданным в качестве аргумента функции. Если элемент найден по ключу, то возвращает его значение. Итого функция по коду инфоблока возвращает его ID. Полная выборка инфоблоков кешируется стандартным битриксовским кешем на сутки, то есть запрос к БД будет только при первом обращении, а весь следующий день значение будет браться из кеша. В кеш ложатся только пара символьный код — ID, поэтому функция достаточно легкая. Инфоблоки берутся с привязкой к сайту, то есть класс применим при работе с многосайтовостью, по коду вернется ID инфоблока на конкретном сайте.
Наименование констант
Выше я привел довольно простой файл констант, в котором только несколько инфоблоков и пара путей. Однако же бывают проекты в котором констант на пару экранов. И если называть константы не задумываясь, то будет хаос. Лично я стараюсь обозначать константы по виду. Например если в константе хранится ID инфоблока, то делаю префикс IBLOCK_ID, если там путь, то префикс PATH. В общем тут строгих правил никаких нет, но все же стоит как-то хотя бы минимально обозначать в названии константы ее значение. Константа «TEST_BLOCK» какая-нибудь вообще непонятно что содержит, особенно если там просто цифра записана.
Модуль проекта
Со временем у любого программиста накапливается довольно много готового кода под разные ситуации, который заметно облегчает работу. Кроме того во многих проектах есть сложный функционал, который нужно где-то хранить. Я встречал подключение классов в init.php (как довольно грамотно сделанное с автолоадом, так и простые инклуды), всякие вычисления в result_modifier.php, сам я раньше создавал под проект свой специфический модуль. Однако же сейчас я остановился на создании универсального локального модуля, который уже содержит все наработки и готов к написанию специфичного функционала. На всех проектах я использую модуль «local.lib». Название через точку чтобы он отобразился в списке модулей marketplace. Что именно можно и нужно делать в модуле?
Автолоад классов
На текущий момент битрикс поддерживает автоматический автолоад классов. Тавтология небольшая, но тем не менее. Автолоад классов — подключение класса по требованию. Автоматический автолоад — не нужно прописывать классы в автолоад заранее, путь до файла автоматически определяется при вызове. Что это означает на практике? В папке с модулем создаете папку /lib/, в папке /lib/ создаете файл testecho.php, название обязательно в нижнем регистре. В файле пишете:
<?php
namespace LocalLib;
class TestEcho
{
public function test()
{
echo 'test';
}
public static function testTwo()
{
echo 'test two';
}
}
Теперь в любом месте проекта, на любой странице, в любом компоненте и т.д. можете этот свой класс использовать:
<?php
if(BitrixMainLoader::includeModule('local.lib')) {
LocalLibTestEcho::testTwo();
$test = new LocalLibTestEcho();
$test->test();
}
И в месте вызова будет отображаться строка «test», либо «test two» из класса.
Теперь после примера можно чуть подробнее остановиться на том, как работает автолоад классов. Обратите внимание на первую строку в файле с классом «namespace LocalLib;» именно на основе пространств имен все и работает. Модуль у нас называется local.lib, это означает что все классы модуля должны быть в пространстве имен LocalLib. Если бы модуль назывался test.module, то мы бы во всех классах прописывали пространство имен TestModule. При публикации на marketplace битрикса первое слово до наклонной черты — это id партнера, второе слово это название модуля (просто на всякий случай).
Можно использовать подпространства имен. Например LocalLibHelpers. Создаете папку /lib/helpers/ и в ней файл increment.php
<?php
namespace LocalLibHelpers;
class Increment
{
public static function get($number)
{
return $number++;
}
}
Обратите на пространство имен, я туда добавил Helpers. И точно так же как и в предыдущем примере используем класс в любом месте
<?php
if(BitrixMainLoader::includeModule('local.lib')) {
echo LocalLibHelpersIncrement::get(1);
}
После выполнения кода в месте вызова отобразится циферка «2».
Подробнее для тех кто не понял в чем суть. В модуле битрикса можно создать сколько угодно классов, классы можно красиво разложить по папкам. Класс вообще никак не влияет на производительность, до тех пор, пока к нему не обратились. То есть только в момент обращения к классу срабатывает автолоад, по вызванному имени класса битрикс пытается найти файл, и подключает конкретно этот файл. Например имя класса LocalLibHelpersIncrement означает что битрикс будет смотреть в папку модулей, будет искать в этой папке подпапку local.lib, далее внутри папки local.lib он будет искать lib/helpers/ и внутри этой папки уже будет искать файл increment.php. Если такой файл найден, то он подключается инклудом и вызывается класс из этого файла.
Если даже модуль подключен, но на этой конкретной странице ни один из его классов не был использован, то фактически можно сказать что эта конкретная страница отработала как будто модуль совсем не установлен в системе. Влияние на производительность минимальное.
Обработчики
Практически во всех битрикс проектах, за редким исключением файл init.php это свалка. Какие то функции, нагромождение классов, тысячи строк кода который непонятно вообще используется или лежит в качестве наследия. Тьма каких то обработчиков, инклудов. В общем смотрится это все довольно ужасно. Чтобы такого хаоса не было стоит хранить и использовать обработчики грамотно. В большинстве моих проектов файл init.php состоит всего из пяти строк
<?php
if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true) die();
if (file_exists($_SERVER["DOCUMENT_ROOT"]."/local/php_interface/include/constants.php"))
require_once($_SERVER["DOCUMENT_ROOT"]."/local/php_interface/include/constants.php");
if (file_exists($_SERVER["DOCUMENT_ROOT"]."/local/php_interface/include/handlers.php"))
require_once($_SERVER["DOCUMENT_ROOT"]."/local/php_interface/include/handlers.php");
То есть всего две операции — подключение вышеупомянутого файла констант, и подключение файла обработчиков. Примерный листинг файла констант я уже приводил, а вот листинг файла обработчиков
<?php
use BitrixMainLoader;
$eventManager = BitrixMainEventManager::getInstance();
//page start
AddEventHandler("main", "OnPageStart", "loadLocalLib", 1);
function loadLocalLib()
{
Loader::includeModule('local.lib');
}
//BASKET
//basket add
AddEventHandler("sale", "OnBeforeBasketAdd", array('LocalLibHandlersBasket', 'beforeAdd'));
AddEventHandler("sale", "OnBasketAdd", array('LocalLibHandlersBasket', 'afterAdd'));
//basket update
AddEventHandler("sale", "OnBeforeBasketUpdate", array('LocalLibHandlersBasket', 'beforeUpdate'));
AddEventHandler("sale", "OnBasketUpdate", array('LocalLibHandlersBasket', 'afterUpdate'));
// basket delete
AddEventHandler("sale", "OnBeforeBasketDelete", array('LocalLibHandlersBasket', 'beforeDelete'));
AddEventHandler("sale", "OnBasketDelete", array('LocalLibHandlersBasket', 'afterDelete'));
//order
AddEventHandler("sale", "OnOrderAdd", array('LocalLibHandlersOrder', 'afterAdd'));
AddEventHandler("sale", "OnOrderUpdate", array('LocalLibHandlersOrder', 'afterUpdate'));
//property types
AddEventHandler("main", "OnUserTypeBuildList", array('LocalLibPropertiesComplect', 'GetUserTypeDescription'));
AddEventHandler("iblock", "OnIBlockPropertyBuildList", array('LocalLibPropertiesComplect', 'GetUserTypeDescription'));
//user
AddEventHandler("main", "OnBeforeUserRegister", array('LocalLibHandlersUser', 'beforeUpdate'));
AddEventHandler("main", "OnBeforeUserUpdate", array('LocalLibHandlersUser', 'beforeUpdate'));
//highload blocks
$eventManager->addEventHandler('', 'UserDataOnUpdate', array('LocalLibHandlersUserData', 'afterUpdate'));
$eventManager->addEventHandler('', 'UserDataOnAdd', array('LocalLibHandlersUserData', 'afterAdd'));
Никакого кода здесь нет и не должно быть. Единственное исключение, это функция подключения локального модуля. Чтобы не надо было везде его прописывать, просто сразу пользуемся функциями модуля. Если модуль гарантированно подключен при старте страницы, то писать BitrixMainLoader::includeModule(‘local.lib’) как в предыдущем примере уже не нужно, сразу вызываем классы модуля и все.
Как вы уже наверное поняли на основе предыдущего блока про автолоад — все обработчики лежат в локальном модуле. Вызов array(‘LocalLibHandlersBasket’, ‘afterDelete’) по событию OnBasketDelete означает, что при необходимости битрикс автоматически подключит файл /local/modules/local.lib/lib/handlers/basket.php, и вызовет статическую функцию afterDelete, класса Basket.
Битрикс позволяет регистрировать обработчики при установке модуля. То есть в файле /install/index.php просто один раз регистрируем обработчик и он начинает работать. При этом в файле handlers.php будет пусто. Для модулей в маркетплейс это безусловно очень удобно, и по сути единственный возможный для них вариант работы. Однако я считаю, что для модуля проекта такого делать не стоит. Во первых, обработчики часто добавляются и удаляются, а каждый раз удалять и устанавливать обратно модуль это вообще не круто, как и постоянно лезть в консоль php. Во вторых, зарегистрированные при установке модуля обработчики фиг найдешь. Про них нужно заранее знать, в то время как обработчики из init.php все программисты лезут проверять в первую очередь. Понять что и где делается гораздо проще.
Класс обработчика
Подробнее о том что должно быть в файле /local/modules/local.lib/lib/handlers/basket.php, и о том как должен строиться класс LocalLibHandlersBasket. В битриксе названия событий достаточно запутанные. Всякие before, onBefore и т.д. Впринципе вызываемую функцию можно назвать просто по названию события. Если событие называется OnBeforeBasketDelete, то в классе Basket так и пишем
<?php
namespace LocalLibHandlers;
use BitrixMainLocalizationLoc;
use BitrixMainLoader;
Loc::loadMessages(__FILE__);
class Basket
{
public static function OnBeforeBasketDelete($ID)
{
//do something
}
}
однако логичнее как мне кажется называть функции по шаблону «когдаДействие», например «beforeDelete», «afterDelete», «beforeAdd», «afterChange» и т.д. Класс обработчика предназначен для работы с конкретным объектом (условным), например класс для событий корзины, класс для событий элемента инфоблока, класс для работы с событиями заказа и т.д. Смысла дублировать название класса в названии функции на мой взгляд нет. В этом примере мы работаем с событиями корзины, и соответственно функция которая будет вызываться перед удалением товара из корзины должна называться beforeDelete.
<?php
namespace LocalLibHandlers;
use BitrixMainLocalizationLoc;
use BitrixMainLoader;
Loc::loadMessages(__FILE__);
class Basket
{
public static function beforeDelete($ID)
{
//do something
}
}
Все функции событий должны быть статическими. Битрикс не создает объект класса, он просто вызывает одну конкретную функцию. Но использовать класс просто как хранилище функций довольно глупо. Поэтому этот класс мы сделаем паттерном singleton и во всех функциях событий будем получать объект класса. То есть код будет выглядеть вот так:
<?php
namespace LocalLibHandlers;
use BitrixMainLocalizationLoc;
use BitrixMainLoader;
Loc::loadMessages(__FILE__);
class Basket
{
/**
* @var array
*/
protected $arFields;
/**
* @var array
*/
protected $errors = array();
/**
* @var self
*/
private static $instance;
private function __construct()
{
}
private function __clone()
{
}
private function __wakeup()
{
}
public static function getInstance()
{
if (empty(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
public static function beforeDelete($basketItemId)
{
$handler = self::getInstance();
$handler->doSomething();
$handler->doSomethingElse();
return $basketItemId;
}
protected function doSomething()
{
//do something
}
protected function doSomethingElse()
{
//do something else
}
}
Кроме того обратите внимание на функции doSomething() и doSomethingElse(), по факту обработчик события вызвался всего один раз, однако в обработчике мы выполнили два логически разделенных действия. В файле handlers.php всего один обработчик на событие OnBeforeBasketDelete, но внутри функции beforeDelete мы вызываем несколько логически не связанных функций. Это тоже значительно увеличивает читабельность файла handlers.php с обработчиками. Внутри функций класса мы уже можем использовать объект $this, как в нормальном полноценном классе, вызывать другие функции класса, использовать переменные класса, получить какие то общие данные (типа состояние элемента до изменения) и использовать их в нескольких разных функциях и т.д. То есть писать какой то уже более менее сложный код.
Следующий пример использования класса чуть посложнее. Если в функции по событию OnBeforeIBlockElementUpdate вернуть false и в $APPLICATION бросить ошибку, то элемент не сохранится. Если в этой же функции изменить какое либо поле, то сохранится уже измененное значение. Допустим мы хотим вообще всем элементам в инфоблоке каталог, в названии добавлять префикс test при сохранении. Кроме того представим, что в инфоблоке каталог у нас есть свойство типа список, с одним значением (галочка да/нет) и кодом READ_ONLY. Если галочка в свойстве READ_ONLY стоит, то элемент не должен сохраниться. Вот так это можно реализовать в классе обработчика:
<?php
namespace LocalLibHandlers;
use BitrixMainLocalizationLoc;
use BitrixMainLoader;
Loc::loadMessages(__FILE__);
class Catalog
{
/**
* @var array
*/
protected $arFields;
/**
* @var array
*/
protected $arElement;
/**
* @var array
*/
protected $errors = array();
/**
* @var self
*/
private static $instance;
private function __construct()
{
}
private function __clone()
{
}
private function __wakeup()
{
}
public static function getInstance()
{
if (empty(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
/**
* Выполняется по событиям
* OnBeforeIBlockElementUpdate
*
* @param $arFields
*
* @return array|bool
*/
public static function beforeChange(&$arFields)
{
if ($arFields['IBLOCK_ID'] == IBLOCK_ID__CATALOG) {
$handler = self::getInstance();
$handler->setFields($arFields);
$handler->getElement();
$handler->setName();
$handler->checkReadOnly();
if (!empty($handler->errors)) {
$errors = implode("rn", $handler->errors);
global $APPLICATION;
$APPLICATION->throwException($errors);
return false;
} else {
$arFields = $handler->arFields;
}
}
return $arFields;
}
protected function setName()
{
$this->arFields['NAME'] = 'Test '.$this->arFields['NAME'];
}
protected function checkReadOnly()
{
if(!empty($this->arElement['PROPERTY_READ_ONLY_VALUE'])){
$this->errors[] = 'Снимите галочку "Только для чтения", чтобы сохранить элемент';
}
}
protected function setFields($arFields)
{
$this->errors = array();
$this->arFields = $arFields;
}
protected function getElement()
{
if (is_array($this->arFields)) {
$this->arElement = CIBlockElement::GetList(
array(),
array(
'ID' => $this->arFields['ID'],
'IBLOCK_ID' => $this->arFields['IBLOCK_ID'],
),
false,
false,
array(
'ID',
'IBLOCK_ID',
'PROPERTY_READ_ONLY',
)
)
->Fetch();
}
}
}
Вместо функции setName можно поставить любые преобразования данных.
То есть в переменной класса $errors у нас сохраняются ошибки. Если в любой функции класса объявить ошибку вот так «$this->errors[] = ‘text’;», то при сохранении в админке пользователю отобразится ошибка. Мы можем вызывать сколько угодно функций, вместо свойства READ_ONLY проверить любые другие зависимые данные, может быть даже из нескольких источников и в случае необходимости объявить ошибку с отменой сохранения элемента.
Это два простеньких примера использования класса обработчика. На самом деле возможности тут гораздо шире. Еще например перед удалением элемента можно получить все его поля в переменную класса (напомню, класс singleton, статический класс), а потом уже после удаления просто проверить эту же переменную класса и совершить какие нибудь действия после гарантированного удаления элемента, но с использованием уже удаленных по сути данных.
Я думаю я смог показать простоту, удобство и широкие возможности класса обработчика.
Хэлперы и части страниц
Помимо обработчиков в модуле проекта у меня лежат классы хелперы и часто используемый фукнционал по формированию html (условно части страниц).
Хелперы, это простенькие классы, можно сказать набор функций объединенных в класс. Я часто использую хелпер Files для ресайза и получения изображений (который в отличие от битриксовского всегда возвращает и src, и SRC, плюс еще несколько удобных вещей делает), класс Validation для валидации различных данных типа email, телефонов, ИНН, КПП и т.д., класс Mail для отправки почтовых событий с прикрепленными файлами. Кроме того под проекты довольно часто пишутся свои хелперы, если какой то функционал вызывается из нескольких разных мест.
Части страниц это по сути те же хелперы, но не просто набор функций, а уже что-то более менее взаимосвязанное. Например очень частая задача — отобразить любую картинку из анонса, либо из детальной, либо из свойства инфоблока. Для этого я написал класс Image и вынес его в модуль проекта, пример использования:
<?php
//make detail image
$image = new LocalLibPartsImage(array(
'width' => 400,
'height' => 400
));
$image->addImage($this->arProduct['DETAIL_PICTURE']);
$image->addImage($this->arProduct['PREVIEW_PICTURE']);
$image->addImagesList($this->arProduct['PROPERTIES']['MORE_IMAGES']['VALUE']);
$this->arProduct['DETAIL_PICTURE'] = $image->getFirstResized();
В классе последовательно проверяются все переданные данные, и берется первая найденная картинка. По итогу в $this->arProduct[‘DETAIL_PICTURE’] будут храниться данные по файлу картинки, либо false если ни в одном из указанных мест картинка не была найдена. Если картинка найдена, то она сразу пережмется до указанных размеров.
Другой пример для части страниц — слайдеры. Практически во всех проектах есть слайдеры картинок и как правило в слайдер нужно засунуть не одну, а несколько картинок из разных мест, плюс пережать эти картинки под несколько разных размеров, для превью и для отображения на странице как минимум. Класс слайдера работает так:
<?php
//main slider
$arSizes = array(
'FULL' => array(
'width' => 2000,
'height' => 650
),
'PREVIEW' => array(
'width' => 200,
'height' => 100
),
);
$slider = new LocalLibPartsSlider($arSizes);
$slider->addSlide($arResult['DETAIL_PICTURE']);
$slider->addSlidesList($arResult['PROPERTIES']['MORE_PHOTO_SITE']['VALUE']);
$slider->addSlidesList($arResult['PROPERTIES']['MORE_PHOTO']['VALUE']);
$arResult['SLIDER'] = $slider->getSlider();
То есть примерно как с картинкой, указали желаемый массив размеров и на выходе в $arResult[‘SLIDER’] мы получим
- $arResult[‘SLIDER][‘ORIGINAL’] массив картинок в полном оригинальном размере
- $arResult[‘SLIDER][‘FULL’] массив картинок ужатых до какого-то промежуточного размера
- $arResult[‘SLIDER][‘PREVIEW’] массив картинок ужатых до самого мелкого размера
Каждый из массивов содержит все картинки совпадающие по ключу. Картинка $arResult[‘SLIDER][‘ORIGINAL’][0] это та же самая картинка, что и $arResult[‘SLIDER][‘PREVIEW’][0], только с другими размерами естественно. При необходимости можно добавить еще какую то градацию размеров в массив $arSizes
Напишите какой у вас есть часто используемый функционал, который вы вынесли или хотели бы вынести в отдельный класс.
Итого по модулю проекта
Помимо хранилища классов модуль проекта можно использовать для хранения глобальных настроек, достаточно закинуть файлик options.php в корень модуля и с помощью класса Options (сделал свой на основе этого) задать массив желаемых параметров. В модуле сразу можно делать классы моделей для работы с ORM битрикса. Можно сделать класс для работы c Highload блоком, то есть вызываем функцию типа так LocalLibMap::add($arData); в которую передаем чистые данные, или делаем выборку примерно так же, только вместо add что нибудь типа getByUserId, а все взаимодействие с HL блоком прописано внутри класса. В общем модуль проекта это круто, и я крайне советую вам его использовать. Но использовать разумно, не пихать туда все подряд, всякие мелочи, и наоборот большой функционал с использованием всяких сторонних библиотек можно (нужно?) выносить в отдельные модули.
Компоненты
По устройству типового компонента мне нечего добавить. Как использовать result_modifier.php, component_epilog.php, шаблоны компонентов и т.д. все это можно прочитать в официальных обучающих курсах. Единственное что хочу добавить по компонентам касается файла class.php. В каких случаях писать свой компонент, а в каких использовать стандартный я не буду объяснять, большая часть задач решается стандартными компонентами. Остановлюсь чуть подробнее на написании собственных компонентов.
При написании собственных компонентов стоит полностью отказаться от файла component.php. Если там прям совсем какой то микрофункционал, то может быть и стоит его оставить, и то непонятно зачем. Однако на чуть более серьезных задачах стоит пользоваться классом. Перекрываем родительский метод executeComponent() и все содержимое component.php пишем прямо в этой функции. Плюс вместо разделения смысловых блоков комментариями выносим их в отдельные функции. И читабельность кода заметно повышается. Функция executeComponent() если все из нее вынесено в отдельные логические блоки становится довольно короткой, на экран или в крайнем случае на несколько и ее гораздо легче понять, чем десятки экранов сплошного кода разделенного только комментариями.
В классе можно использовать переменную $this->request для доступа к переменным запроса, в эту переменную пишется объект класса BitrixMainHttpRequest и можно прямо сразу в любой функции класса обращаться к его методам, например $this->request->getQuery(«some_name») или $this->request[«some_name»].
В классе доступна функция $this->setTemplateName(‘name’) которая позволяет прямо на лету изменить шаблон, и шаблон переданный при инициализации компонента перестает учитываться. Это может пригодиться например для сложного пошагового мастера, который в зависимости от предыдущих данных определяет текущий шаг и подключает шаблон с этим шагом. Или например если один компонент обслуживает какой-то front-end функционал состоящий из нескольких связанных окошек, можно в зависимости от запроса отображать нужное окошко из определенного шаблона компонента.
В заранее определенной функции onPrepareComponentParams($arParams) можно сразу провести валидацию переданнных в компонент параметров (она получает на вход то что передано в компонент при вызове) и объявить при необходимости ошибку. Там же можно заполнить массив параметров данными из запроса, опять таки провалидировать их и в дальнейшем уже не к запросу обращаться, а просто смотреть гарантированно верные параметры. Функция onPrepareComponentParams() выполняется до executeComponent(), и если в ней объявить ошибку например в переменную класса $this->errors[], то уже в executeComponent() наличие ошибок проверяется просто по заполненности переменной $this->errors
В общем класс компонента может содержать довольно большой объем кода без вреда для читабельности. Это позволяет шире использовать компоненты при решении различных задач. И встает вопрос о том, в каких случаях использовать модуль проекта, а в каких случаях класс компонента.
Компонент vs Модуль
Все это достаточно субъективно, но на мой взгляд выносить какой либо функционал в модуль стоит только в двух случаях:
- Функционал используется в нескольких местах сразу
- Тяжелый функционал
Если функционал используется сразу в нескольких местах, то выносить его в модуль стоит чтобы избежать дублирования. Например работа с HL блоками не требует большого объема кода, однако же если какой либо HL блок используется в компоненте и плюс в каких либо событиях, то разумно будет вынести весь функционал работы с ним в отдельный класс модуля, а в компоненте оставить только вызов этого класса. Дублирование кстати говоря не только в рамках одного проекта, но и в рамках нескольких. Если вы один и тот же функционал используете на многих проектах, пусть даже всего один раз за проект, то возможно имеет смысл его вынести в модуль.
Тяжелый это функционал или нет судить вам, на мой взгляд грань — это внешние библиотеки. То есть в компоненте не должно быть подключения внешних библиотек вообще. Если вы используете какую-то внешнюю библиотеку (тот же phpexcel например), то ее практически наверняка стоит вынести либо в модуль проекта, либо вообще в отдельный модуль по работе с этой библиотекой. Если никакие внешние библиотеки не используются, то никаких четких критериев предложить не могу, разве что количество строк. Если число строк кода в компоненте больше 500-1 000, то возможно стоит задуматься о выносе части кода в модуль.
Общий взгляд
Основные моменты по структуре проекта я обозначил. Возможно в будущем эту статью я буду дополнять. Повторюсь еще раз, моя задача при написании статьи была не показать несколько фишек, или там показать какой то порядок действий, желательно чтобы у вас появился какой то общий взгляд на битрикс разработку. Надеюсь по итогу прочтения у вас появилось более полное понимание о том куда следует добавлять какой то конкретный запланированный функционал. Но если вы просто узнали несколько новых фишек тоже неплохо 🙂