Спомням си онова прекрасно време, когато изграждането на версията за освобождаване на мобилно приложение означаваше, че трябва да зададете debug = false и да започнете да експортирате apk файла. Отнема 2 минути, докато IDE се задейства и сте готови. Всички усилия бяха насочени към необходимостта от уточняване на данните на сертификата за подпис. Това беше съвсем наскоро. Сега процесът на сглобяване на същото приложение се разрасна толкова много, че ако изведнъж трябва да извърша всички операции сам и дори да си спомня всичко и да го направя правилно (което не вярвам), това ще отнеме не един час, което днес изглежда твърде дълъг и най-вероятно ден, след който терапевтът ще бъде задължен да ми предпише отпуск по болест поради умора за две седмици.

И така, процесът на изграждане на мобилно приложение. Ще се опитам да ви кажа от какво се състои - не защото напоследък стана модерно да се публикува информация за CI на определен мобилен отбор (с покер, русалки и други задължителни атрибути), а защото това е страхотно преживяване, което получих, докато работи върху Mail.Ru Mail за Android и защото тази функция най-вероятно няма да съществува, ако работех в различен екип, по различен проект или в друга компания.

За всеки процес важно решение е изборът на система, въз основа на която ще бъде изграден целият монтаж. Надстройките трябва да се обработват от сървъра за изграждане. Това е логично. Но кой да избера?

Въпросът е двусмислен, всеки избира едно или друго решение въз основа на своя опит, на задачите, пред които е изправена системата, и на ресурсите, с които разполага. Някои хора харесват безплатни решения, защото не е нужно да обяснявате на мениджъра си за какво са ви необходими $N000 годишно и защо не можете без тях. Някой е мотивиран от присъствието на общност или от опита на огромен брой екипи, които вече са използвали тези решения и са доволни от резултата. Броят на гледните точки клони към броя на хората, които са задали този въпрос. Не мога да кажа, че аргументът на някого е правилен или нечие възражение е без значение. Но независимо от възгледите, към които се придържа разработчикът, който се сблъсква с подобен проблем, повечето ще се съгласят, че като цяло всички популярни решения на пазара се различават само по лекота на настройка, интеграция със свързани системи, възможности за разширение и поддръжка от общността или системни разработчици.

По принцип изборът на сървър за изграждане е тема за отделен holivar. Нека само да кажа, че избрахме решението на Atlassian Bamboo Build Server. Има няколко основни причини, една от тях е лесната интеграция с тракера за проблеми, който използваме в проекта, както и със системите за преглед на код и хостинг на хранилища. В това момчетата са страхотни: всичко е удобно, всичко е под ръка и, най-важното, почти всички предоставени решения и опции се вписват перфектно в процеса на разработка на нашия екип

бамбук

Бамбукът е много често срещано решение, използвано от огромен брой екипи по целия свят. Подробна информация за работата на този CI/CD инструмент може да бъде намерена на официалния уебсайт за документация, но ще си позволя безплатен превод на малка част от този документ, за да избегна несъответствия в терминологията.

Задачата на сървъра за непрекъсната интеграция е да върши цялата работа по изграждане, тестване, внедряване в тестовата среда на проекта. CI сървърът се свързва с хранилището, получава определена ревизия на проекта, извършва всички необходими действия и предоставя готовия резултат от изграждането на екипа по проекта.

Проект	се състои от един или повече планове за изграждане предоставя отчет за всички планове за изграждане на проекта свързани с други приложения (Jira, Fisheye, Crucible, Stash)
План за изграждане (план)	се състои от един или повече етапи (етап) всички етапи се изпълняват последователно, използвайте едни и същи хранилища съдържа правила за стартиране на компилации, зависимости от други планове за изграждане на проекти
сцена (сцена)	се състои от една или повече произведения изпълнява работа паралелно, на безплатни агенти за изграждане се счита за завършена, когато цялата работа е завършена успешно предава артефакти към следващите етапи на изграждане.
Работете (работа)	се състои от една или повече задачи всички задачи вътре се изпълняват последователно на един и същ агент
Задача (задача)	дискретна операция като проверка на ревизия на проекта, изпълнение на скрипт и т.н.

Повече или по-малко подобно разделяне е налично във всяка система за изграждане, то осигурява необходимата гъвкавост при изграждането на целия процес. На пръв поглед това изглежда като прекомерно усложнение. Същото беше и с нашия проект, когато току-що започнахме да използваме Bamboo, но постепенно всичко се уреди, имаше ясно разбиране коя част от целия процес на изграждане трябва да бъде мащабирана, коя трябва да остане изолирана и в рамките на предложеното концепции, се разви доста последователна структура.

Като цяло трябва да разберете добре, че сървърът за изграждане или CI сървърът е важна част от автоматизирането на процеса на разработка на софтуер. Възлагайки на този модул всички задачи и работа, която трябва да бъде извършена на различни етапи и нива на подготовка на приложението за пускане на пазара, ние получаваме един вид Application Release Pipeline. Това от своя страна дава възможност лесно да се определи кои задачи са включени в конкретна компилация, на какъв етап е изданието сега, какви проблеми възникват при интегрирането на нова функционалност, на какъв етап от подготовката на актуалната корекция сме сега и много повече.

И така, плавно подходихме към описанието на това как се прави това в нашия екип.

Задачи

Нашият проект за изграждане е разделен на няколко етапа, отразяващи основните задачи в момента:

• Изграждане - включва всички опции за изграждане, които може да са необходими по време на тръбопровода Release: алфа, бета, версия. Да, да, у нас се различават проектните асамблеи, а не само статута им. Разлики в продуктите: различни ресурси, наличие или липса на настройки и т.н.
• Проверката е най-обемната и технически сложна част от целия етап на изграждане на приложението: статичен анализ на кода, тестване на модули, функционално тестване на потребителския интерфейс, тестване на локализация.
• Разгръщане. В момента, абстрахиран от цялото събрание, той е като че ли отстрани. По този начин, ако е необходимо, можем да разположим всяка ревизия / клон / тип приложение във всяка среда (алфа, бета, версия).

С това по принцип можете да завършите историята, но аз, може би, ще бъда натрапчив и ще предоставя подробности.

Сглобяване

Сега разработваме три проекта наведнъж с една кодова база, нека ги наречем Проект 1, Проект 2 и Проект 3. Разбира се, разликите между тях не са толкова радикални, колкото между шах и видео плейър, тъй като и трите продукта принадлежат към категорията имейл клиенти. Те обаче имат различен дизайн, има разлики във функционалността, взаимодействат със сървъра по различни начини. Всичко това диктува собствените си изисквания за сглобяване, тестване и разработване на продукта.

Функция за клонов работен поток

Всяка компилация започва с проверка на ревизията на проекта от системата за контрол на версиите. Изглежда, защо да се фокусираме върху това - в края на краищата всеки може да направи плащане? Наистина ли. Но от кой клон трябва да се направи?

Ние използваме Feature Branch Workflow, за да работим върху продукта. Можете да прочетете за този подход отделно. Основното му предимство за мен е изолацията на промените. С този подход всеки разработчик може да превърне поне целия проект в рамките на задачата, да го даде на тестване и ако QA даде одобрение, тогава тестваният и работещ код ще попадне в общия клон. Този подход минимизира риска от попадане на дефект в изданието, поради факта, че е дефинирана последователността от действия: първо проверка, след това сливане в основния клон на проекта.

За да тестваме тези изолирани промени, трябва да имаме сборка, върху която да стартираме автоматични тестове и която ще предадем на ръчно тестване за одобрение от QA екипа. Bamboo предоставя решението за това извън кутията. Нарича се план на клон и се състои във факта, че основният клон е дефиниран за изграждането (например алфа) и всички клонове, които съвпадат според посочения модел, се считат за клон на характеристиките. За тях се създава клонинг на плана за изграждане, но с тази разлика, че проверката ще се извършва от този клон, а не от основния клон на плана за изграждане. Изглежда така.

В изгледа на план за изграждане можем да превключваме между основния клон и съществуващите клонове, като преглеждаме резултатите от всички локални състояния.

Самият план за клон изглежда по същия начин, с изключение на това, че има връзка към задачата.

При този вид поток клонът неизбежно започва да остарява от момента, в който е създаден. За да откриете рано конфликти с основния клон, така че актуализираният код да бъде тестван, трябва постоянно да актуализирате своя клон по време на разработката. Bamboo може да направи това автоматично, преди да изгради проект. В случай на конфликт, сборката няма да бъде изпечена и разработчикът първо ще трябва да актуализира своя клон и след това да натисне тези промени. Тогава няма да има конфликт преди сглобяването и всичко ще продължи както обикновено.

Продуктови аромати

Да кажем, че имаме проект, който трябва да бъде изграден в няколко варианта, променяйки ресурси, код и конфигурации. Има няколко опции как да приложите това. Водехме се от факта, че всички условия за изграждане, всички конфигурации и друга описателна част трябва да бъдат в скрипта за изграждане. В нашия случай Gradle е идеален за тази задача. За него има добър плъгин за Android, който ви позволява гъвкаво да конфигурирате повечето стандартни и нестандартни параметри за изграждане на сложен проект.

Нека видим колко опции за изграждане активно използваме и поддържаме.

Нека започнем с факта, че имаме три основни продукта: проект 1, проект 2 и проект 3.

Вкусът на продукта е представяне на продуктов клон. В повечето случаи това са различни приложения, които имат различни пакети, различни сертификати за подписване, различни източници и ресурси. За всяко приложение имаме няколко опции за изграждане, а именно:

• отстраняване на грешки- подписан с ключ за отстраняване на грешки, може да се отстранява, не се закрива;
• алфа/клон алфа- обфусцирана сборка, различава се по конфигурации за анализи, сриваеми сборки, ресурси, настройки за отстраняване на грешки, налични в приложението;
• бета корпорация- бета версия, която има активирани регистрационни файлове, наличен режим за отстраняване на грешки;
• бета- изграждане възможно най-близо до версията, която се различава по анализи, изграждане на сривове, деактивирани регистрационни файлове, режим за отстраняване на грешки и без настройки за отстраняване на грешки;
• освобождаване- производствена версия на приложението, почти всички допълнителни опции са деактивирани, конфигурирани са анализи и събиране на статистики за бойни проекти в тези системи и т.н.;
• единица/UI тестване- сборки, които имат презаписани манифести, което позволява например да се активират разрешенията за четене на SMS, необходими за автоматизирано тестване за влизане (упълномощаване, регистрация, двуфакторна авторизация) с помощта на SMS код.

Обща сума:

8 типа компилация * 3 вкуса на продукта = 24 варианта на приложение

Защо толкова много? Ще се опитам да отговоря. Едно от типичните предизвикателства при наличието на три различни продукта, които се публикуват в различни среди, е отделянето на анализи. И е необходимо да направите това, в противен случай статистическите данни от алфа версията на приложението ще изкривят картината, която съществува в производството. Ние използваме HockeyApp за събиране на статистически данни за катастрофи. В него имаме отделни проекти за различни варианти на сглобяване. Това улеснява отделянето например на сривове на Проект 1 от сривове на Проект 2, бета версия от версия и т.н.

В build.gradle на нашия проект тази конфигурация изглежда така.

ProductFlavors ( project1 ( ... android.buildTypes ( алфа ( hockeyApp ( ) ) бета ( hockeyApp ( ) ) publicBeta ( ... ) издание ( ... ) ) ) project2 ( ... android.buildTypes ( alpha ( hockeyApp ( ) ) ) ... ) ) project3 ( ... android.buildTypes ( алфа ( hockeyApp ( ) ) ... ) )
По този начин можем да конфигурираме различни стойности за всякакви опции за изграждане. Що се отнася до ресурсите и източниците, тук се използва същият принцип, с изключение на една характеристика: възможно е да се сливат ресурси от различни опции. В нашия проект има ресурси, които са еднакви за всички приложения – например оформлението на екрана за писане на писмо. Ако такива файлове трябваше да се копират във всеки ресурсен пакет и да се съхраняват отделно, тогава при промяна на оформлението на екрана за писане на букви ще трябва да се променят до три файла. За щастие, плъгинът gradle + android може да обедини ресурси.

Ще ви разкажа малко повече за това как се случва това - може би някой ще успее да реши ежедневните си задачи, използвайки същия подход.

Дефинирахме няколко папки с ресурси (всички те се намират в корена на проекта).

• рез- общи ресурси за всички варианти на приложението: тук са общи селектори, маркировки, теми, стилове и т.н.;
• res_project1- ресурси, които са уникални за Проект 1: това включва почти всички графики, които се използват в приложението, редове, които съдържат името на проекта, специфични лога или маркировка - като цяло всичко, което се отнася само за Проект 1;
• res_project23- ето малко по-различна картина: в пакета res _проект23са включени всички ресурси, които не се пресичат с Проекта, но са еднакви за Проект 2 и Проект 3. Такова групиране на ресурси помага за решаването на проблема, когато продуктите Проекти 2 и 3 са много сходни един с друг, като същевременно се различават доста силно от Проект 1. В противен случай ще трябва да копирате същите ресурси в папките res_project2 и res_project3;
• res_project2- ресурси, уникални за Проект 2: в момента цветове, графики, текстове. Всичко останало е в общите пакети;
• res_project3- подобно на Проект 3, в този пакет остава само уникалната селекция от ресурси за това приложение.

В резултат на това за всяка опция за изграждане ние обединяваме няколко пакета, за да получим общ набор от ресурси за приложението:

• Проект 1 = res + res_project1;
• Проект 2 = res + res_project23 + res_project2;
• Проект 3 = res + res_project23 + res_project3.

Това е основата. За по-дълбоко персонализиране можете например да добавите конкретни ресурси, код за тестова компилация и т.н. Цялото затваряне с изходния код изглежда така:

SourceSets ( main ( manifest.srcFile "AndroidManifest.xml" java ( srcDir "src" изключва "**/instrumentTest/**" ) resources.srcDirs = ["src"] aidl.srcDirs = ["src"] renderscript.srcDirs = ["src"] res.srcDirs = ["res"] assets.srcDirs = ["активи"] ) androidTest ( manifest.srcFile "src/instrumentTest/AndroidManifest.xml" java.srcDir "src/instrumentTest/Java" ) project2 ( res.srcDirs = ["res_project2", "res_project23"] java.srcDirs = ["src_common"] assets.srcDirs=["assets_ project2] manifest.srcFile "res_ project23/AndroidManifest.xml" ) project3 ( res.srcDirs = ["res_project3", "res_ project23] assets.srcDirs=["assets_project3"] java.srcDirs = ["src_project3"] manifest.srcFile "res_ project23/AndroidManifest.xml" ) project1 ( res.srcDirs = ["res_project1" ] java.srcDirs = ["src_common"] assets.srcDirs=["assets_project1"] manifest.srcFile "res_project1/AndroidManifest.xml" ) testingUi ( manifest.srcFile "ui_testing/AndroidManifest.xml" ) )
За малките остава така. В конфигурацията на проекта за изграждане трябва да изпълните правилната задача, за да получите желания .apk, например gradle AssemblyProject1PublicBeta. Естествено, при толкова голям брой опции за сглобяване решихме да не ги сглобяваме всички последователно, а да паралелизираме този процес. Общо получихме 6 паралелни задачи, които се изпълняват като част от етапа на монтаж. Всяка работа публикува 3 артефакта на продукт.

Предполагам, че тези, които са чели до този момент, имат въпрос: защо събирате бета версията и пускате с всяка версия на проекта? Въпросът наистина е много интересен. Стигнахме до това решение не веднага, а след много време. Исторически, бета и версията на версиите са създадени отделно, като се използва една и съща ревизия или договор, че кодът е същият там. Тогава разбрахме, че този подход е изпълнен с много проблеми и най-неприятното е, че ще знаете статуса на изграждане, след като решите да публикувате бета версията. Според закона на Мърфи, разбира се, конструкцията е червена. По каквато и да е причина. Колкото повече промени, толкова по-голяма е вероятността те да повлияят негативно на конструкцията и нищо не можем да направим по въпроса. Можете само да съкратите интервала от време между момента на въвеждане на грешка и момента, в който тя е открита. И в идеалния случай, направете го изолирано от общия клон. Ако се абстрахираме от проекта и сглобяването на бета версията или версията за пускане и разгледаме процеса на автоматизация, сега виждам един от основните показатели за качеството на целия подход към автоматизиране на процеса на изграждане, вероятно възможността да разберете за проблемите, които са възникнали възможно най-бързо, и най-важното, да разберете ПРЕДИ как тези промени са влезли в основния клон.

Преглед

Автоматичният контрол на качеството в мобилните приложения, разбира се, е тенденцията от последната година. Според моя опит за мнозина това остава нещо нереалистично. Всички говорят за това, но почти никой не го е виждал. Ние се занимаваме с подобни задачи като част от нашия проект от 2 години и през това време вече сме разработили доста ясно разбиране за повечето от тънкостите, с които всеки разработчик трябва да се сблъска. Всички тези проблеми и решения са сравнително нов и нововъзникващ сегмент за мобилни приложения, въпреки че мрежата отдавна е изминала този път и има достатъчен брой стандартизирани решения.

Първият въпрос, който повечето хора имат, е: какво ще автоматизираме? Разработчикът ще отговори: ние ще тестваме кода, мениджърът веднага ще започне да спори, че функционалността трябва да бъде тествана. Мисля, че и двете трябва да бъдат тествани.

Като цяло, ако говорим за нашето приложение, тогава всички проверки са разделени на няколко категории:

• Статичен анализ: Не знам защо се обръща толкова малко внимание на този подход, той е много мощен инструмент, който ви позволява да прилагате формализирани правила към целия проект, а не към отделни класове;
• Единично тестване: добрите стари модульни тестове, които гарантират, че класът работи точно както разработчикът или потребителят на този клас очаква;
• UiTesting: функционални / тестове от край до край, които проверяват крайния резултат: какво ще види потребителят и как ще работи с него.

Статичен анализ

Като статичен анализатор използваме готови решения. За Android това е Lint, който напоследък се превърна в много ефективен инструмент за наблюдение на качеството на специфичния за android код, ресурси за маркиране, графики и т.н. Освен всичко друго, той ви позволява да добавяте свои собствени проверки, специфични за договора в рамките на проекта. Един такъв договор е, че никакви параметри, свързани с оформлението, не трябва да са в стилове. Например свойствата layout_margin\ layout_alignParentTop или нещо подобно. От гледна точка на синтаксиса, никой не забранява поставянето на тези свойства в стилове, но в този случай самият стил се използва не за определяне на визуалния компонент на някакъв UI компонент, а за съхраняване на някои стойности, които след това не могат да бъдат записано във файла за маркиране. С други думи, стилът се използва като контейнер за атрибути. Решихме, че това са различни неща, които трябва да бъдат разделени, защото, първо, LayoutParams все още се отнасят до маркирането, и второ, те не се отнасят до контролата, в чийто таг са записани тези атрибути, а до нейния родител, в който се намира.

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

Писането на собствени чекове е достатъчно лесно, дори забавно. В хода на добавянето на всякакви статични проверки веднага се появяват куп идеи как статично да се идентифицират някои други проблеми. За Lint ръководствата и официалната документация ще помогнат за това. Можете да разработвате правила директно в Android Studio.

За Java код има и статични анализатори, измислени отдавна. Няма да изброявам всичко, ще говоря само за това, че използваме FindBugs. Когато избрахме инструмент, искахме да получим удобен формат, достатъчно количество правила, по които ще се извършва проверката, и възможност за добавяне на собствени правила. В момента сме написали необходимите проверки, като проверка за затворени курсори, проверка дали екземплярът на AccountManager винаги се получава с контекст на приложението, проверка дали задължителният метод onEventComplete се извиква по време на използване на шаблони на класа на събитието и други. Добавянето на ваши собствени правила, които ще дефинират вътрешно-екипните споразумения, предотвратяват често срещани грешки поради невнимание, е страхотна практика, която намалява времето за преглед на кода и тестване, а също така гарантира, че такива грешки поне не попадат в производствената версия на приложението в бъдещето . Използвахме FindBugs, част 2: Писане на персонализирани детектори като ръководство за писане на персонализирани детектори. Той ясно показва как да създадете своя плъгин, да добавите детектори и да го използвате в процеса на проверка. Отчетът се предоставя или във форматиран HTML документ, или като XML отчет, където се изписва накратко и до точката в кой клас/метод е открита грешката, код на грешката, низ и т.н. Това обикновено е достатъчно, за да разберете къде просто не сте почистили след себе си :-).

Прекрасно, нали? Огромен набор от правила и често срещани грешки вече е готов, има възможност да го допълните, остава само да намерите смелостта в себе си и да започнете да го използвате.

Един ден забелязах, че нашият проект използва SNAPSHOT версии на библиотеки. Очевидно това е валидно само в клон на задачата, когато тези промени са направени в използваната библиотека. След като кодът се слее в основния клон, в проекта не трябва да има МОМЕНТНИ СНИМКИ. В случая причината е доста прозаична и характеризира повечето от тези грешки. След като задачата беше тествана и реши, че тази версия е достигнала цялата дефиниция на готово, разработчикът беше толкова щастлив, че забрави да обедини библиотеката в основния клон, да дефинира нова версия на тази библиотека и да промени версията в основния проект. Проблемът е, че нито Lint, нито FindBugs могат да проверят скрипта за изграждане. Освен това, дори ако тези проверки се добавят към самия build.gradle, трябва да знаете къде е разрешено и къде не. Очевидно това е разрешено в клона, където библиотеката се променя сега, но не е позволено, след като влезе в общия клон. Ето как започнахме да използваме git pre-receive hooks, за да следим какво се случва в проекта на ниво хранилище.

Знам, че много екипи не смятат за необходимо да отделят време за настройка на правила, подходящи за проекта на ниво контрол на източника, защото „нямаме глупаци, никой няма да изтрие всички клонове в хранилището“ или за някои други причини като липса на време. За нас това е преминат етап: стигнахме до решението, че е по-добре да отделим малко повече време, но да бъдем сигурни в безопасността и качеството на продукта. За тази цел куките за предварително получаване работят много добре: можем да открием, че промените се добавят към споделен клон и да проверим дали HEAD на този споделен клон не съдържа нежелан код. В най-добрия случай никой никога няма да разбере за съществуването на такава проверка, но, както показва практиката, една случайна грешка е достатъчна, за да направи възможно особено пробиване. Куката за предварително получаване е чудесна за проверка на всички фиксирани TODO и FIXME, които разработчикът охотно поставя, но забравя да поправи. Освен това върши чудесна работа при решаването на типични проблеми с регистрирането, като добавяне на изхода на new Throwable() към всички функции, от които се интересува разработчикът, тъй като в клона имаше много сложна и подробна грешка. За нас възможността да проследяваме автоматично допуснатите грешки е важна, за да разберем, че няма да стъпим отново на същия рейк. Всеки прави грешки, важното е какви изводи ще направиш след това. Нашето заключение е, че в допълнение към коригирането, трябва да се положат усилия, за да се гарантира, че тези грешки не се допускат в бъдеще.

единично тестване

Тук като цяло всичко е обикновено. За някои класове са написани проверки, за да се гарантира, че класът работи точно както е предвидено, и в същото време да се покаже на клиента на класа пример как може да се използва. Понастоящем модулните тестове се изпълняват на реални устройства, но не установяват реална връзка, ако е необходимо. Между другото, за необходимостта от установяване на връзка: когато разработчикът мисли как да тества конкретен модул, най-често първо мисли как да замени зависимостите на класа, за да изолира тестването от средата на живо. В случай на мрежова връзка това може да изглежда като обезсърчаваща задача, тъй като мрежовата комуникация не се заменя с извикване на един метод, тя изисква подигравка на цял слой логика. Известно време се противопоставяхме на използването на кука в кода на приложението, за да заменим отговора на сървъра и да извършим всички последващи действия с него. Факт е, че този подход увеличава риска кодът, който не работи в производственото приложение, да бъде тестван. Всеки път, когато възникне въпросът дали си струва да промените интерфейса на класа за удобство на тестването, дали си струва да добавяте допълнителни условия към процеса на изпълнение на функция, за да „заключите“ някои зависимости, се опитвам да се придържам към следната позиция : на първо място, целият написан код трябва да е безопасен по отношение на функциите на приложението. Ако допълнителните условия, добавени към кода, изискват отделна проверка, тогава тестовете не трябва да правят това. Това е основната причина, поради която не бяхме доволни от обичайния сетер, който просто ще замести отговора, ще го вземе от друг източник.

В резултат на това стигнахме до друго решение, според мен, по-честно. Ето как изглежда един от тестовете, който проверява дали при определен отговор командата издава статус „error_folder_not_exist“

@AcquireCookie @LargeTest public void testDeleteNonExistingFolder() ( DeleteFolder delete = runDeleteFolder(999); assertERROR_FOLDER_NOT_EXIST(delete); )
В този тест правим честна заявка към сървъра, тоест командата работи точно както в приложението. Проблемът е, че единичният тест зависи от това как е конфигурирана мрежата на устройството, на което работи. И по-долу е вторият тест, който проверява абсолютно същото нещо, но вече замества желания отговор, без да прави реална заявка и без да взаимодейства със сървъра.

@MockMethod(response = RESPONSE_NOT_EXISTS) public void testDeleteNonExistingFolderMock() ( testDeleteNonExistingFolder(); )
По този начин имаме възможността да контролираме изпълнението на тестове - това е необходимо, например, така че състоянието на изграждане да не отчита отговора на сървъра. Разчитаме на факта, че протоколът за взаимодействие е описан и след като се уверим, че заявката е формирана правилно (с помощта на модулни тестове, разбира се), можем да сме сигурни, че сървърът ще даде правилния отговор. И с правилния отговор остава само да се уверите, че приложението го интерпретира съответно. Въпреки това, например, за нощно изграждане, би било хубаво да се уверите, че договорът за взаимодействие със сървъра не е нарушен. За да направите това, ще бъдат стартирани всички тестове, включително тези, които действително взаимодействат с него. Това ще ни даде допълнителна възглавница за безопасност в случай, че поради някакъв бъг договорът за взаимодействие със сървъра бъде нарушен. Научаваме за това от резултатите от тестовете, а не от потребителските отзиви на пазара. Ако за нас е толкова важно да тестваме функционалността от началото до края, тогава можем да направим тези тестове основни и да ги стартираме за всяка компилация на приложението.

Работата е там, че не искаме да зависим постоянно от услугата, но в същото време трябва да наблюдаваме ситуацията и да получаваме информация под формата на ежедневни отчети, че всичко е наред или че някаква част от приложението не е в поръчка. Тук предпочитам да отделя нашето приложение и услугите на трети страни, които са критични за пълното му функциониране, но не са наша област на отговорност. Можем да открием проблем в нашето приложение, свързан с работата на услуга на трета страна, но не можем да го отстраним. Нашата работа е да съобщим за проблема, да изчакаме поправка и да изпълним тестове с тази услуга, за да се уверим, че проблемът е отстранен.

UI тестване

От гледна точка на потребителя, това са най-честните тестове. От гледна точка на разработчика - най-трудният. Най-честните, защото тестват крайния продукт, а не част от него. Прехвърлянето на вината върху някой друг няма да работи: всяка грешка е грешка в приложението и няма значение каква е причината за нея, в несъвършенството на Android в кривите ръце на друг разработчик или в нещо друго. Във всеки случай грешката трябва да бъде коригирана. Предимствата на подобно тестване с черна кутия включват факта, че за нас всъщност няма разлика как е внедрена функционалността, каква архитектура има приложението и т.н. Ако две грешки в приложението се припокриват една с друга и в резултат , потребителят вижда правилния резултат - той ни подхожда. Ако във всичките много случаи грешките в приложението ви позволяват да получите правилните резултати за потребителя, това ни устройва от гледна точка на проверка на функционалността.

Ако модулните тестове проверяват дали кодът работи точно както е предвидил разработчикът, тогава е по-вероятно тестовете на потребителския интерфейс да гарантират, че продуктовият екип е убеден, че потребителските скриптове в приложението се изпълняват правилно.

Грешките също са свързани с потребителски скриптове. Един от най-добрите начини да поправите грешка в приложението, като получите скрипт, който да го възпроизвежда, е да напишете тест. Проверете дали проблемът съществува. Отстранете проблема в кода на приложението (ако е необходимо, придружете с допълнителни модулни тестове на модула, в който не е затворено някакво поведение) и се уверете, че тестът сега преминава. В този случай няма нужда да се използва цялата бюрокрация, при която няколко души трябва да тестват дали грешката е отстранена, че нищо ново не е повредено и т.н. с цел откриване и идентифициране на проблема, тогава в случай на успешното му преминаване, вече има причина да се счита, че проблемът е решен. Колкото повече такива случаи се затварят с тестове, толкова по-добра е проверката, защото толкова по-голяма е вероятността да не сме пропуснали нищо.

Разбира се, всичко това е много по-трудно да се направи, отколкото е да се каже. Но първо: нека започнем с избора на рамка, въз основа на която ще изградим нашите тестове. Отново няма да отварям Америка, като пиша, че сега има много рамки, но не може да се посъветва, че ще реши 99% от всички проблеми. Можете да започнете да пишете своя собствена идеална рамка, залагайки, че коефициентът на кривина на ръката ви е по-малък от този на конкурентите и се надявате, че след месец всичките ви проблеми ще бъдат решени, а след шест месеца, като изчислите цената на такова решение, се върнете отново към този избор. Наистина не обичам да върша чужда работа и може би затова смятам, че този подход е утопичен. Също така виждам кросплатформено тестване като утопия, защото разликите между Android и iOS са твърде големи. Написването на един тестов пакет, който тества както едно приложение, така и друго изглежда като очевидно решение само на пръв поглед. Различна навигация в приложението, различно оформление в рамките на един и същ екран, различно поведение на системата в отговор на минимизирането на приложението, да не говорим за факта, че дори функционалността може да се различава, тъй като всеки висококачествен продукт ще вземе предвид всички характеристики на платформата за да предоставим на потребителя най-доброто изживяване.

В исторически план ние сме използвали Robotium в проекта. Това е много познато решение, което се използва от голям брой екипи както у нас, така и в чужбина. Интересно е, че всички негови потребители са обединени от пламенна неприязън към тази рамка. Той е бавен, нестабилен, неудобно е да се пишат тестове върху него. Но всеки, въпреки това, редовно се връща към употребата му. Дали бизнес Еспресо! Бърз е като вятъра, стабилен е като икономиката на Съединените щати и т. н. Това прави репутацията на гиганта в търсенето с проектите, които поема под крилото си. Пишем на Robotium от 2 години, така че мога да кажа съвсем уверено, че отговорността за нестабилността и ниската скорост е по-скоро на клиента, който пише тези тестове. Нека да разберем това. Причината за проблемите със скоростта често се крие не в несъвършенството на алгоритмите на Robotium, не в неговата архитектура, а във факта, че има злоупотреба с така наречения Sleep Pattern в тестовете. Същността му се крие във факта, че всеки проблем може да бъде решен чрез добавяне на sleep(N * 1000) преди реда, където е открит проблемът. В основата на това е следното просто нещо: тестовете се изпълняват в нишка, различна от основната нишка на приложението (UI Thread). Съответно, синхронизацията, която се извършва със Sleep() не е добро решение на проблема. Оттук и резултатът: изчакайте поне 10 секунди между стъпките в тестовете, резултатът няма да бъде гарантиран. В тестовете, базирани на инструментариум, има нещо, което изчаква нишката на потребителския интерфейс на приложението да завърши операциите, които са в ход. Класът android.app.Instrumentation има метод:

/** * Изчакайте синхронно приложението да бъде неактивно. Не може да бъде извикан * от основната нишка на приложението - използвайте (@link #start), за да изпълните * инструментация в собствената си нишка. */ public void waitForIdleSync() ( validateNotAppThread(); Idler idler = new Idler(null); mMessageQueue.addIdleHandler(idler); mThread.getHandler().post(new EmptyRunnable()); idler(.wait)ForIdle
Използването му, както видяхме от собствения си опит, решава повечето проблеми с факта, че View не е намерен, въпреки че екранните снимки показват, че всичко се показва, както и че View е в междинно състояние, анимирайки свойствата му от една стойност към друга и т.н.

Естествено, историите, че еспресото е в пъти по-добро, ни преследваха. Планът за преминаване към тази рамка е назрял отдавна; освен това Google вече обръща много внимание на въпроса за автоматизираното тестване, така че има предпоставки за това, че Espresso ще се развива по-активно. Решителност беше добавена от убеждението на водещия разработчик, че за да преминете от Robotium към Espresso, е достатъчно да промените TestRunner. Изпробвахме го и тестовете наистина работиха. Сега можем, без да променяме стари тестове наведнъж, да пишем нови скриптове и все още да се наслаждаваме на всички предимства на Espresso. За нас това определи прехода към релсите на новата рамка. Стартирахме тестовете и замръзнахме в очакване на резултатите.

Еспресото се оказа по-бързо, въпреки че нямаше драматични промени. Сега всичките ни тестове са разделени на ~26 пакета и във всеки се забелязва ускорение. Но общите промени в скоростта на преминаване на тестовете се вписват в 4%. Според мен това не е съществено предимство. Много повече, от моя гледна точка, дава възможност да се напише аналог на waitForIdleSync за всяко чакане в приложението: не само за задачи за интерфейс и анимация, но и за задачи за зареждане на данни от мрежата и от диск - за всякакви взаимодействия , резултатът от който трябва да оперираме, като направим проверка в тестовия код. Тази функция се нарича CustomIdlingResource и наистина отличава Espresso от Robotium. Въпреки факта, че идеята е много проста, а именно да ви позволи да регистрирате своята реализация на интерфейса за изчакване на неактивно състояние, персонализираният ресурс за празен ход ви позволява да контролирате синхронизацията между тестовете и приложението. По този начин можете да изчакате, докато всички асинхронни операции преминат в приложението, например, което, заедно със състоянието на неактивност на основната нишка, показва, че можете да прекратите чакането и да започнете да проверявате състоянието на приложението.

Естествено, еспресото не е страхотен джин. Той не може да реши всичките ви проблеми, не може да напише тестове вместо вас и не може да се справи със задачите по поддръжка на тестовата инфраструктура, провеждане на тестове и събиране на отчети.

В допълнение към тестването на действителната функционалност вътре в приложението, често срещана задача, която трябва да бъде решена в контекста на автоматизирано осигуряване на качеството, е взаимодействието на вашия продукт с други приложения, които могат да бъдат инсталирани на телефона на потребителя. Като пример можете да вземете например Споделяне от друго приложение (за имейл клиент това е доста уместно) или лентата на състоянието на известие. И в двата случая скриптът засяга друго приложение, което се изпълнява в различен процес. Всички рамки, подобни на Robotium/Espresso, остават слепи, когато става въпрос за друг процес. За щастие вече съществува решение, което ви позволява да пишете функционални UI тестове за различни приложения и се нарича UI Automator. Ако по-рано трябваше да избираме между една или друга рамка или да поддържаме различни проекти, всеки от които ще бъде изострен за различни проверки, то с пускането на библиотеката за поддръжка на тестване, обявена на последната конференция на Google I / O 2015, можем комбинирайте предимствата на всеки подход и използвайте инструментите, които са необходими за всеки отделен случай. Това означава, че за имейл клиент, например, можем да автоматизираме този сценарий:

1. Стартирайте приложението, отидете на списъка с букви.
2. Отворете писането на ново писмо, въведете тема, получател, прикачени файлове.
3. Получаване на push известие до свързаната пощенска кутия.
4. Отидете на известието, проверете съдържанието на новия имейл.
5. Излезте от новия екран с букви с бутона за връщане. Уверете се, че сме отново на екрана за писане на букви и че всички попълнени полета са запазени.

В този пример можем безопасно да използваме старата рамка, за да навигираме през моделите на списъка с имейли, да четем имейли, да пишем нов имейл и т.н., а за стъпки 3 и 4 можем да използваме рамката uiAutomator, за да проверим текста на известието, уверете се, че известието съдържа необходимите бутони и следвайте известието до приложението. След това тестът ще продължи да използва Espresso API и няма да се налага да пишем друга реализация на съществуващи модели за втората рамка. За мен, като разработчик, това е най-добрата новина, която може да дойде в контекста на библиотеките за автоматизация на тестове.

Разбира се, всичко това изглежда просто само на пръв поглед. Зад кулисите имаше куп събрани рейкове и атака срещу най-неприятните вещества - понякога изглеждаше, че цялата тази идея просто не може да бъде реализирана.

В бъдеще ще говорим отделно за това как се изгражда инфраструктурата, как се осигурява денонощна готовност на устройствата, как се разпределят тестовете за различни продуктови вкусове между различните сглобки, как се тестват различни реализации в зависимост от версията на операционна система, форм-фактор на устройството и др. В крайна сметка имаме толкова дълги две години борба с adb, usb, VirtualBox и много други инструменти и технологии зад гърба си. Предстои повече работа, отколкото вече е свършена, но разбираме, че всичко това не е било напразно.

Препоръчваме ви да закупите този курс в комплект с курса „Разработване на мобилни приложения на 1C 8.3“.

Във втория курс ние анализираме подробно монетизацията на мобилните приложения, както и какво трябва да имате предвид предварително, когато ги разработвате.

Възможност за добавяне на второ ястие в количката ще се появи във формата за въвеждане на поръчка - след като щракнете върху "Направете поръчка!".

Гаранция

Обучаваме от 2008 г., уверени сме в качеството на нашите курсове и даваме своето стандартна 60 дни гаранция.

Това означава, че ако сте започнали да посещавате нашия курс, но изведнъж сте променили решението си (или, да речем, нямате възможност), тогава имате 60-дневен период, за да вземете решение - и ако направите връщане, ние ще възстановим сумата 100% от плащането.

Разсрочено плащане

Нашите курсове могат да се плащат на вноски или на вноски, дори без лихва. При което веднага получавате достъп до материалите.

Това е възможно при плащане от физически лица в размер на 3000 рубли. до 150 000 рубли.

Всичко, което трябва да направите, е да изберете метода на плащане „Плащане чрез Yandex.Checkout“. След това на уебсайта на платежната система изберете „Плащане на вноски“, посочете срока и размера на плащанията, попълнете кратък въпросник - и след няколко минути ще получите решение.

Начини на плащане

Приемаме всички основни форми на плащане.

От физически лица- плащания от карти, плащания с електронни пари (WebMoney, YandexMoney), плащания чрез интернет банкиране, плащания през комуникационни магазини и т.н. Възможно е и плащане на поръчката на части (разсрочено), включително без допълнителна лихва.

Започнете да правите поръчка - и във втората стъпка ще можете да изберете предпочитания от вас начин на плащане.

От организации и индивидуални предприемачи– безкасово плащане, предоставени са документи за доставка. Въвеждате поръчка - и веднага можете да разпечатате фактура за плащане.

Обучение за няколко служители

Нашите курсове са предназначени за индивидуално обучение. Групово обучение на един комплект е незаконно разпространение.

Ако една компания трябва да обучи няколко служители, ние обикновено предлагаме „комплекти с добавки“, които са с 40% по-евтини.

За да направите поръчка за „допълнителен комплект“ изберете 2 или повече комплекта курсове във формуляракато се започне от втория сет цената на курса ще бъде с 40% по-евтина.

Има три условия за използване на допълнителни комплекти:

• не можете да закупите само допълнителен комплект, ако поне един обикновен комплект не е бил закупен преди (или заедно с него).
• няма други отстъпки за допълнителни комплекти (те вече са намалени, щеше да се окаже „отстъпка от отстъпка“)
• промоции (например компенсация от 7000 рубли) не се прилагат за допълнителни комплекти по същата причина

Пример за разработване на мобилно приложение на 1C:ПідPRIємство 8.3 за работа на куриер на онлайн магазин при доставка на стоки до клиенти. За разработка е използвана конфигурацията "Ассемблер на мобилни приложения".

Пример за разработване на мобилно приложение за куриер на онлайн магазин с помощта на "Мобилно приложение асемблер"

И така, разработихме мобилно приложение за работа на куриер на онлайн магазин при доставка на стоки до клиенти. Разбира се, той е доста схематичен и не може да обхване всички задачи, които реално възникват в хода на работата на куриера. Но той изпълнява цялата функционалност, която искахме да покажем в тази книга.

Сега, след като разработката приключи, просто трябва да съберем нашето мобилно приложение в един файл и да го изтеглим на таблета.

Въпреки че за монтажа ще използваме специална конфигурация Създател на мобилни приложения, което улеснява процеса на сглобяване, така или иначе за първи път не е лесно и не бързо да се направи. Ето защо трябва да бъдете търпеливи и внимателно и внимателно да следвате последователността от действия, описана по-долу.

Къде да изтеглите и как да инсталирате Mobile Application Builder

Конфигурация Създател на мобилни приложениядоставени като част от мобилна платформа. В първата глава на книгата в раздела „Мобилна платформа 1C: Enterprise“ разопаковахме архива с мобилната платформа на компютър. Тази директория съдържа папка MobileAppMaker с файл Setup.exe за инсталиране на конфигурационния шаблон. Нека стартираме този файл и инсталираме конфигурационния шаблон в директорията на 1C:Primary шаблон (фиг. 5.1).

Ориз. 5.1. Инсталиране на шаблона за конфигурация "Mobile Application Builder".

След това нека добавим нова информационна база към списъка с информационни бази "1C:Pіdpriemstvo" и създадем информационна база от предварително създадения шаблон (фиг. 5.2).

Ориз. 5.2. Създаване на информационна база "Асамблер на мобилно приложение" от шаблон

След това ще отворим тази база данни в конфигуратора и ще добавим потребителя Администратор със свойствата за удостоверяване на 1C: Enterprise, ролите Администратор и Потребител и езика Руски (фиг. 5.3).

Ориз. 5.3. Създаване на потребител "Администратор".

Нека да запазим конфигурацията, да я затворим и да я отворим в режим 1C:Enterprise от името на потребителя на администратора. Тази база данни в момента е празна. В него трябва да попълним всички необходими параметри за монтажа, които ще бъдат запазени и използвани за по-нататъшни монтажи.

Първо (ако базата е празна), общата помощна информация за създателя на мобилни приложения се отваря на началната страница на приложението. Можете също да получите достъп до него от главното меню - Главно меню > Помощ > Съдържание на помощ > Създател на мобилни приложения. В допълнение, допълнителни страници за помощ за сглобяването на мобилни приложения излизат от индивидуални конфигурационни форми (фиг. 5.4).

Ориз. 5.4. Помощ за конфигуриране на конструктора на мобилни приложения

Конфигуриране на настройките на приложното решение

Първо трябва да настроим опциите за колектор. За да направите това, от менюто на услугата извикайте елемента Настройки на приложението. Сега няма да създаваме мобилно приложение за Apple, така че оставяме съответното квадратче за отметка празно.

Във формуляра за настройки трябва да попълним таблицата с директории на компонентите на компютрите, участващи в процеса на изграждане, която ще съдържа пътищата до софтуерните компоненти, необходими за изграждане на мобилното приложение. За да направите това, щракнете върху бутона Създаване над тази таблица (фиг. 5.5).

Ориз. 5.5. Създаване на запис в таблицата "Каталози на компоненти ..."

Отваря се формулярът Component Paths. Извиквайки помощ от този формуляр, можете да видите връзки за получаване на софтуерни компоненти и тяхното описание (фиг. 5.6).

Ориз. 5.6. Помощ за описание на пътищата на компонентите

Първо трябва да инсталирате Java SDK и да посочите директорията, в която е инсталиран този компонент в полето JDK. Java SDK може да бъде получен от: http://www.oracle.com/technetwork/java/javase/downloads/index.html. Препоръчително е да изтеглите пакета Java Platform Package (JDK).

На страницата, която се отваря, в горната част щракнете върху бутона Изтегляне (фиг. 5.7).

Ориз. 5.7. Получаване на Java SDK

На следващата страница трябва да приемете лицензионното споразумение (задайте отметка в квадратчето Приемане на лицензионно споразумение) и щракнете върху връзката с необходимия комплект за разпространение в колоната Изтегляне (за 64-битов Windows това е jdk-8u60-windows- x64.exe пакет), фиг. 5.8.

Ориз. 5.8. Получаване на Java SDK

Полученият инсталатор трябва да бъде стартиран и Java SDK да бъде инсталиран, например, в директорията: C:\Program Files\Java\jdk1.8.0_60 (фиг. 5.9).

Ориз. 5.9. Инсталиране на Java SDK

След това този път трябва да бъде посочен в полето JDK на формуляра за задаване на пътища към компонентите на приложението Асемблер на мобилно приложение (фиг. 5.10).

Ориз. 5.10. Конфигуриране на пътища към компонентите на мобилното приложение

В следващото поле на конфигурационния формуляр Работна директория и кеш на конструктора трябва да посочите всяка директория на латиница, в която програмата за изграждане ще постави сервизни файлове. Потребителят, под чието име ще бъдат изградени мобилни приложения, трябва да има пълни права за тази директория (фиг. 5.11).

Ориз. 5.11. Конфигуриране на пътища към компонентите на мобилното приложение

В полето за Android SDK посочете пътя до директорията, където се намира SDK Manager. Инсталирахме Android SDK в Глава 1, в раздела за Android SDK (Фигура 5.12).

Ориз. 5.12. Конфигуриране на пътища към компонентите на мобилното приложение

След това трябва да инсталирате Apache ANT и да посочите директорията, в която е инсталиран този компонент в полето Apache ANT. Apache ANT се изисква за създаване на мобилно приложение за Android OS. Apache Ant може да се получи от .

От тази страница трябва да изтеглим архива apache-ant-1.9.6-bin.zip (фиг. 5.13).

Ориз. 5.13. Получаване на Apache ANT

Разархивирайте този файл на компютъра и посочете пътя към него под формата на настройки на пътя на компонента (фиг. 5.14).

Ориз. 5.14. Конфигуриране на пътища към компонентите на мобилното приложение

След това трябва да инсталирате системата PuTTY и да посочите директорията, в която е инсталиран този компонент в полето PuTTY. PuTTY е наличен.

PuTTY се използва при изграждане на мобилно приложение за Apple. Помощните програми pscp.exe и plink.exe са необходими за изграждане на мобилни приложения. За всеки случай нека изтеглим целия инсталационен пакет putty-0.65-installer.exe (фиг. 5.15).

Ориз. 5.15. Получаване на PuTTY

Полученият инсталатор трябва да бъде стартиран и PuTTY инсталиран, например, в директорията: C:\Program Files (x86)\PuTTY (фиг. 5.16).

Ориз. 5.16. Инсталиране на PuTTY

След това посочваме пътя, получен по време на инсталирането на PuTTY във формата за настройка на пътища към компоненти (фиг. 5.17).

Ориз. 5.17. Конфигуриране на пътища към компонентите на мобилното приложение

Това завършва конфигурацията на пътищата към компонентите. Щракнете върху Запиши и затвори.

Конфигуриране на настройките на доставчика

Сега трябва да конфигурираме настройките на доставчика. За да направите това, извикайте елемента Редактиране на параметри на доставчика от менюто Сервиз.

Ще се отвори формулярът Доставчици, в който трябва да посочите произволно име на доставчика в раздела Общи настройки, както и да зададете префикса за идентификационен номер на приложението. Това поле трябва да бъде попълнено на латиница и да започва с низа "com". Правилата за попълване на това поле можете да намерите в контекстната помощ, която се отваря, като щракнете върху бутона със знака „?“.

След това трябва да отбележите за кои операционни системи се изгражда мобилното приложение. В нашия случай поставете отметка в квадратчето За ОС Android.

За да работим с push известия чрез спомагателната услуга "1C:Pіdpriєmstvo", ще посочим параметрите за достъп до услугата. За да направите това, щракнете върху бутона Добавяне над таблицата в долната част на формуляра за доставчик. В прозореца за настройки за достъп до помощната услуга 1C:Pidpriyemstvo, който се отваря, проверете опцията Регистриране за - избран потребител, изберете потребителя на колектора - Администратор и посочете имейл адреса и паролата, под които по-рано се регистрирахме в услугата при тестване на работата с push известия . Щракнете върху бутона Запиши и затвори. Освен това можете да се регистрирате в услугата 1C: Основна директно от този формуляр, като използвате бутона Регистриране на бутона 1C: Основна услуга, ако това все още не е направено (фиг. 5.18).

Ориз. 5.18. Конфигуриране на настройките на доставчика на приложения за конструктор на мобилни приложения

Освен това можете да извикате прозореца за настройка на параметри за достъп до услугата 1C:Enterprise от менюто Service, елемент Параметри за достъп до услугата 1C:Enterprise.

След това в раздела Опции за Android OS попълнете групата полета с ключове за програмисти. За да направите това, първо създайте ключ за разработчик, като щракнете върху връзката Създаване на ключ за разработчик. Във формуляра Създаване на ключ за разработчик, който се отваря, попълнете полетата произволно (за полето Държава трябва да посочите руския код в стандарта ISO - ru) и щракнете върху бутона Генериране на ключ (фиг. 5.19).

Ориз. 5.19. Конфигуриране на настройките на доставчика на приложения за конструктор на мобилни приложения

След това полетата-параметри на ключа за разработчик ще бъдат попълнени автоматично (фиг. 5.20).

Ориз. 5.20. Конфигуриране на настройките на доставчика на приложения за конструктор на мобилни приложения

Стойността в хеш полето SHA1 на ключа на разработчика ще бъде използвана по-късно за получаване на ключа за работа с Google maps. Тази стойност е задължителна, ако мобилното приложение ще използва инструментите за местоположение на платформата Android.

Това завършва настройките на доставчика. Щракнете върху Запиши и затвори.

Изтегляне на мобилна платформа

Сега трябва да изтеглим мобилната платформа "1C:Pіdpriєmstvo", под която ще работи сглобеното мобилно приложение. Може да има няколко версии на мобилната платформа, но те трябва да са поне версия 8.3.4.

Директорията за мобилни платформи е предназначена за изтегляне и съхранение на различни версии на мобилната платформа. В тази директория трябва да се създаде отделен запис за всяка версия на платформата.

От командния панел на приложението отворете директорията Мобилни платформи и щракнете върху бутона Създаване. След това ще се появи диалогов прозорец за избор на файл, в който трябва да изберете файла с архива на мобилната платформа mobile.zip, който запазихме на компютъра, когато получихме мобилната платформа в първата глава на книгата, в „1C : Enterprise Mobile Platform” раздел. Изберете го и щракнете върху бутона Отвори.

При успешно зареждане на платформата ще се отвори формата за създаване на елемента Мобилни платформи директория, в която автоматично ще се попълнят полетата Версия на мобилната платформа и Име и ще се появи квадратчето за отметка Заредени файлове на Мобилна платформа (фиг. 5.21).

Щракнете върху Запиши и затвори.

Изтеглете мобилна конфигурация

Сега трябва да заредим мобилната конфигурация, разработена от нас CourierOnlineStore. Нека отворим тази конфигурация в конфигуратора. В палитрата със свойства на конфигурацията задайте свойствата Vendor - myfirm и Version - 1.0.0 (фиг. 5.22).

Ориз. 5.22. Свойства на мобилната конфигурация "CourierOnline Store"

След това ще качим тази конфигурация във файл, като изпълним командата на конфигуратора Конфигурация > Мобилно приложение > Запис във файл...

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

От командния панел на приложението отворете директорията Mobile configurations и натиснете бутона Create group с името на нашата конфигурация Online Store Courier (фиг. 5.23).

Ориз. 5.23. Създаване на група директории "Мобилни конфигурации"

След това в тази група ще създадем нов елемент от директорията.

След това ще се появи диалогов прозорец за избор на файл, в който трябва да изберете файла 1cema.xml, в който току-що запазихме нашата мобилна конфигурация. Изберете го и щракнете върху бутона Отвори.

Ако конфигурацията бъде качена успешно, всички полета на формуляра ще бъдат попълнени автоматично и не трябва да се променят ръчно. Таблицата с разрешения ще изброява всички разрешения за работа на мобилното приложение с мултимедия, геолокация, известия и т.н., които сме задали при разработката му. Освен това ще се показват съобщения за невъзможността за работа с календари и контакти, за които не сме задали разрешения (фиг. 5.24).

Щракнете върху Запиши и затвори.

Описание на настройките на мобилното приложение

Сега трябва да опишем параметрите на мобилното приложение, които ще съберем в директорията Mobile Applications.

Препратката трябва да има структура на две нива, където групата описва основните параметри за изграждане, а елементът на групата определя настройките за изграждане за конкретна версия на мобилното приложение. За всяко мобилно приложение трябва да се създаде отделна група и да се създаде отделен елемент за всяка версия на мобилното приложение в тази група.

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

Имаме един доставчик - Моята компания. Ще се попълни автоматично. Освен това ще постави отметка в квадратчето за Android OS. Нека оставим полето Мобилна платформа празно - най-новата версия на платформата ще се използва автоматично по време на изграждането.

В полето Solution ID посочете произволен низ на латиница. Следващото му поле ще се попълни автоматично (фиг. 5.25).

Ориз. 5.25. Създаване на група директории "Мобилни приложения"

След това автоматично ще се попълни полето Параметър за получаване на ключ за работа с Google maps (това поле се заменя със стойността на параметъра Hash SHA1 на ключа на разработчика на доставчика Моята компания от формуляра за настройки на доставчика, виж Фиг. 5.20 + низ за идентификатор на решение) - това ще ни е необходимо, за да получим ключа за работа с Google maps. За да направим това, трябва да се свържем с услугата на Google и след като получим ключа, да го напишем в полето Ключ за работа с Google maps.

Тази статия е за тези, които се интересуват от мобилния клиент. Ще разгледаме инсталирането на мобилен клиент на Android, свързване на отстраняване на грешки и изграждане на apk на приложението в конфигурацията на Mobile Application Builder.

Най-накрая се появи тестовата мобилна платформа 8.3.12 и вече можем да тестваме работата на мобилния клиент. Не знам за вас, но много от познатите ми разработчици чакаха това от публикуването на статията за „1C: През огледалото“ (мобилен клиент).

Предполагам, че сте запознати с инсталирането на мобилно приложение и създателя на мобилни приложения и че вече имате инсталиран Android SDK, Apache Ant и други. Вече има много статии по тази тема.

Нека вземем демонстрационната конфигурация на „Управлявано приложение“ за нашите експерименти и за начало да се опитаме да я свържем с готов мобилен клиент. В моя случай клиентската дистрибуция е файлът "1cem-client-arm.apk". Предварително на смартфона трябва да е активирана възможността за инсталиране на приложения от неизвестни източници. При мен изглежда така:

Мобилният клиент е аналог на уеб клиент, следователно, за да получите достъп до базата данни, той трябва да бъде публикуван на уеб сървър. Тук всичко е стандартно, публикувам на уеб сървъра на IIS с името „демо“. Имам файлова база, така че трябва да дам правата върху директорията на потребителя на IUSR. Радвам се, че самата система напомни за това.

Свързваме базата данни в мобилния клиент:

Разбира се, не беше възможно веднага да се влезе в базата данни J Работата е там, че администраторът отваря обработката за работа с електронна поща и се опитва да зададе икона за лентата на задачите, която не е в мобилния клиент. Тъй като тази функционалност също не е налична в уеб клиента, кодът е поставен в директивите за компилация "#If Not WebClient Then". Просто трябва да намерим всички места, където се използва тази директива и да я променим на "#If Not WebClient AND Not MobileClient Then". Като за начало това е напълно достатъчно и най-накрая можем да видим работата на мобилния клиент. Командният интерфейс изглежда така:

Ето списъка на състезателите:

Разбира се, това не са всички места, които трябва да бъдат адаптирани за мобилния клиент. Можете да проверите конфигурацията с помощта на "Главно меню - Конфигурация - ---Проверка на конфигурацията":

Открих 84 грешки, включително неподдържани обекти с метаданни. Плюс тези три места в кода, които вече ограничих до директиви. Така че все още трябва да работите върху адаптацията, но това със сигурност не е същото като писането на мобилно приложение от нулата.

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

Ако не разберем каква е грешката, отстраняването на грешки ще ни помогне. Той е в мобилния клиент, но се използва само HTTP отстраняване на грешки. Имам файлова база, така че ще използвам локалния сървър за отстраняване на грешки ("Инструменти - Опции - Отстраняване на грешки") и ще настроя автоматична връзка за мобилния клиент ("Отстраняване на грешки - Свързване - Автоматично свързване"):

Посочете параметрите и сте готови:

Настройката за предварително подготвения apk клиент от 1C е завършена.

Сега ще изградим нашия apk с помощта на създателя на мобилни приложения. Честно казано, прекарах няколко часа, опитвайки се да създам приложението за първи път. Сглобяването премина, но се отвори празен списък с бази.

И така, имаме архив на мобилната версия на платформата. Качете го в директорията "Мобилни версии":

В настройките на колектора се появи отделен елемент за SDK 26 и по-високи (който, като мен, не се е актуализирал дълго време - стартирайте SDK Manager и изтеглете нови пакети):

Следващата стъпка е да подготвите конфигурационния файл. Точно с тази стъпка имах проблеми в самото начало. След това отворих документацията и всичко се изясни малко. Ръководството на разработчика казва следното за това: „Всяка конфигурация, която може да работи в мобилен клиент, съдържа някаква помощна информация, която ви позволява да проследявате подмяната на конфигурацията.“
Конфигурационният файл трябва да бъде подписан. В същото време за всяка конфигурация се генерира частен ключ, а публичен ключ (полето DSAKey) се качва във файла 1cemca.xml, с помощта на който се сравнява конфигурационният подпис.

За да генерирате ключ и подпис, отидете на конфигурационните свойства "Подпис на мобилен клиент" (веднага под необходимите разрешения, ако вашите свойства са разделени на категории, а не по азбучен ред) и вижте настройките за подпис:

Първо създаваме частен ключ, като го крием от шпиони и врагове. След това формираме подписа на конфигурацията. За в бъдеще ръководството съветва да отидете в "Главно меню - Конфигурация - Мобилен клиент - Настройка на използването на мобилния клиент". В диалоговия прозорец поставете отметка в квадратчето „Проверете подписа на мобилния клиент при актуализиране на конфигурацията на базата данни“ и щракнете върху бутона „OK“. Съдейки по ръководството, подписът ще се промени, ако променим състава или имената на типовете обекти на метаданни, както и имената и/или състава на ключовете за вписване в регистъра. Тези. промяната на формулярите определено не засяга подписа и, съдейки по описанието, промяната на състава на детайлите на съществуващите директории, документи (но това не е точно).

Подписът е готов, можем да продължим. Веднага трябва да кажа, че фоновите процеси в мобилния клиент не са налични, така че трябва да бъдат деактивирани в разрешенията на мобилния клиент. Също така не е налично за прехвърляне на файлове от компютър. Допълнително изключих геолокацията, за да не генерира грешка в монтажа поради липса на ключ за работа с карти. Получих следния списък с разрешения: