Windows.  Viruslar.  Noutbuklar.  Internet.  Idora.  Utilitalar.  Haydovchilar

Mobil ilovalarni ishlab chiqish har doim qo'shimcha texnologiyalarni o'rganish zarurati bilan bog'liq. Agar savolni qayta ko'rib chiqsak va allaqachon tanish bo'lgan vositalardan foydalansak nima bo'ladi?

Birinchi marta 1C kompaniyasi kirishga harakat qildi mobil rivojlanish bozori 2006 yilda. O'sha paytda PDA-lardan foydalangan holda masofaviy xodimlarning ishini avtomatlashtirish uchun haqiqiy shoshilish bor edi. Bunday muammolarni hal qilish uchun yangi dasturlar qo'ziqorin kabi paydo bo'ldi va turli biznes sohalarini avtomatlashtirish uchun muvaffaqiyatli mahsulotlarga ega 1C kabi sotuvchi foydali bozorga kirish imkoniyatini qo'ldan boy bermadi.

2006 yil o'rtalariga kelib kompaniya "1C: Enterprise 8. Portativ kompyuterlar uchun kengaytma" istiqbolli nomi bilan yangi mahsulotni taqdim etdi. 8-platformaning istiqbollarini ko'rgan 1C ishlab chiquvchilari, endi bitta vositadan foydalanib, o'sha yillarda mashhur bo'lgan "Windows Mobile" mobil operatsion tizimini ishlab chiqish juda qiyin bo'lishiga umid qila boshladilar.

Amalda, hamma narsa yomonroq ko'rinardi. Ushbu vosita original g'oyalarni amalga oshirishga imkon bermadi. Plastik to'rva " Portativ kompyuterlar uchun kengaytma» toʻliq ishlab chiqish yechimidan koʻra maʼlum tipik konfiguratsiyalar uchun qoʻshimcha edi. Yangi metama'lumotlar ob'ektlarini qo'shish orqali konfiguratsiya funksiyalarini kengaytirish uchun hech qanday shart yo'q edi. Uchinchi tomon dasturchilariga juda oddiy narsalar qoldirildi: foydalanuvchilarning o'zaro aloqasi uchun yangi shakllarni yaratish, foydalanuvchi hodisalarini qayta ishlash.

Ha, cheklovlar uchun har qanday vaqtinchalik echimlar bor edi, lekin ular hatto haqiqiy rivojlanishga imkon bermadi. Texnik cheklovlardan tashqari, iste'molchilar jiddiy moliyaviy to'siqni his qilishdi. 1C dan yechimni amalga oshirishga qaror qilgan kompaniyalar samarali PDA sotib olishlari, Windows Mobile uchun litsenziyalarni sotib olishlari, shuningdek, yechim va yakuniy dasturni yetkazib berish uchun 1C to'lashlari kerak edi.

1C dan yechim juda qimmat edi. Pulni tejashga odatlangan kompaniyalar muqobil echimlardan foydalanishda davom etishdi. Bundan tashqari, alternativalarni ishlab chiquvchilar o'z mahsulotlarini standart 1C echimlari bilan o'zaro ishlash uchun funksionallik bilan jihozlashga muvaffaq bo'lishdi.

Texnik cheklovlar va yuqori narx mahsulotga ish stoli platformasining ulkan muvaffaqiyatini takrorlashga imkon bermadi. Binoning mobil bozorini zabt etish g'oyasi.

ilovalar muvaffaqiyatsiz tugadi.

Bir qadam oldinga

Muvaffaqiyatsiz loyihaning yo'qotishlari va yo'qotishlari istiqbolli yo'nalishning rivojlanishiga chek qo'ymadi. 2013 yilda 1C kompaniyasi mobil ilovalarni ishlab chiqish funksiyasiga ega yangi platforma 8.3 ning birinchi barqaror versiyasini taqdim etdi.

1C mobil "teorema" ni echishda o'z yondashuvini butunlay qayta ko'rib chiqdi va oldingi muvaffaqiyatsiz mahsulotning xatolarini hisobga oldi. Natijada o'zidan oldingi bilan hech qanday umumiylik yo'q va eng zamonaviy mobil platformalar - Android va iOS-ga qaratilgan mutlaqo yangi vosita.

1C uslubida mobil ilovalar

Mobil platformalar uchun rivojlanish imkoniyatlari bilan to'liq tanishish uchun biz kichik konfiguratsiyani ishlab chiqishga harakat qilamiz. Yakuniy misoldan foydalanib, siz mavjud funksionallikni yaxshiroq baholashingiz va muammolarni hal qilish uchun 1C platformasidan foydalanish imkoniyati to'g'risida qaror qabul qilishingiz mumkin.

Ishlash uchun sizga 1C: Enterprise 8.3 platformasining so'nggi versiyasi kerak bo'ladi. Tarqatishning o'quv versiyasi 1C rasmiy veb-saytida mavjud. Uning imkoniyatlarining namunasini qayta tiklash uchun ko'proq narsa bor.

1C: Enterprise 8.3 platformasidan tashqari, bizga bir qator qo'shimcha vositalar kerak bo'ladi. Ushbu maqolada Android ilovasini ishlab chiqish misoli ko'rib chiqiladi. Shu munosabat bilan siz yuklab olishingiz kerak bo'ladi: Android SDK va Apache WEB server. Birinchi komponent dasturni yaratish uchun zarur bo'lgan hamma narsani va sinov uchun emulyatorni o'z ichiga oladi va WEB-server ilovani mobil OTga tezda yuklab olish uchun foydalidir.

Shuningdek, biz “Mobil dasturchilar platformasi”ni yetkazib berishni talab qilamiz. Unda yaratilgan mobil ilovani yaratish jarayonini soddalashtirish uchun konfiguratsiya, shuningdek, mobil dasturchilar platformasi mavjud. U mobil qurilma yoki emulyatorga o'rnatilishi kerak.

Google Play orqali tarqatishga tayyor dasturni yaratish uchun siz yuklab olishingiz kerak bo'ladi Apacheant Va JavaJDK. Ushbu mavzu ushbu maqola doirasidan tashqarida, shuning uchun siz ushbu vositalar bilan ishlash va dasturni yig'ish haqida ko'proq ma'lumotni mening tegishli bo'limda topishingiz mumkin.

Asboblarni sozlash

platformasi" 1C: Enterprise 8.3" va Apache veb-serveri o'rnatuvchilar bilan ta'minlangan va standart tarzda o'rnatiladi. Android SDK siz uni alohida katalogga ochishingiz va ishga tushirishingiz kerak " sdk manager.exe" Sizning oldingizda o'rnatish uchun mavjud paketlar tanlovi bilan oyna paydo bo'ladi. Ushbu maqolada muhokama qilingan misolni sinab ko'rish uchun siz quyidagilarni tanlashingiz va o'rnatishingiz kerak: Android SDK vositalari, A ndroid platformasi vositalari, SDK platformasi API 17.

Oxirgi qadam yangi axborot bazasini yaratish bo'ladi. "Bo'yicha rivojlanishda ishtirok etmaganlar uchun" 1C: Korxona“Men ushbu platforma uchun har qanday yechim axborot bazasi va konfiguratsiyadan iboratligini tushuntiraman. Yangi ma'lumotlar bazasini qo'shish "ni bosish orqali amalga oshiriladi. Qo'shish» boshlash oynasi. Ma'lumotlar bazasini qo'shgandan so'ng, uni " Konfigurator».

Birinchi mobil konfiguratsiya

Konfiguratorning asosiy menyusida biz bo'limni topamiz " Konfiguratsiya" va "Konfiguratsiyani ochish" -ni tanlang. Konfiguratsiya daraxti (kelajakdagi dasturni tashkil etuvchi ob'ektlar) oynaning chap tomonida ko'rsatiladi. Undagi konfiguratsiya ildizini tanlang va tugmalar birikmasini bosing " Alt+Enter" Xususiyatlar muharriri konfigurator oynasining o'ng qismida ochiladi.

Keling, konfiguratsiyaga qo'ng'iroq qilaylik " QILMOQ" va "Foydalanish maqsadi" xususiyatida biz " Mobil qurilma" E'tibor bering, oxirgi amalni bajarganingizdan so'ng, konfiguratsiya daraxtining ba'zi tugunlari nofaol bo'ladi. Afsuski, mobil platformada barcha metadata ob'ektlaridan foydalanish mumkin emas.

Muammoni hal qilish uchun konfiguratsiya daraxtida bir nechta metadata ob'ektlarini yaratishimiz kerak bo'ladi:


Protsedura AddTask(Task) ExportRecordManager = CreateRecordManager(); RecordManager.Period = CurrentDate(); RecordManager.Task = Vazifa; RecordManager.Status = Task.Status; RecordManager.Record(); EndProcedure

Listing 2. “Yopilmagan vazifalar roʻyxatini olish()” funksiyasi kodi.

Funktsiya GetList of UnClosedTasks() Eksport so'rovi = Yangi so'rov; Query.Text = "Tanlash |TaskStatusSliceLast.Task AS Task, |TaskStatusSliceLast.Task.ExecutionDate AS ExecutionDate |FROM | Information Register.TaskStatus.SliceLast(&CurrentDate, Status)<>VALUE(Enumeration.TaskStatuses.Completed)) AS StateTasksSliceLast | |BUYuRDIRIB | Amalga oshirish sanasi DESC"; Request.SetParameter("CurrentDate", CurrentDate()); Return Request.Execute().Unload(); EndFunction

Biz ma'lumotlar registridan ma'lumotlarni olish va uni yozib olishni tartibladik, endi ma'lumotnomamizga registr bilan ishlashni o'rgatamiz. Buning uchun konfiguratsiya daraxtiga "nomli umumiy modul qo'shing. Vazifalar bilan ishlash" Siz usiz ham qila olasiz, lekin men darhol kodni modullarga bo'lish imkoniyatiga e'tibor qaratmoqchiman. Ko'pgina 1C ishlab chiquvchilari hali ham ushbu tavsiyani e'tiborsiz qoldiradilar va barcha mantiqni bir joyda tasvirlaydilar va shu bilan keyingi kodni saqlashni murakkablashtiradilar. Keling, modulda yangi protsedura yarataylik " Yangi vazifa yarating(3-ro'yxatga qarang).

Listing 3. “Yangi vazifa yaratish” protsedurasi uchun kod

Protsedura Yaratish NewTask(Link) Export If Link.ThisGroup Keyin Qaytish; endIf; So'rov = Yangi so'rov; Query.Text = "Tanlash |TaskStatusSliceLast.Status |FROM |Ma'lumot Register.TaskStatus.SliceLast(&CurrentDate, Task = &Task) AS TaskStatusSliceLast"; Query.SetParameter("CurrentDate", CurrentDate()); Request.SetParameter("Vazifa", Havola); Natija = Query.Run().Select(); Agar Natija.Next() bo'lsa, Natija.Status bo'lsa<>Bog'lanish.Status Keyin ma'lumot registrlari.Vazifa holati.AddTask(Link); endIf; Aks holda Information Registers.TaskStatus.AddTask(Link); endIf; EndProcedure

Yangi yozuvni yaratishdan oldin, vazifa uchun mavjud yozuvlar mavjudligi tekshiriladi. Agar yozuv allaqachon mavjud bo'lsa, siz vazifa holatini solishtirishingiz kerak. Agar registrdagi holat yozilayotgan elementning holatidan farq qilmasa, qo'shimcha yozuv yaratishning hojati yo'q.

Yakuniy teginish sifatida keling, "Vazifalar" katalog elementining shaklini ochamiz va voqea ishlov beruvchisini yaratamiz " AfterRecordingOnServer" Unda biz uchinchi ro'yxatda tasvirlangan protseduraga qo'ng'iroq qilamiz:

WorkWithTasks.CreateNewTask(CurrentObject.Link);

Biz interfeys ustida ishlayapmiz

Ilovaning asosiy funksionalligi tayyor - foydalanuvchi vazifalarni yaratishi mumkin va har bir yangi vazifa davriy ma'lumotlar registrida yozuv yaratadi. Endi interfeysga o'tamiz. Keling, vazifalar bilan ishlashni birinchi o'ringa qo'yaylik. Ilovani ishga tushirgandan so'ng darhol yopilmagan vazifalar ro'yxatini va yangisini yaratish qobiliyatini ko'rsatish mantiqan to'g'ri keladimi?

Keling, tugunni topamiz " Umumiy shakllar"va" deb nomlangan yangi shakl qo'shing Ish stoli" Yaratilgan shaklni interfeys dizaynerida ochamiz va " kabi atributni qo'shamiz. Qadriyatlar jadvali" Keling, buni "OpenZachi" deb ataymiz. Jadvalda ikkita ustun bo'ladi - " Vazifa"(Ma'lumot havolasi. Vazifalar) va" Amalga oshirish sanasi"(sana).

Keyingi qadam qo'shilgan rekvizitlarni shaklga sudrab borishdir. Biz oddiy jadval uchun interfeysga ega bo'lishimiz kerak. Biz hech qanday o'lchamlarni belgilamaymiz, biz interfeysni platformaga o'tkazish tashvishini qoldiramiz.

Yaratilgan jadval uchun Mulk inspektorida mulk uchun katagiga belgi qo'ying " Faqat koʻrish", va mulk" Buyruqlar panelining joylashuvi» “Yo‘q” qiymatini o‘rnating. Jadvalni dinamik ma'lumotlar bilan to'ldiramiz, shuning uchun uni foydalanuvchi tomonidan tahrir qilishning ma'nosi yo'q.

Endi forma uchun “When CreatedOnServer” hodisasi ishlovchisini tasvirlaylik. Keling, unga bir qator kod qo'shamiz:

OpenTasks.Load(InformationRegisters.TaskStatus.GetListofUnClosedTasks());

Kodda biz tasvirlangan protseduraga murojaat qilamiz " Yopilmagan vazifalar ro'yxatini oling” va uning bajarilishi natijasi jadvalga joylashtiriladi.

Keling, shakl dizayneriga qaytaylik va ikkita tugma bilan "Displeysiz muntazam guruh" turini qo'shamiz: " Yaratmoq"Va" Yangilash" Mulk" Guruhlash"Qo'shilgan guruh uchun qiymatni" Gorizontal "ga o'rnating. Tugmalarni yanada ifodali qilish uchun tasvirlarni qo'shing va standart shriftni o'zgartiring.

Endi tugmani tanlang " Yaratmoq"va unga global buyruq bering" Vazifalar: yaratish" Bu sizga katalogning o'ziga kirmasdan vazifalar yaratish imkonini beradi. Ikkinchi tugmani bosish orqali biz jadval mazmunini vazifalar bilan yangilaymiz. Buning uchun siz qo'shimcha forma buyrug'ini yaratishingiz kerak bo'ladi.

Barcha yangi shakl buyruqlari bir xil nomdagi yorliqda yaratilgan " Jamoalar" Printsip oddiy - biz yangi buyruq qo'shamiz, undagi harakat kodini tasvirlaymiz va keyin buyruqni interfeys bilan, bizning holatlarimizda tugma bilan bog'laymiz.

Shuningdek, biz boshqariladigan dasturni ishlab chiqayotganimizni unutmasligimiz kerak, shuning uchun mijoz va server kodini aniq ajratib olishimiz kerak. Tugma bosilganda kontekst paydo bo'ladi " OnClient", va biz serverdan ma'lumotlar bazasidan ma'lumotlarni olamiz. Kodda bu shunday ko'rinadi:

&Mijoz protsedurasi UpdateTaskList(Buyruq) UpdateList(); Protseduraning oxiri &Serverda yaratilgan protsedura bo'yicha (Muvaffaqiyatsizlik, StandardProcessing) OpenTasks.Load(InformationRegisters.TaskStatus.GetListofUnClosedTasks()); EndProcedure

Endi ish stoli formamizni bosh sahifa maydoni sifatida belgilaymiz. Konfiguratsiya xususiyatlarini oching (eng yuqori tugunni tanlang va " Alt+Enter") va "Bosh sahifaning ish maydoni" xususiyatini "ga o'rnating. Bir ustun", keyin shaklimizni ro'yxatga qo'shing" Ish stoli».

Ilova to'liq tayyor va uni amalda sinab ko'rish vaqti keldi. Misolni ishga tushirib ko'ring va "dan boshqa holatga ega bo'lgan bir nechta vazifalarni yarating. Bajarildi" Ma'lumotlar reestri yangi yozuvlar bilan to'ldirildi (buni menyu bandi orqali ko'rish mumkin " Barcha funksiyalar") va ularning ba'zilari ish stolida ko'rsatiladi.

Android-ga tushish

Konfiguratsiya ish stolida ajoyib ishlaydi va endi uni mobil OS emulyatorida sinab ko'rish vaqti keldi. Yangi emulyatorni tayyorlash uchun buyruq tarjimonini ishga tushiring ( cmd.exe) va Android SDK tarqatishning "toos" katalogiga o'ting. Buyruqni bajaring " android.bat avd", bu virtual Android qurilmalar menejerini ishga tushiradi. Unda "Yaratish" tugmasini bosing va paydo bo'lgan oynada virtual qurilmaning parametrlarini belgilang. Ish muhitimda men taqlid qilishga qaror qildim Android bilan Nexus S 4.2.2 versiyasi. (API darajasi 17).

Qurilmani yaratgandan so'ng, biz uni darhol ishga tushiramiz. Android yuklanayotganda, keling, konfiguratorga qaytaylik va ilovamizni veb-serverda nashr etamiz. Konfiguratorning asosiy menyusida elementni tanlang " Konfiguratsiya» -> « Mobil ilova» -> « Nashr qilish" Nashr sozlamalari oynasida biz dastur nomini (har qanday narsa bo'lishi mumkin), veb-serverni (bizning muhitimizda bitta bo'lishi kerak) va sozlamalarni saqlash uchun katalogni belgilaymiz.

Ism sifatida belgilash " todo-mobile", ilova manzilda mavjud bo'ladi - " http://host/todo-mobile" "OK" tugmasini bosing va brauzer yordamida nashr etilgan ilovaga kirishga harakat qiling. Muvaffaqiyatli bo'lsa, server yaratilgan konfiguratsiyaning XML kodini qaytaradi.

Biz emulyatorga qaytamiz va unga mobil ishlab chiquvchi platformasi bilan ilovani yuklaymiz. Ilova faylining o'zi mobil dasturchi platformasini yetkazib berish bilan birga mavjud va "1cem-arm.apk" deb nomlanadi. Ushbu dasturni emulyatorga o'rnatish uchun biz yordam dasturidan foydalanamiz " adb.exe"katalogdan" platforma vositalari»: adb.exe o'rnatish -r 1cem-arm.apk.

Muvaffaqiyatli o'rnatishdan so'ng, emulyatorda ilovalar ro'yxatini oching va mobil ishlab chiquvchi platformani ishga tushiring. Ochilgan oynada "ni bosing. Ilova qo'shish" va "manzil" maydonida biz veb-serverimizga URL manzilini ko'rsatamiz. Menda bu bor http://192.0.168.106/todo-mobile. "bosing" Qo'shish"va bizning konfiguratsiyamiz mobil platformaga muvaffaqiyatli o'tkazildi. Ilova foydalanishga tayyor. Natijani sinab ko'ring va konfiguratorga qayting, ilovalarni "mobil funksionallik" bilan ta'minlash vaqti keldi.

SMS/MMS xabarlarini yuborish

SMS/MMS bilan ishlash funksiyalari xabar almashish mobil platformalar tomonidan turlicha qo'llab-quvvatlanadi. Masalan, Android-da dasturni ishga tushirganda, ishlab chiquvchi SMS-ga obuna bo'lish va ularni olgandan so'ng darhol yangi xabarlarga kirish imkoniyatiga ega. Afsuski, xuddi shu xususiyat iOS-da mavjud emas, shuning uchun ishlab chiqish jarayonida hujjatlar qo'lda bo'lishi kerak.

SMS xabarlarni yuborish uchun ob'ekt taqdim etiladi SMS xabar. Keling, bir misolni ko'rib chiqaylik:

&OnClient protsedurasi SendSMSMessage(Recipient, MessageText) NewMessage = Yangi SMSMessage(); NewMessage.Text = MessageText; NewMessage.Recipients.Add(Recipient); Telefoniya vositalari.SendSMS(NewMessage); EndProcedure

Kod juda oddiy va sharhlarga muhtoj emas. Keling, kiruvchi xabarlarga obuna bo'lishni ko'rib chiqaylik:

&Mijoz protsedurasi bo'yicha ConnectMessageReceivingHandler() SubscribeToMessages = New AlertDescription("ProcessingNewMessages", ThisObject); Telefoniya vositalari.ConnectSMSMessageHandler(SubscribeToMessages); Protseduraning oxiri &Mijozning yangi xabarlarni qayta ishlash tartibi (Xabar, qo'shimcha parametrlar) // Yangi xabarni qayta ishlash // Xabar, xabar. EndProcedure

Jarayon " Yangi xabarlarni qayta ishlash" har safar yangi SMS kelganda qo'ng'iroq qilinadi. Parametr orqali " Xabar"turdagi ob'ekt" uzatiladi SMS xabar» va biz xabar matnini va jo‘natuvchi haqidagi ma’lumotlarni osongina olishimiz mumkin.

MMS xabarlari bilan ishlash xuddi shu tarzda amalga oshiriladi. Avval biz SMS-xabar yaratamiz, so'ngra unga qo'shimcha (masalan, tasvirlar) qo'shamiz. Ushbu oddiy amal bilan SMS MMSga aylanadi:

NewMessage= Yangi SMSMessage(); Biriktirma = Yangi MMSA ilovasi; Attachment.Data = Rasm; Attachment.ContentType = "rasm/jpeg"; MMSMessage.Attachments.Add(Ilova);

Mobil ilovadan qo'ng'iroq qilish

Dasturiy qo'ng'iroq "Telefoniya asboblari" global ob'ektining "Raqamni terish" usuli yordamida amalga oshiriladi. Usulni chaqirishdan oldin, qo'ng'iroq qilish imkoniyatini tekshirish tavsiya etiladi:

Agar Telephony Tools.SupportedDialing() bo'lsa, Keyin Telefon vositalari.DialNumber(Telefon raqami, Darhol qo'ng'iroq); endIf;

Parametr " Darhol qo'ng'iroq qiling» terish unumdorligiga ta'sir qiladi. "ga teng bo'lganda To'g'ri", terish standart qo'ng'iroq ilovasi orqali avtomatik ravishda amalga oshiriladi. Agar “False” qiymati o‘rnatilgan bo‘lsa, foydalanuvchi standart terish interfeysini ham ko‘radi, lekin qo‘ng‘iroq qilish uchun tugmani bosish kerak bo‘ladi. Qo'ng'iroq qiling».

Qo'ng'iroqlar jurnali

Mobil platforma ishlab chiquvchiga qo'ng'iroqlar jurnali bilan o'zaro aloqa qilish imkonini beradi. Masalan, siz chiquvchi, o'tkazib yuborilgan yoki kiruvchi qo'ng'iroqlar ro'yxatini osongina olishingiz mumkin. Bu xususiyat faqat Androidda qo'llab-quvvatlanadi:

Qo'ng'iroqlar jurnali = Telephony Tools.GetCall Log(); Tanlash = NewDataCompositionSelection; Tanlash elementi = Selection.Elements.Add(Type("DataCompositionSelection Element")); SelectionElement.LeftValue = NewDataCompositionField("CallType"); SelectionElement.ComparisonView = ComparisonTypeDataLayout.Equals; SelectionElement.RightValue = CallLogCallType.Missed; SelectionElement.Use = rost; CallLog yozuvlari ro'yxati = CallLog.FindRecords(Tanlash); //Qo'ng'iroqlar jurnali yozuvlari ro'yxati yozuvlar to'plamini o'z ichiga oladi

Geopozitsiyalash

Deyarli har qanday zamonaviy smartfon geolokatsiya funksiyalariga ega. Siz ushbu funksiyadan o'rnatilgan 1C tilidan foydalanishingiz mumkin. Qurilmaning joriy koordinatalarini olish 2 bosqichga bo'linishi mumkin: geopozitsion provayderni tanlash va olingan koordinatalarni qayta ishlash:

//Platformaga provayder tanlashni taqdim qilaylik IdealProvider = Geopositioning Tools.GetMost AccurateProvider(); Koordinatalar = GeoPositioningTools.GetLastLocation(IdealProvider); //Agar koordinatalar uzoq vaqt oldin olingan bo'lsa, yangilang If Koordinatalar = Aniqlanmagan OR CurrentDate() – Koordinatalar.Sana > 3600 Keyin Geopozitsiyalash Tools.UpdateLocation(IdealProvider, 60); Koordinatalar = GeoPositioningTools.GetLastLocation(IdealProvider); endIf;

Multimedia funksiyalari bilan ishlash

Ishlab chiquvchi o'rnatilgan tildan foydalangan holda rasm, video va audio yozuvlarni olish imkoniyatiga ega: Suratga olish(), Video yozib oling(), Audio yozib oling().

1C da qaysi mobil operatsion tizimni ishlab chiqish yaxshiroq?

Apple texnologiyasiga bo'lgan muhabbatimga qaramay, Android uchun 1C platformasidan foydalangan holda mobil ilovalarni yaratish yaxshidir. Buning bir qancha sabablari bor, lekin eng muhimi qo'llab-quvvatlanadigan funktsiyalardir. Afsuski, iOS-da ko'plab kerakli narsalar qo'llab-quvvatlanmaydi. Misol uchun, SMS-xabarlarga dasturiy ravishda obuna bo'lish yoki qo'ng'iroqlar jurnallari bilan o'zaro aloqada bo'lish imkonsizligi ba'zi g'oyalarni amalga oshirishni imkonsiz qilishi mumkin. Android bu borada ancha do'stona. Qurilmalarning o'zlari narxi haqida unutmang. Har bir kompaniya Apple-dan mobil qurilmalarni sotib olishga tayyor emas.

To'ldirish o'rniga

platformasi" 1C: Enterprise 8» korporativ rivojlanishni rivojlantirish uchun oddiy vositaga aylanishga tayyorligini amalda isbotladi. Mobil platformalar uchun ilovalar. Maqolada muhokama qilingan misollar buning qo'shimcha tasdig'idir. Agar ilovaning funksionalligi mobil platforma imkoniyatlariga to'g'ri kelsa va kompaniyada 1C mahsulotlari ustunlik qilsa, mahalliy vositalarni o'rganish uchun resurslarni sarflashning hojati yo'q.

Mijozlarga tovarlarni etkazib berishda onlayn-do'kon kurerining ishi uchun 1C: Enterprise 8.3 da mobil ilovani ishlab chiqish misoli. Ishlab chiqish uchun "Mobil ilovalarni ishlab chiqaruvchi" konfiguratsiyasi ishlatilgan.

"Mobil ilovalar yaratuvchisi" dan foydalangan holda onlayn-do'kon kuryeri uchun mobil ilovani ishlab chiqish misoli

Shunday qilib, biz mijozlarga tovarlarni etkazib berishda onlayn-do'kon kurerining ishlashi uchun mobil ilovani ishlab chiqdik. Albatta, bu juda sxematik va kurerning ishi paytida yuzaga keladigan barcha vazifalarni qamrab ololmaydi. Ammo u biz ushbu kitobda ko'rsatmoqchi bo'lgan barcha funktsiyalarni amalga oshiradi.

Endi, ishlab chiqish tugallangandan so'ng, biz qilishimiz kerak bo'lgan narsa mobil ilovamizni bitta faylga yig'ish va uni planshetga yuklab olishdir.

Garchi biz yig'ish uchun maxsus konfiguratsiyadan foydalansak ham Mobil ilovalar yaratuvchisi, yig'ish jarayonini osonlashtiradigan, birinchi marta hali ham oson yoki tez emas. Shuning uchun siz sabr-toqatli bo'lishingiz va quyida tavsiflangan harakatlar ketma-ketligini diqqat bilan va diqqat bilan kuzatib borishingiz kerak.


Mobile Application Builder-ni qayerdan yuklab olish va qanday o'rnatish kerak

Konfiguratsiya Mobil ilovalar yaratuvchisi mobil platformaning bir qismi sifatida taqdim etiladi. Kitobning birinchi bobida "Mobil platforma 1C: Korxona" bo'limida biz arxivni mobil platforma bilan kompyuterga ochdik. Ushbu katalogda konfiguratsiya shablonini o'rnatish uchun Setup.exe fayli bilan MobileAppMaker papkasi mavjud. Keling, ushbu faylni ishga tushiramiz va konfiguratsiya shablonini "1C: Enterprise" shablonlari katalogiga o'rnatamiz (5.1-rasm).

Guruch. 5.1. Mobile Application Builder konfiguratsiya shablonini o'rnatish

Keyin “1C:Enterprise” axborot bazalari ro‘yxatiga yangi axborot bazasini qo‘shamiz va avval yaratilgan shablondan axborot bazasini yaratamiz (5.2-rasm).

Guruch. 5.2. Shablondan “Mobil ilovalar yaratuvchisi” axborot bazasini yaratish

Keyin biz ushbu ma'lumotlar bazasini konfiguratorda ochamiz va 1C: Enterprise Authentication xususiyatlariga ega Administrator foydalanuvchisini, Administrator va Foydalanuvchi rollari va rus tilini qo'shamiz (5.3-rasm).

Guruch. 5.3. "Administrator" foydalanuvchisini yaratish

Keling, konfiguratsiyani saqlaymiz, uni yopamiz va Administrator foydalanuvchisi sifatida 1C: Enterprise rejimida ochamiz. Endi bu ma'lumotlar bazasi bo'sh. Biz uni yig'ish uchun barcha kerakli parametrlar bilan to'ldirishimiz kerak, ular saqlanadi va keyingi yig'ilishlar uchun ishlatiladi.

Avval (ma'lumotlar bazasi bo'sh bo'lsa), mobil ilova yaratuvchisi haqida umumiy yordam ma'lumotlari ilovaning dastlabki sahifasida ochiladi. Siz unga asosiy menyudan ham kirishingiz mumkin - Asosiy menyu > Yordam > Yordam mazmuni > Mobil ilovalar yaratuvchisi. Bundan tashqari, shaxsiy konfiguratsiya shakllaridan mobil ilovalarni yig'ish bo'yicha qo'shimcha yordam sahifalari ochiladi (5.4-rasm).

Guruch. 5.4. Mobile Application Builder konfiguratsiya yordami


Ilova yechimi parametrlarini sozlash

Avval biz kollektor sozlamalarini sozlashimiz kerak. Buning uchun Asboblar menyusidan Ilova sozlamalari bandiga qo'ng'iroq qiling. Biz hozir Apple uchun mobil ilova yaratmaymiz, shuning uchun tegishli katakchani bo'sh qoldiramiz.

Sozlamalar shaklida biz mobil ilovani yaratish uchun zarur bo'lgan dasturiy ta'minot komponentlariga yo'llarni o'z ichiga olgan qurish jarayonida ishtirok etuvchi kompyuterlardagi komponentlar kataloglari jadvalini to'ldirishimiz kerak. Buning uchun ushbu jadval ustidagi “Yaratish” tugmasini bosing (5.5-rasm).

Guruch. 5.5. “Komponentlar kataloglari...” jadval yozuvini yaratish

Komponent yo'llari shakli ochiladi. Ushbu shakldan yordamga qo'ng'iroq qilish orqali siz dasturiy ta'minot komponentlarini va ularning tavsiflarini olish uchun havolalarni ko'rishingiz mumkin (5.6-rasm).

Guruch. 5.6. Komponentlarga yo'llarni tavsiflashda yordam bering

Avval Java SDK-ni o'rnatishingiz kerak va JDK maydonida ushbu komponent o'rnatilgan katalogni ko'rsating. Java SDK ni quyidagi manzildan olish mumkin: http://www.oracle.com/technetwork/java/javase/downloads/index.html. Java Platforma Paketini (JDK) yuklab olish tavsiya etiladi.

Ochilgan sahifada, yuqori qismida Yuklab olish tugmasini bosishingiz kerak (5.7-rasm).

Guruch. 5.7. Java SDK ni olish

Keyingi sahifada siz litsenziya shartnomasini qabul qilishingiz kerak (Litsenziya shartnomasini qabul qilish katagiga belgi qo'ying) va Yuklab olish ustunidagi kerakli tarqatish bilan havolani bosing (64 bitli Windows uchun - bu jdk-8u60-windows-x64. exe to'plami), rasm. 5.8.

Guruch. 5.8. Java SDK ni olish

Olingan o'rnatuvchini ishga tushirish va Java SDK ni o'rnatish kerak, masalan: C:\Program Files\Java\jdk1.8.0_60 (5.9-rasm).

Guruch. 5.9. Java SDK o'rnatilmoqda

Keyin bu yo'l Mobile Application Builder ilovasi komponentlariga yo'llarni o'rnatish uchun shaklning JDK maydonida ko'rsatilishi kerak (5.10-rasm).

Guruch. 5.10. Mobile Application Builder ilovasi komponentlariga yo‘llarni sozlash

Konfiguratsiya shaklining keyingi maydonida, Ishchi katalog va quruvchi keshida siz lotin tilida qurish dasturi xizmat fayllarini joylashtiradigan istalgan katalogni ko'rsatishingiz kerak. Kimning nomidan mobil ilovalar quriladigan foydalanuvchi ushbu katalog uchun to'liq huquqlarga ega bo'lishi kerak (5.11-rasm).

Guruch. 5.11. Mobile Application Builder ilovasi komponentlariga yo‘llarni sozlash

Android SDK maydonida SDK menejeri joylashgan katalogga yo'lni belgilang. Biz Android SDK-ni 1-bobda, "Android SDK" bo'limida o'rnatdik (5.12-rasm).

Guruch. 5.12. Mobile Application Builder ilovasi komponentlariga yo‘llarni sozlash

Keyin siz Apache ANT-ni o'rnatishingiz kerak va Apache ANT maydonida ushbu komponent o'rnatilgan katalogni belgilang. Android OS uchun mobil ilova yaratish uchun Apache ANT talab qilinadi. Apache chumolini olish mumkin.

Ushbu sahifadan biz apache-ant-1.9.6-bin.zip arxivini yuklab olishimiz kerak (5.13-rasm).

Guruch. 5.13. Apache ANT ni olish

Ushbu faylni kompyuteringizga oching va unga boradigan yo'lni komponentlarga yo'llarni o'rnatish shaklida belgilang (5.14-rasm).

Guruch. 5.14. Mobile Application Builder ilovasi komponentlariga yo‘llarni sozlash

Keyin PuTTY tizimini o'rnatishingiz kerak va PuTTY maydonida ushbu komponent o'rnatilgan katalogni ko'rsating. PuTTY ni olish mumkin.

PuTTY, agar siz Apple uchun mobil ilova yaratayotgan bo'lsangiz ishlatiladi. Mobil ilovalarni yaratish uchun pscp.exe va plink.exe yordamchi dasturlari talab qilinadi. Har holda, putty-0.65-installer.exe o'rnatish paketini to'liq yuklab olaylik (5.15-rasm).

Guruch. 5.15. PuTTY olinmoqda

Olingan o'rnatuvchini ishga tushirish va PuTTY-ni o'rnatish kerak, masalan, katalogda: C:\Program Files (x86)\PuTTY (5.16-rasm).

Guruch. 5.16. PuTTY o'rnatilmoqda

Keyin komponentlarga yo'llarni o'rnatish shaklida PuTTY ni o'rnatishda olingan yo'lni ko'rsatamiz (5.17-rasm).

Guruch. 5.17. Mobile Application Builder ilovasi komponentlariga yo‘llarni sozlash

Bu komponent yo'llarining konfiguratsiyasini yakunlaydi. Yozib olish va yopish tugmasini bosing.


Provayder parametrlarini sozlash

Endi biz provayder sozlamalarini sozlashimiz kerak. Buning uchun Asboblar menyusidagi yetkazib beruvchi parametrlarini tahrirlash bandiga qo'ng'iroq qiling.

Yetkazib beruvchilar shakli ochiladi, unda siz Umumiy parametrlar yorlig'ida yetkazib beruvchining o'zboshimchalik nomini ko'rsatishingiz, shuningdek, Ilova identifikatori prefiksini o'rnatishingiz kerak. Ushbu maydon lotin tilida to'ldirilishi va "com" qatoridan boshlanishi kerak. Ushbu maydonni to'ldirish qoidalarini kontekstli yordamda topish mumkin, uni "?" belgisi bilan bosish orqali ochish mumkin.

Keyin mobil ilova qaysi operatsion tizimlar uchun yaratilayotganiga e'tibor berishingiz kerak. Bizning holatda, Android OS uchun katagiga belgi qo'ying.

“1C: Enterprise” yordamchi xizmati orqali push-bildirishnomalar bilan ishlash uchun biz xizmatga kirish parametrlarini aniqlaymiz. Buning uchun yetkazib beruvchi formasining pastki qismidagi jadval ustidagi Qo‘shish tugmasini bosing. Ochilgan oynada "1C: Enterprise" yordamchi xizmatiga kirish sozlamalari, Ro'yxatdan o'tish - tanlangan foydalanuvchi variantini belgilang, kollektor foydalanuvchi - Administratorni tanlang va biz xizmatda avval ro'yxatdan o'tgan elektron pochta manzili va parolni ko'rsating. push-bildirishnomalar bilan ishlashni sinovdan o'tkazish. Saqlash va yopish tugmasini bosing. Bundan tashqari, 1C: Enterprise xizmatiga to'g'ridan-to'g'ri ushbu shakldan 1C: Enterprise xizmatida ro'yxatdan o'tish tugmasi yordamida ro'yxatdan o'tishingiz mumkin, agar bu hali amalga oshirilmagan bo'lsa (5.18-rasm).

Guruch. 5.18. Mobile App Builder ilova provayderi sozlamalarini sozlang

Bundan tashqari, Asboblar menyusidan 1C: Enterprise xizmatiga kirish parametrlarini sozlash oynasiga qo'ng'iroq qilishingiz mumkin, 1C: Enterprise xizmati uchun Access parametrlari.

Shundan so'ng, Android OS uchun sozlamalar yorlig'idagi Tuzuvchi kalitlari guruhini to'ldirishingiz kerak. Buni amalga oshirish uchun avval dasturchi kalitini yaratish havolasini bosish orqali dasturchi kalitini yarating. Ochilgan dasturchi kalitini yaratish formasida maydonlarni tasodifiy ravishda to'ldiring (Mamlakat maydoni uchun siz ISO standartida Rossiya kodini ko'rsatishingiz kerak - ru) va Kalit yaratish tugmasini bosing (5.19-rasm).

Guruch. 5.19. Mobile App Builder ilova provayderi sozlamalarini sozlang

Shundan so'ng, ishlab chiquvchining kalit parametrlari maydonlari avtomatik ravishda to'ldiriladi (5.20-rasm).

Guruch. 5.20. Mobile App Builder ilova provayderi sozlamalarini sozlang

Ishlab chiquvchi kalitining SHA1 Hash maydonidagi qiymat kelajakda Google xaritalari bilan ishlash uchun kalitni olish uchun ishlatiladi. Agar mobil ilova Android platformasida geolokatsiya vositalaridan foydalansa, bu qiymat talab qilinadi.

Bu yetkazib beruvchi parametrlarining konfiguratsiyasini yakunlaydi. Yozib olish va yopish tugmasini bosing.


Mobil platforma yuklanmoqda

Endi biz 1C: Enterprise mobil platformasini yuklab olishimiz kerak, uning ostida yig'ilgan mobil ilova ishlaydi. Mobil platformaning bir nechta versiyalari bo'lishi mumkin, lekin ular 8.3.4 versiyasidan past bo'lmasligi kerak.

Mobil platformalar katalogi mobil platformaning turli versiyalarini yuklab olish va saqlash uchun mo‘ljallangan. Ushbu katalogdagi har bir platforma versiyasi uchun alohida yozuv yaratilishi kerak.

Ilova buyruqlar panelida Mobil platformalar katalogini oching va Yaratish tugmasini bosing. Shundan so'ng, faylni tanlash dialog oynasi paydo bo'ladi, unda siz kitobning birinchi bobida mobil platformani qabul qilishda kompyuterda saqlangan mobile.zip mobil platformasi arxivi bilan faylni tanlashingiz kerak bo'ladi. "Mobil platforma 1C: Enterprise". Uni tanlang va Ochish tugmasini bosing.

Agar platforma muvaffaqiyatli yuklangan bo'lsa, Mobil platformalar katalog elementini yaratish shakli ochiladi, unda Mobil platforma versiyasi va Nom maydonlari avtomatik ravishda to'ldiriladi va Mobil platforma fayllari yuklangan belgilash katakchasi paydo bo'ladi (5.21-rasm).

Yozib olish va yopish tugmasini bosing.


Mobil konfiguratsiya yuklanmoqda

Endi biz ishlab chiqqan Courier onlayn-do'konining mobil konfiguratsiyasini yuklashimiz kerak. Keling, ushbu konfiguratsiyani konfiguratorda ochamiz. Konfiguratsiya xususiyatlari palitrasida Vendor – myfirm va Version – 1.0.0 xususiyatlarini o'rnating (5.22-rasm).

Guruch. 5.22. "Kuryer onlayn do'koni" mobil konfiguratsiyasining xususiyatlari

Keyin biz ushbu konfiguratsiyani Konfiguratsiya > Mobil ilova > Faylga yozish... konfigurator buyrug'ini bajarish orqali faylga yuklaymiz.

Mobil konfiguratsiyalar ma'lumotnomasi mobil ilova konfiguratsiyalarining turli versiyalarini yuklab olish va saqlash uchun ishlatiladi. Katalog ikki darajali tuzilmani nazarda tutadi: guruhlar dastur yechimlarini tavsiflaydi va guruhlardagi elementlar ushbu amaliy yechimlar konfiguratsiyasining turli versiyalarini ifodalaydi. Konfiguratsiyaning yangi versiyasini yuklab olish uchun siz dastur yechimiga mos keladigan guruhga o'tishingiz va ushbu guruhda yangi element yaratishingiz kerak.

Ilovaning buyruqlar panelidan Mobil konfiguratsiyalar katalogini oching va konfiguratsiyamiz nomi bilan guruh yaratish tugmasini bosing Onlayn do'kon Kuryeri (5.23-rasm).

Guruch. 5.23. "Mobil konfiguratsiyalar" katalog guruhini yaratish

Keyin ushbu guruhda biz yangi katalog elementini yaratamiz.

Shundan so'ng, biz mobil konfiguratsiyani saqlagan 1cema.xml faylini tanlashingiz kerak bo'lgan fayl tanlash dialog oynasi paydo bo'ladi. Uni tanlang va Ochish tugmasini bosing.

Agar konfiguratsiya muvaffaqiyatli yuklangan bo'lsa, barcha shakl maydonlari avtomatik ravishda to'ldiriladi va qo'lda o'zgartirilmasligi kerak. Ruxsatlar jadvalida mobil ilovaning multimedia, geopozitsiya, bildirishnomalar va boshqalar bilan ishlash uchun biz uni ishlab chiqish jarayonida o'rnatgan barcha ruxsatnomalari ko'rsatiladi. Bundan tashqari, kalendarlar va kontaktlar bilan ishlashning mumkin emasligi, biz o'rnatmagan ruxsatnomalar haqida xabarlar ko'rsatiladi (5.24-rasm).


Yozib olish va yopish tugmasini bosing.


Mobil ilova parametrlarining tavsifi

Endi biz mobil ilovalar ma'lumotnomasida to'playdigan mobil ilovaning parametrlarini tavsiflashimiz kerak.

Ma'lumotnoma ikki darajali tuzilishga ega bo'lishi kerak, bu erda guruh asosiy yig'ish parametrlarini tavsiflaydi va guruh elementi mobil ilovaning ma'lum bir versiyasi uchun yig'ish parametrlarini belgilaydi. Har bir mobil ilova uchun alohida guruh yaratilishi kerak va ushbu guruhdagi mobil ilovaning har bir versiyasi uchun siz o'z elementini yaratishingiz kerak.

Ilova buyruqlar panelida Mobil ilovalar katalogini oching va Guruh yaratish tugmasini bosing. Ochilgan shaklda Courier Online Store mobil ilovasining nomini o'rnating.

Bizda bitta yetkazib beruvchi bor - Mening kompaniyam. U avtomatik ravishda to'ldiriladi. Android OS uchun katakcha ham tanlanadi. Mobil platforma maydonini bo'sh qoldiring - platformaning so'nggi versiyasi yig'ish paytida avtomatik ravishda ishlatiladi.

Yechim identifikatori maydoniga lotin tilida ixtiyoriy qatorni kiriting. Keyingi maydon avtomatik ravishda to'ldiriladi (5.25-rasm).

Guruch. 5.25. "Mobil ilovalar" katalog guruhini yaratish

Shundan so'ng, Google xaritalari bilan ishlash uchun kalitni olish parametri maydoni avtomatik ravishda to'ldiriladi (bu maydonga yetkazib beruvchi sozlamalari formasidan Mening kompaniyam ishlab chiqaruvchi kalitining Hash SHA1 parametrining qiymati ushbu maydonga kiritilgan, 5.20-rasmga qarang. + yechim identifikatori liniyasi) - bu bizga Google xaritalari bilan ishlash uchun kalitni olish uchun kerak bo'ladi. Buning uchun biz Google xizmatiga murojaat qilishimiz kerak va kalitni olgandan so'ng uni Google xaritalari bilan ishlash kaliti maydoniga yozib qo'yishimiz kerak.

Mobil ilovaning reliz versiyasini yig'ishda o'sha ajoyib vaqt debug = false ni o'rnatishingiz va apk faylini eksport qilishni boshlashingiz kerakligini eslayman. IDE chugs va hamma narsa tayyor bo'lgunga qadar 2 daqiqa o'tadi. Barcha harakatlar imzo sertifikati ma'lumotlarini ko'rsatish zarurligiga qaratilgan. Bu juda yaqinda edi. Endi o'sha ilovani yaratish jarayoni shu qadar o'sdiki, agar men to'satdan barcha operatsiyalarni o'zim bajarishim kerak bo'lsa va hamma narsani eslab, to'g'ri bajarsam ham (men bunga ishonmayman), bu bir soat davom etmaydi. , qaysi bugun taqiqlovchi uzoq ko'rinadi , va, eng ehtimol, bir kun, shundan so'ng terapevt ikki hafta davomida charchoq uchun kasallik ta'tilini buyurish talab qilinadi.

Shunday qilib, mobil ilovani yaratish jarayoni. Men sizga bu nimadan iboratligini aytib berishga harakat qilaman - yaqinda u yoki bu mobil jamoaning CI (poker, suv parisi va boshqa majburiy atributlari bilan) haqida nashr etish modaga aylangani uchun emas, balki bu men olgan ajoyib tajriba bo'lgani uchun. , Android uchun Mail.Ru Mail-da ishlayotganim uchun va agar men boshqa jamoada, boshqa loyihada yoki boshqa kompaniyada ishlaganimda, bu imkoniyat mavjud bo'lmasligi mumkin edi.

Har qanday jarayon uchun muhim qaror butun yig'ilish quriladigan tizimni tanlashdir. Qurilishlar qurilish serveri tomonidan boshqarilishi kerak. Bu mantiqiy. Lekin qaysi birini tanlash kerak?

Savol noaniq, har bir kishi o'z tajribasi, tizim oldida turgan vazifalar va mavjud resurslardan kelib chiqib, u yoki bu yechimni tanlaydi. Ba'zi odamlar bepul echimlarni yaxshi ko'radilar, chunki ular xo'jayiniga nima uchun sizga yiliga N000 dollar kerakligini va nima uchun usiz qila olmasligingizni tushuntirishlari shart emas. Ba'zilar jamoaning mavjudligi yoki ushbu echimlardan allaqachon foydalangan va natijadan mamnun bo'lgan juda ko'p sonli jamoalarning tajribasidan kelib chiqadi. Nuqtai nazarlar soni bu savolni berganlar soniga mos keladi. Birovning argumenti asosli yoki birovning e’tirozi ahamiyatsiz deb ayta olmayman. Ammo, bunday muammoga duch kelgan ishlab chiquvchining qarashlari qanday bo'lishidan qat'i nazar, ko'pchilik, umuman olganda, bozordagi barcha mashhur echimlar faqat konfiguratsiya qulayligi, tegishli tizimlar bilan integratsiyalashuvi, kengaytirish imkoniyatlari va imkoniyatlari bilan farqlanishiga rozi bo'ladi. hamjamiyat yoki tizim ishlab chiquvchilari tomonidan qo'llab-quvvatlash.

Umuman olganda, qurish serverini tanlash alohida muhokama uchun mavzudir. Aytmoqchimanki, biz Atlassianning Bamboo Build Server yechimini tanladik. Bir nechta asosiy sabablar mavjud, ulardan biri biz loyihada foydalanadigan muammoni kuzatuvchisi bilan, shuningdek, kodni ko'rib chiqish va omborlarni joylashtirish tizimlari bilan integratsiya qilish qulayligi. Yigitlar bu borada zo'r: hamma narsa qulay, hamma narsa qo'lda va eng muhimi, deyarli barcha taqdim etilgan echimlar va variantlar jamoamizning rivojlanish jarayoniga juda mos keladi.

Bambuk

Bambuk - bu juda keng tarqalgan yechim va butun dunyo bo'ylab ko'plab jamoalar tomonidan qo'llaniladi. Ushbu CI/CD vositasi qanday ishlashi haqida batafsil tavsifni rasmiy hujjatlar veb-saytida topish mumkin, ammo men atamalardagi tafovutlarni oldini olish uchun ushbu hujjatning kichik qismini erkin tarjima qilishga ruxsat beraman.

Uzluksiz integratsiya serverining vazifasi loyihaning sinov muhitiga yig'ish, sinovdan o'tkazish va joylashtirish bo'yicha barcha ishlarni bajarishdir. CI serveri ombor bilan bog'lanadi, loyihaning ma'lum bir qayta ko'rib chiqilishini oladi, barcha kerakli harakatlarni bajaradi va loyiha jamoasiga tayyor qurilish natijasini beradi.

Loyiha
  • bir yoki bir nechta qurilish rejalaridan iborat
  • barcha loyihani qurish rejalari bo'yicha hisobot beradi
  • boshqa ilovalar bilan bog'langan (Jira, Fisheye, Crucible, Stash)
Qurilish rejasi
(reja)
  • bir yoki bir necha bosqichdan iborat (bosqich)
  • barcha bosqichlar bir xil omborlardan foydalangan holda ketma-ket ishga tushiriladi
  • boshqa loyihalarni qurish rejalariga qarab qurilishlarni ishga tushirish qoidalarini o'z ichiga oladi
Bosqich
(Bosqich)
  • bir yoki bir nechta asardan iborat
  • ishni parallel ravishda bajaradi, bepul qurish agentlarida barcha ishlar muvaffaqiyatli yakunlanganda u tugallangan hisoblanadi
  • artefaktlarni keyingi qurish bosqichlariga o'tkazadi.
Ish
(Ish)
  • bir yoki bir nechta vazifalardan iborat
  • ichidagi barcha vazifalar bir xil agentda ketma-ket bajariladi
Vazifa
(Vazifa)
  • diskret operatsiya, masalan, loyihani qayta ko'rib chiqish, skriptni ishga tushirish va hokazo.


Har qanday yig'ish tizimida ko'proq yoki kamroq o'xshash bo'linmalar mavjud va butun jarayonni loyihalashda zarur moslashuvchanlikni ta'minlaydi. Bir qarashda bu haddan tashqari murakkablik kabi ko'rinadi. Biz bambukdan foydalanishni boshlaganimizda, loyihamizda shunday bo'ldi, lekin asta-sekin hamma narsa o'rnashdi, butun yig'ish jarayonining qaysi qismini masshtablash kerakligi, qaysi qismi izolyatsiya qilinishi kerakligi va taklif qilingan tushunchalar doirasida aniq tushuncha paydo bo'ldi. , ancha uyg'un tuzilma ishlab chiqilgan.

Umuman olganda, siz qurish serveri yoki CI serveri dasturiy ta'minotni ishlab chiqish jarayonini avtomatlashtirishning muhim qismi ekanligini yaxshi tushunishingiz kerak. Ushbu modulga ilovani bozorga chiqarish uchun tayyorlashning turli bosqichlari va darajalarida bajarilishi kerak bo'lgan barcha vazifalar va ishlarni belgilash orqali biz o'ziga xos Ilovalarni chiqarish quvurini olamiz. Bu, o'z navbatida, qaysi vazifalar ma'lum bir tuzilishga kiritilganligini, relizning qaysi bosqichida ekanligini, yangi funksionallikni integratsiyalashganda qanday muammolar paydo bo'lishini, biz hozir tuzatishlarni tayyorlashning qaysi bosqichida ekanligimizni va boshqalarni osongina aniqlash imkonini beradi.

Shunday qilib, biz asta-sekin jamoamizda bu qanday amalga oshirilayotganini tavsiflashga yaqinlashdik.

Vazifalar

Bizning qurilish loyihamiz hozirgi vaqtda asosiy vazifalarni aks ettiruvchi bir necha bosqichlarga bo'lingan:
  • Yig'ish - Chiqaruvchi quvur liniyasi paytida kerak bo'lishi mumkin bo'lgan barcha yig'ish variantlarini o'z ichiga oladi: alfa, beta, versiya. Ha, ha, bizning oramizda nafaqat ularning maqomi bilan farq qiladigan loyiha assambleyalari. Mahsulot farqlari: turli manbalar, sozlamalar mavjudligi yoki yo'qligi va boshqalar.
  • Tasdiqlash dasturni yig'ishning butun bosqichining eng sig'imli va texnik jihatdan murakkab qismidir: statik kod tahlili, birlik testi, funktsional UI testi, mahalliylashtirishni tekshirish.
  • Joylashtirish. Hozirda butun majlisdan mavhum, u yon tomonda bo'lganga o'xshaydi. Shunday qilib, agar kerak bo'lsa, biz har qanday muhitga (alfa, beta, versiya) har qanday reviziya/filial/ilova turini joylashtirishimiz mumkin.
Asosan, hikoya shu erda tugashi mumkin, lekin men, ehtimol, aralashib, tafsilotlarni taqdim etaman.

Assambleya

Endi biz bir vaqtning o'zida bitta kod bazasi bilan uchta loyihani ishlab chiqmoqdamiz, keling, ularni Loyiha 1, Loyiha 2 va Loyiha 3 deb ataymiz. Albatta, ular orasidagi farq shaxmat va video pleer o'rtasidagi kabi radikal emas, chunki har uchala mahsulot ham tegishli. elektron pochta mijozlari toifasiga. Biroq, ular turli xil dizaynlarga ega, funksionallikda farqlar mavjud va ular server bilan boshqacha munosabatda bo'lishadi. Bularning barchasi uni yig'ish, sinovdan o'tkazish va mahsulotni ishlab chiqish uchun talablarini belgilaydi.

Xususiyatlar bo'limining ish jarayoni

Har qanday qurilish versiyani boshqarish tizimidan loyihani qayta ko'rib chiqish bilan boshlanadi. Ko'rinib turibdiki, nega bunga e'tibor qaratish kerak - axir, hamma ham hisob-kitob qila oladimi? Haqiqatan ham. Lekin buni qaysi filialdan qilish kerak?

Biz mahsulot ustida ishlash uchun Feature Branch Workflow dasturidan foydalanamiz. Ushbu yondashuv haqida alohida o'qishingiz mumkin. Men uchun uning asosiy afzalligi - o'zgarishlarning izolyatsiyasi. Ushbu yondashuv bilan har bir ishlab chiquvchi vazifa doirasida hech bo'lmaganda butun loyihani topshirishi, uni sinovga topshirishi mumkin va agar QA ma'qullasa, sinovdan o'tgan va ishlaydigan kod umumiy bo'limga kiritiladi. Ushbu yondashuv, harakatlar ketma-ketligi aniqlanganligi sababli, nuqsonni chiqarish xavfini kamaytiradi: birinchi navbatda tekshiring, so'ngra loyihaning asosiy bo'limiga qo'shing.

Ushbu izolyatsiya qilingan o'zgarishlarni sinab ko'rish uchun bizda avtotestlarni o'tkazishimiz mumkin bo'lgan va QA guruhining tasdiqlashi uchun qo'lda sinovdan o'tkazish uchun taqdim etadigan tuzilma bo'lishi kerak. Bambuk buning uchun kerakli yechimni qutidan tashqarida taqdim etadi. U Filial rejasi deb ataladi va qurilish uchun asosiy filialni aniqlashdan iborat (masalan, alfa) va belgilangan shablonga mos keladigan barcha filiallar xususiyat bo'limi sifatida qabul qilinadi. Ular uchun qurilish rejasining kloni yaratiladi, ammo farqi bilan, hisob-kitob qurilish rejasining asosiy bo'limidan emas, balki ushbu filialdan amalga oshiriladi. Bu shunga o'xshash narsaga o'xshaydi.

Qurilish rejasi ko'rinishida biz barcha mahalliy holat natijalarini ko'rib, asosiy filial va mavjud filiallar o'rtasida almashishimiz mumkin.

Filial rejasining o'zi bir xil ko'rinadi, faqat uning vazifaga havolasi bor.

Bunday oqim bilan ip muqarrar ravishda yaratilgan paytdan boshlab eskirib keta boshlaydi. Eng so'nggi kod sinovdan o'tkazilishi uchun asosiy filial bilan ziddiyatlarni erta aniqlash uchun siz rivojlanish jarayonida filialingizni doimiy ravishda yangilab turishingiz kerak. Bambuk loyihani qurishni boshlashdan oldin buni avtomatik ravishda amalga oshirishi mumkin. Mojaro bo'lsa, qurilish pishirilmaydi va ishlab chiquvchi avval o'z filialini yangilashi va keyin bu o'zgarishlarni surishi kerak. Keyin yig'ilishdan oldin hech qanday nizo bo'lmaydi va hamma narsa odatdagidek ketadi.

Mahsulot lazzatlari

Aytaylik, bizda resurslarni, kodlarni va konfiguratsiyalarni o'zgartiradigan bir nechta o'zgarishlarda yig'ilishi kerak bo'lgan loyihamiz bor. Buni qanday amalga oshirishning bir nechta variantlari mavjud. Biz barcha qurilish shartlari, barcha konfiguratsiyalar va boshqa tavsiflovchi qismlar qurilish skriptida bo'lishi kerakligiga amal qildik. Bizning holatlarimizda Gradle bu muammoni hal qilish uchun idealdir. U uchun yaxshi Android plagini mavjud, bu sizga murakkab loyihani yig'ish uchun ko'pgina standart va nostandart parametrlarni moslashuvchan tarzda sozlash imkonini beradi.

Keling, qancha yig'ish variantlarini faol ishlatayotganimizni va qo'llab-quvvatlashimizni aniqlaylik.

Keling, bizda uchta asosiy mahsulot lazzatlari borligidan boshlaylik: 1-loyiha, 2-loyiha va 3-loyiha.

Mahsulot ta'mi mahsulot bo'limining ifodasidir. Ko'pgina hollarda, bu turli xil paketlar, turli imzo sertifikatlari, turli manbalar va manbalarga ega bo'lgan turli xil ilovalar. Har bir dastur uchun bizda bir nechta qurish variantlari mavjud, xususan:

  • disk raskadrovka- disk raskadrovka kaliti bilan imzolangan, disk raskadrovka qilinishi mumkin, xiralashgan emas;
  • alfa/tarmoq alfa- noaniq yig'ilish, dasturda mavjud bo'lgan tahliliy konfiguratsiyalar, nosozliklar yig'ilishlari, resurslar, disk raskadrovka sozlamalarida farqlanadi;
  • beta corp- jurnallar yoqilgan beta versiyasi, disk raskadrovka rejimi mavjud;
  • beta- nashrga imkon qadar yaqinroq bo'lgan, tahliliy, nosozliklar to'plami bilan ajralib turadigan, jurnallar o'chirilgan, disk raskadrovka rejimi va disk raskadrovka sozlamalari yo'q;
  • ozod qilish- ilovaning ishlab chiqarish versiyasi, deyarli barcha qo'shimcha variantlar o'chirilgan, analitik va statistika to'plami ushbu tizimlardagi jangovar loyihalar uchun sozlangan va hokazo;
  • birlik/UI sinovi- masalan, SMS kodidan foydalangan holda avtomatik kirish testi (avtorizatsiya, ro'yxatdan o'tish, ikki faktorli autentifikatsiya) uchun zarur bo'lgan SMS o'qish ruxsatlarini yoqish imkonini beruvchi manifestlarni qayta yozgan yig'ilishlar.
Jami:

8 ta tuzilish turlari * 3 ta mahsulot ta'mi = 24 ta ilova varianti

Nega shunchalik? Men javob berishga harakat qilaman. Turli muhitlarda chop etilgan uch xil mahsulotga ega bo'lganingizda hal qilishingiz kerak bo'lgan odatiy muammolardan biri bu tahlillarni ajratishdir. Va buni qilish kerak, aks holda dasturning alfa versiyasidagi statistika ishlab chiqarishda mavjud rasmni buzadi. Biz HockeyApp dasturidan halokat statistikasini yig'ish uchun foydalanamiz. Unda bizda turli xil montaj variantlari uchun alohida loyihalar mavjud. Bu ajratishni osonlashtiradi, masalan, 1-loyihaning ishdan chiqishini 2-loyihadan, beta-versiyasini reliz versiyasidan va hokazo.

Loyihamiz build.gradle da bu konfiguratsiya shunday ko'rinadi.

ProductFlavors (loyiha1 ( ... android.buildTypes ( alfa ( hockeyApp ( ) ) beta ( hockeyApp ( ) ) publicBeta ( ... ) versiyasi ( ... ) ) project2 ( ... android.buildTypes ( alpha ( hockeyApp ( ) ) ) ... ) ) project3 ( ... android.buildTypes ( alfa ( hockeyApp ( ) ) ... ) )
Shunday qilib, biz har qanday qurish opsiyalari uchun turli qiymatlarni sozlashimiz mumkin. Resurslar va manbalarga kelsak, bu erda taxminan bir xil printsip qo'llaniladi, bitta xususiyat bundan mustasno: turli xil variantlardan resurslarni birlashtirish mumkin. Bizning loyihamiz barcha ilovalar uchun bir xil bo'lgan resurslarga ega - masalan, yozish ekranining tartibi. Agar bunday fayllar har bir resurs paketiga ko'chirilishi va alohida saqlanishi kerak bo'lsa, xat yozish ekranining tartibini o'zgartirganda, uchta faylni o'zgartirish kerak bo'ladi. Yaxshiyamki, gradle + android plagini resurslarni birlashtirishi mumkin.

Bu qanday sodir bo'lishini sizga biroz batafsilroq aytib beraman - ehtimol kimdir xuddi shu yondashuvdan foydalanib, kundalik muammolarini hal qila oladi.

Biz resurslarga ega bir nechta papkalarni aniqladik (ularning barchasi loyiha ildizida joylashgan).

  • res- barcha dastur variantlari uchun umumiy manbalar: bu erda umumiy selektorlar, belgilar, mavzular, uslublar va boshqalar;
  • res_project1- 1-loyihaga xos bo'lgan resurslar: ilovada qo'llaniladigan deyarli barcha grafikalar shu yerda, loyiha nomini o'z ichiga olgan qatorlar, maxsus logotiplar yoki belgilar - umuman olganda, faqat 1-loyihaga tegishli bo'lgan hamma narsa;
  • res_project23- bu erda bir oz boshqacha rasm: res paketida _ loyiha 23 Loyiha bilan kesishmaydigan, biroq 2-loyiha va 3-loyiha uchun bir xil bo‘lgan barcha resurslarni o‘z ichiga oladi. Resurslarni bunday guruhlash 2 va 3-loyihalarning mahsuli bir-biriga juda o‘xshash bo‘lsa-da, biroq butunlay boshqacha bo‘lsa, muammoni hal qilishga yordam beradi. 1-loyihadan. Aks holda, men bir xil resurslarni res_project2 va res_project3 papkalariga nusxalashim kerak edi;
  • res_project2- 2-loyihaga xos manbalar: hozirda bu ranglar, grafikalar, matnlar. Qolganlarning hammasi umumiy paketlarda;
  • res_project3- xuddi shunday loyiha 3 uchun, ushbu paketda faqat ushbu ilova uchun resurslarning noyob tanlovi qoladi.

Natijada, har bir qurish varianti uchun biz dastur uchun umumiy resurslar to'plamini olish uchun bir nechta paketlarni birlashtiramiz:

  • 1-loyiha = res + res_project1;
  • 2-loyiha = res + res_project23 + res_ project2;
  • Loyiha 3 = res + res_project23 + res_ project3.
Bu asos. Chuqurroq moslashtirish uchun siz, masalan, ma'lum resurslarni, test yaratish uchun kodni va hokazolarni qo'shishingiz mumkin. Bizning manbalar bilan to'liq yopishimiz quyidagicha ko'rinadi:

SourceSets ( asosiy ( manifest.srcFile "AndroidManifest.xml" java ( srcDir "src" istisno "**/instrumentTest/**" ) resources.srcDirs = ["src"] aidl.srcDirs = ["src"] renderscript.srcDirs = ["src"] res.srcDirs = ["res"] assets.srcDirs = ["assets"] ) 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" ) project3Dirres = ["res_project3", "res_ project23] assets.srcDirs=["assets_project3"] java.srcDirs = ["src_project3"] manifest.srcFile "res_ project23/AndroidManifest.xml" ) project1 ( res.srcDirs = ["res ] java.srcDirs = ["src_common"] assets.srcDirs=["assets_project1"] manifest.srcFile "res_project1/AndroidManifest.xml" ) testingUi (manifest.srcFile "ui_testing/AndroidManifest")x.
Bir oz ish qoldi. Qurilish loyihasi konfiguratsiyasida siz kerakli .apk ni olish uchun to'g'ri vazifani bajarishingiz kerak, masalan, gradle assembleProject1PublicBeta. Tabiiyki, bunday ko'p sonli yig'ish variantlari bilan biz ularning barchasini ketma-ket yig'ishga emas, balki bu jarayonni parallellashtirishga qaror qildik. Hammasi bo'lib biz montaj bosqichining bir qismi sifatida amalga oshirilgan 6 ta parallel ishlarni oldik. Har bir ishda har bir mahsulot uchun 3 ta artefakt nashr etiladi.

O'ylaymanki, shu paytgacha o'qiganlarda savol tug'iladi: nega beta-versiyani yig'ish va har bir loyihani yaratishda chiqarish kerak? Savol haqiqatan ham juda qiziq. Biz bu qarorga darhol emas, uzoq vaqtdan keyin keldik. Tarixiy jihatdan, beta va versiya tuzilmalari bir xil tahrir yoki kod bir xil ekanligini ko'rsatadigan shartnoma yordamida alohida qurilgan. Keyin biz tushundikki, bu yondashuv juda ko'p muammolarga to'la va eng yoqimsizi, siz beta-versiyani nashr etishga qaror qilganingizdan so'ng, qurilish holatini bilib olasiz. Merfi qonuniga ko'ra, tabiiy ravishda, qurilish qizil rangga aylanadi. Har qanday sababga ko'ra. Qanchalik ko'p o'zgarishlar bo'lsa, biz bu haqda hech narsa qila olmasdan, ular qurilishga salbiy ta'sir ko'rsatishi mumkin. Siz faqat xato kiritilgan vaqt va u aniqlangan vaqt o'rtasidagi vaqt oralig'ini qisqartirishingiz mumkin. Va ideal holda, buni umumiy filialdan ajratilgan holda qiling. Agar biz loyihadan va beta yoki reliz versiyasini qurishdan mavhum olsak va avtomatlashtirish jarayonini ko'rib chiqsak, men hozir qurilish jarayonini avtomatlashtirishga butun yondashuv sifatining asosiy ko'rsatkichlaridan birini, ehtimol, imkoniyat sifatida ko'raman. yuzaga kelgan muammolar haqida iloji boricha tezroq bilib oling va eng muhimi, bu o'zgarishlar umumiy tarmoqqa qanday kirganligini OLDINDAN bilib oling.

Imtihon

Mobil ilovalarda sifatni avtomatik tekshirish, albatta, o'tgan yilgi tendentsiyadir. Mening tajribamga ko'ra, ko'pchilik uchun bu biroz noreal bo'lib qolmoqda. Bu haqda hamma gapiradi, lekin deyarli hech kim ko'rmagan. Biz 2 yil davomida loyihamiz doirasida bunday vazifalar bilan shug'ullanamiz va shu vaqt ichida biz har qanday ishlab chiquvchi bilan shug'ullanishi kerak bo'lgan ko'pgina nozikliklarni aniq tushunib oldik. Ushbu muammolar va echimlarning barchasi mobil ilovalar uchun juda yangi va hal qilinmagan segmentdir, garchi Internet allaqachon bu yo'lni bosib o'tgan va etarli miqdordagi standartlashtirilgan echimlarga ega.

Ko'pchilikni qiziqtiradigan birinchi savol: biz nimani avtomatlashtiramiz? Ishlab chiquvchi javob beradi: biz kodni sinab ko'ramiz, menejer darhol funksionallikni sinab ko'rish kerakligi haqida bahslasha boshlaydi. Men ikkalasini ham sinab ko'rish kerakligiga ishonaman.

Umuman olganda, agar biz dasturimiz haqida gapiradigan bo'lsak, unda barcha tekshiruvlar bir nechta toifalarga bo'linadi:

  • Statik tahlil: Nima uchun bu yondashuvga juda kam e'tibor qaratilayotganini bilmayman, bu alohida sinflarga emas, balki butun loyihaga rasmiylashtirilgan qoidalarni qo'llash imkonini beruvchi juda kuchli vositadir;
  • UnitTesting: sinfning ishlab chiquvchisi yoki foydalanuvchisi kutganidek ishlashiga ishonch hosil qilish uchun yaxshi eskirgan birlik testlari;
  • UiTesting: yakuniy natijani tekshiradigan funktsional/end-to-end testlari: foydalanuvchi nimani ko'radi va u bilan qanday ishlaydi.

Statik tahlil

Statik analizator sifatida biz tayyor echimlardan foydalanamiz. Android uchun bu Lint bo'lib, u yaqinda Android-ga xos kod, belgilash resurslari, grafikalar va boshqalar sifatini kuzatish uchun juda samarali vositaga aylandi. Boshqa narsalar bilan bir qatorda, bu sizga loyiha doirasida o'zingizning shartnomaga xos tekshiruvlaringizni qo'shish imkonini beradi. Bunday shartnomalardan biri shundaki, hech qanday tartib bilan bog'liq parametrlar uslublarda bo'lmasligi kerak. Masalan, layout_margin\layout_alignParentTop yoki shunga o'xshash xususiyatlar. Sintaksis nuqtai nazaridan, hech kim bu xususiyatlarni uslublarga qo'yishni taqiqlamaydi, ammo bu holda uslubning o'zi ba'zi UI komponentining vizual komponentini aniqlash uchun emas, balki ba'zi qiymatlarni saqlash uchun ishlatiladi, keyin bo'lishi shart emas. belgilash faylida yozilgan. Boshqacha qilib aytganda, uslub atributlar uchun konteyner sifatida ishlatiladi. Biz bularni ajratish kerak bo'lgan turli xil narsalar deb qaror qildik, chunki birinchidan, LayoutParams hali ham belgilash bilan bog'liq, ikkinchidan, ular bu atributlar tegida yozilgan boshqaruvga emas, balki u joylashgan ota-onasiga tegishli.

Agar siz unga qarasangiz, kod yozish bo'yicha qo'llanmalar, belgilash resurslari va ushbu ilovaga xos muammolarni hal qilish uchun shablonlarga ega bo'lgan ko'p yoki kamroq muvaffaqiyatli loyihada bunday narsalar juda ko'p. Ularni kodni ko'rib chiqish bosqichida kuzatish, hujjatlashtirish, har safar ish kunining boshida eslatish mumkin yoki siz ushbu istaklar bilan tanishganingizdan so'ng, kelajakda hamma ularga ergashishiga ishonishingiz mumkin. Ular aytganidek, ishongan odam baxtlidir, lekin shaxsan men o'zim buni unutmasligimni va hech narsani o'tkazib yubormasligimni bilib, zerikarli ishni tezda tugatishga shoshilishim uchun ishlash ancha xotirjam bo'ladi. Siz bunday tekshiruvlarni rasmiylashtirishingiz, ularni qulay hisobotlar bilan qurish jarayoniga qo'shishingiz kerak va yangi vazifani o'z zimmangizga olganingizda, to'satdan barcha tekshiruvlarni o'tkazib yuborgan kodni topib qo'yishingizdan tashvishlanmang, bu sizning sochingizni tikka qo'yadi.

O'z cheklaringizni yozish juda oson, hatto qiziqarli. Har qanday statik tekshiruvlarni qo'shsangiz, darhol boshqa muammolarni statik ravishda aniqlash bo'yicha bir qator fikrlar paydo bo'ladi. Lint uchun qo'llanmalar va rasmiy hujjatlar bunga yordam beradi. Siz to'g'ridan-to'g'ri Android Studio'da qoidalarni ishlab chiqishingiz mumkin.

Java kodi uchun uzoq vaqtdan beri ixtiro qilingan statik analizatorlar ham mavjud. Men hamma narsani sanab o'tmayman, faqat FindBugs-dan foydalanishimizni aytaman. Biz vositani tanlaganimizda, biz qulay formatni, tekshirishni amalga oshiradigan etarli miqdordagi qoidalarni va o'z qoidalarimizni qo'shish qobiliyatini xohladik. Ayni paytda biz kerakli tekshiruvlarni yozdik, masalan, yopiq kursorlarni tekshirish, AccountManager nusxasi har doim dastur konteksti bilan olinganligini tekshirish, hodisa sinfidan shablondan foydalanganda talab qilinadigan onEventComplete usuli chaqirilishini tekshirish va boshqalar. Jamoa ichidagi kelishuvlarni belgilaydigan va e'tiborsizlik tufayli keng tarqalgan xatolarning oldini oladigan o'z qoidalarini qo'shish kodni ko'rib chiqish va sinovdan o'tkazish vaqtini qisqartiradigan ajoyib amaliyotdir, shuningdek, bunday xatolar hech bo'lmaganda ishlab chiqarish versiyasida tugamasligini kafolatlaydi. kelajakda ilova. Tekshiruvlarni yozish bo'yicha qo'llanma sifatida biz FindBugs maqolasidan foydalandik, 2-qism: Maxsus detektorlarni yozish. U o'z plaginingizni qanday yaratishni, detektorlarni qo'shishni va uni tekshirish jarayonida qanday ishlatishni aniq ko'rsatib beradi. Hisobot formatlangan HTML hujjatida yoki XML hisoboti ko'rinishida taqdim etiladi, unda xatolik qaysi sinfda/usulda topilganligi, xato kodi, satr va h.k.larni qisqacha ko'rsatadi. Bu odatda o'zingizdan keyin qayerni tozalamaganingizni tushunish uchun etarli :-).

Ajoyib, shunday emasmi? Katta qoidalar va keng tarqalgan xatolar allaqachon tayyor, uni to'ldirish imkoniyati ham bor, siz jasorat topib, undan foydalanishni boshlashingiz kerak.

Bir kuni men loyihamiz kutubxonalarning SNAPSHOT versiyalaridan foydalanishini payqadim. Shubhasiz, bu faqat ushbu o'zgarishlar foydalanilayotgan kutubxonaga kiritilgandagina vazifa bo'limida amal qiladi. Kod asosiy filialga birlashtirilgandan so'ng, loyihada SNAPSHOTlar bo'lmasligi kerak. Bunday holda, sabab juda prozaik va bu xatolarning aksariyatini tavsiflaydi. Vazifa sinovdan o'tkazilgandan so'ng va ushbu versiya bajarilgan barcha ta'riflarga erishganiga qaror qilingandan so'ng, ishlab chiquvchi shu qadar xursand bo'ldiki, u kutubxonani asosiy filialga birlashtirishni, ushbu kutubxonaning yangi versiyasini belgilashni va versiyani o'zgartirishni unutib qo'ydi. asosiy loyiha. Muammo shundaki, na Lint, na FindBugs tuzilish skriptini tekshira olmaydi. Bundan tashqari, bu tekshiruvlar build.gradle-ning o'ziga qo'shilgan bo'lsa ham, bu qayerda maqbul va qaerda emasligini bilishingiz kerak. Shubhasiz, bu kutubxona o'zgartirilayotgan filialda qabul qilinadi, lekin u umumiy filialga kirgandan keyin qabul qilinishi mumkin emas. Shunday qilib, biz loyihada nima sodir bo'layotganini ombor darajasida kuzatib borish uchun git pre-receive ilgaklaridan foydalanishni boshladik.

Bilamanki, ko'plab jamoalar versiyani boshqarish tizimi darajasida loyihaga mos qoidalarni o'rnatish uchun vaqt sarflashni zarur deb bilishmaydi, chunki "biz ahmoq emasmiz, hech kim ombordagi barcha filiallarni o'chirmaydi" yoki boshqa biron bir narsa uchun. sabab sabablar, masalan, vaqt etishmasligi tufayli. Biz uchun bu o'tgan bosqich: biz bir oz ko'proq vaqt sarflash yaxshiroq degan qarorga keldik, lekin mahsulot xavfsizligi va sifatiga ishonch hosil qiling. Oldindan qabul qilish ilgaklari bu maqsadlar uchun juda yaxshi ishlaydi: biz umumiy filialga o'zgarishlar qo'shilayotganini aniqlay olamiz va ushbu umumiy filialning HEAD qismida keraksiz kod mavjud emasligini tekshirishimiz mumkin. Eng yaxshi holatda, bunday tekshiruvning mavjudligi haqida hech kim hech qachon bilmaydi, ammo amaliyot shuni ko'rsatadiki, tasodifiy xato muhim xato qilish imkoniyatini yaratish uchun etarli. Oldindan qabul qilish ilgagi ishlab chiquvchi o'z xohishi bilan joylashtirgan, lekin tuzatishni unutib qo'ygan barcha tuzatilgan TODO va FIXME-larni tekshirish uchun juda mos keladi. Shuningdek, u odatiy jurnalga yozish muammolarini yaxshi hal qiladi - ishlab chiquvchini qiziqtirgan barcha funktsiyalarga yangi Throwable() chiqishini qo'shish, chunki filialda juda ko'p tafsilotlarni talab qiladigan juda murakkab xato topildi. Biz uchun yo'l qo'yilgan xatolarni kuzatish qobiliyati avtomatik ravishda o'sha rakega boshqa qadam bosmasligimizni tushunish uchun muhimdir. Hamma xato qiladi, bundan keyin qanday xulosalar chiqarishingiz muhim. Xulosa shuki, tuzatish bilan bir qatorda, kelajakda bu xatolarga yo'l qo'ymaslik uchun harakat qilish kerak.

Birlik sinovi

Bu erda, umuman olganda, hamma narsa oddiy. Ba'zi sinflar uchun testlar yozilgan bo'lib, ular sinfning aynan mo'ljallanganidek ishlashiga ishonch hosil qiladi va shu bilan birga sinf mijoziga undan qanday foydalanish mumkinligini ko'rsatadi. Hozirgi vaqtda birlik testlari haqiqiy qurilmalarda ishlaydi, ammo kerak bo'lganda haqiqiy ulanishni o'rnatmaydi. Ulanishni o'rnatish zarurati haqida gapirganda: ishlab chiquvchi ma'lum bir modulni qanday sinab ko'rish haqida o'ylaganida, ko'pincha u o'ylaydigan birinchi narsa testni jonli muhitdan ajratish uchun sinfga bog'liqliklarni qanday almashtirishdir. Tarmoqqa ulanish holatida bu qiyin ishdek tuyulishi mumkin, chunki tarmoq aloqasi bitta usulni chaqirish bilan almashtirilmaydi, bu mantiqning butun qatlamini buzishni talab qiladi. Bir muncha vaqt biz server javobini bekor qilish va u bilan keyingi barcha amallarni bajarish uchun dastur kodidagi kancadan foydalanishga qarshilik qildik. Gap shundaki, bu yondashuv sinovdan o'tadigan kod ishlab chiqarish ilovasida ishlamaydigan kod emasligi xavfini oshiradi. Har safar sinovdan o'tish qulayligi uchun sinf interfeysini o'zgartirish kerakmi, ba'zi bog'liqliklarni "qulflash" uchun funktsiyani bajarish jarayoniga qo'shimcha shartlarni qo'shish kerakmi degan savol tug'ilganda, men quyidagi pozitsiyaga rioya qilishga harakat qilaman. : birinchi navbatda, barcha yozilgan kodlar dastur funktsiyalari nuqtai nazaridan xavfsiz bo'lishi kerak. Agar kodga qo'shilgan qo'shimcha shartlar alohida tekshirishni talab qilsa, testlar buni amalga oshirishga hojat yo'q. Bu javobni oddiygina o'rnini bosadigan, uni boshqa manbadan oladigan oddiy setterdan qoniqmaganimizning asosiy sababi.

Natijada yana bir qarorga keldik, nazarimda, halolroq. Sinovlardan biri shunday ko'rinadi, bu buyruq ma'lum bir javob bilan "xato_papkasi_mavjud emas" holatini ishlab chiqarishini tekshiradi.

@AcquireCookie @LargeTest ommaviy bekor testDeleteNonExistingFolder() ( DeleteFolder delete = runDeleteFolder(999); assertERROR_FOLDER_NOT_EXIST(delete); )
Ushbu testda biz serverga halol so'rov yuboramiz, ya'ni buyruq dasturdagi kabi ishlaydi. Muammo shundaki, birlik sinovi tarmoq u ishlayotgan qurilmada qanday sozlanganiga bog'liq. Va quyida aynan bir xil narsani tekshiradigan ikkinchi test, lekin kerakli javobni almashtirish orqali, haqiqiy so'rovni bajarmasdan va server bilan o'zaro aloqada bo'lmasdan.

@MockMethod(response = RESPONSE_NOT_EXISTS) umumiy bekor testDeleteNonExistingFolderMock() ( testDeleteNonExistingFolder(); )
Shunday qilib, bizda testlarning bajarilishini nazorat qilish imkoniyati mavjud - bu, masalan, qurish holati server javobini hisobga olmasligi uchun kerak. Biz o'zaro ta'sir protokoli tavsiflanganligiga tayanamiz va so'rovning to'g'ri tuzilganligiga ishonch hosil qilish orqali (albatta, birlik testlari yordamida) server to'g'ri javob berishiga ishonch hosil qilishimiz mumkin. Va agar javob to'g'ri bo'lsa, dastur uni shunga mos ravishda talqin qilishiga ishonch hosil qilish qoladi. Biroq, masalan, tungi qurilish uchun server bilan o'zaro hamkorlik shartnomasi buzilmaganligiga ishonch hosil qilish yaxshi bo'lar edi. Buning uchun barcha testlar, shu jumladan, u bilan haqiqatda o'zaro aloqada bo'lganlar ham ishga tushiriladi. Agar biror xato tufayli server bilan o'zaro hamkorlik shartnomasi buzilgan bo'lsa, bu bizga qo'shimcha xavfsizlik tarmog'ini beradi. Biz bu haqda bozordagi foydalanuvchi sharhlaridan emas, balki test natijalaridan bilib olamiz. Agar biz uchun funksionallikni boshidan oxirigacha sinab ko'rish juda muhim bo'lsa, biz ushbu testlarni asosiylariga aylantirishimiz va ularni har bir ilova qurilishi uchun ishlatishimiz mumkin.

Gap shundaki, biz doimiy ravishda xizmatga bog'liq bo'lishni xohlamaymiz, lekin shu bilan birga biz vaziyatni kuzatib borishimiz va har kuni hamma narsa yaxshi ekanligi yoki dasturning ba'zi bir qismi mavjud emasligi haqida xabarlar ko'rinishida ma'lumot olishimiz kerak. buyurtma. Bu erda men ilovamiz va uning to'liq ishlashi uchun muhim bo'lgan, ammo bizning mas'uliyat sohamiz bo'lmagan uchinchi tomon xizmatlarini ajratishni afzal ko'raman. Biz ilovamizda uchinchi tomon xizmatining ishlashi bilan bog‘liq muammoni aniqlashimiz mumkin, ammo uni tuzata olmaymiz. Bizning vazifamiz muammo haqida xabar berish, uning tuzatilishini kutish va muammo bartaraf etilganiga ishonch hosil qilish uchun xizmatda testlarni o‘tkazishdir.

UI testi

Foydalanuvchi nuqtai nazaridan, bu eng halol testlar. Ishlab chiquvchi nuqtai nazaridan, ular eng qiyin. Eng halol, chunki ular yakuniy mahsulotni sinab ko'rishadi, faqat uning bir qismini emas. Buni boshqa birovga yuklash ishlamaydi: har qanday xato bu dastur xatosi va uning sababi nimada bo'lishi muhim emas, boshqa ishlab chiquvchining egri qo'llarida Android-ning nomukammalligi yoki boshqa narsa. Har holda, xatoni tuzatish kerak. Bunday qora quti testining afzalliklari shundan iboratki, biz uchun aslida funksionallik qanday amalga oshirilganligi, ilova qanday arxitekturaga ega ekanligi va hokazolarning farqi yo'q. Agar ilovadagi ikkita xato bir-birining ustiga chiqsa va natijada foydalanuvchi to'g'ri natijani ko'rdi - biz bundan mamnunmiz. Agar ko'p hollarda dastur xatolari bizga foydalanuvchi uchun to'g'ri natijalarni olishga imkon bersa, bu bizga funksionallikni sinab ko'rish nuqtai nazaridan mos keladi.

Birlik testlari kodning ishlab chiquvchi mo'ljallanganidek ishlayotganligini tekshirganda, UI testlari mahsulot jamoasi foydalanuvchi skriptlarining ilovada to'g'ri bajarilishini ta'minlash uchun ko'proq ishlab chiqilgan.

Foydalanuvchi skriptlari bilan bog'liq xatolar ham mavjud. Ilova xatosini qayta ishlab chiqarish uchun skriptga ega bo'lgach, uni tuzatishning eng yaxshi usullaridan biri bu test yozishdir. Muammo mavjudligini tekshiring. Ilova kodidagi muammoni hal qiling (agar kerak bo'lsa, har qanday xatti-harakat yopilmagan modulda qo'shimcha birlik testlari bilan birga bo'ling) va test hozir o'tganligiga ishonch hosil qiling. Bunda butun byurokratik apparatni jalb qilishning hojati yo'q, unda bir necha kishi xato tuzatilganligini, yangi hech narsa buzilmaganligini va hokazolarni tasdiqlashi kerak. Gap shundaki, agar test o'ylangan va aniq yozilgan bo'lsa. muammoni aniqlash va aniqlash maqsadi , agar u muvaffaqiyatli yakunlangan bo'lsa, muammoni hal qilingan deb hisoblash uchun allaqachon sabab bor. Bunday holatlar qanchalik ko'p sinovlar bilan yopilsa, tekshirish sifati shunchalik yaxshi bo'ladi, chunki biz hech narsani o'tkazib yubormaslik ehtimoli shunchalik yuqori bo'ladi.

Albatta, bularning barchasini qilish aytishdan ko'ra qiyinroq. Lekin birinchi navbatda: keling, testlarimizni quradigan ramkani tanlashdan boshlaylik. Shunga qaramay, men hozir juda ko'p ramkalar borligini yozish bilan Amerikani ochmayman, lekin barcha muammolarning 99 foizini hal qiladigan bittasini tavsiya qilish mumkin emas. Siz o'zingizning ideal ramkangizni yozishni boshlashingiz mumkin, qo'lingizning egrilik koeffitsienti raqobatchilaringiznikidan kamroq ekanligiga va bir oy ichida barcha muammolaringiz hal bo'lishiga umid qilib, olti oydan keyin bunday yechimning narxini hisoblab, yana bu tanlovga qayting. Men boshqa odamlarning ishini qilishni yoqtirmayman va ehtimol shuning uchun men bu yondashuvni utopik deb hisoblayman. Shuningdek, men platformalar o'rtasidagi testlarni utopiya deb bilaman, chunki Android va iOS o'rtasidagi farqlar juda katta. Bitta ilovani ham, boshqasini ham tekshiradigan testlar to'plamini yozish birinchi qarashda aniq yechim kabi ko'rinadi. Ilova ichida turli xil navigatsiya, bitta ekranda turli xil tartib, dasturni minimallashtirishga javoban tizimning turli xatti-harakatlari, hatto funksionallik ham farq qilishi mumkinligi haqida gapirmasa ham bo'ladi, chunki har qanday yuqori sifatli mahsulot mahsulotning barcha xususiyatlarini hisobga oladi. foydalanuvchiga eng yaxshi tajribani taqdim etish uchun platforma.

Tarixiy jihatdan biz loyihada Robotiumdan foydalanganmiz. Bu mamlakatimizda ham, xorijda ham ko'p sonli jamoalar tomonidan qo'llaniladigan juda mashhur yechim. Qizig'i shundaki, uning barcha foydalanuvchilarini aynan shu ramka uchun ishtiyoqli yoqtirmaslik birlashtiradi. Bu sekin, beqaror va testlarni yozish uchun noqulay. Ammo har bir kishi muntazam ravishda undan foydalanishga qaytadi. Espresso bo'ladimi! Bu shamol kabi tez, Qo'shma Shtatlar iqtisodiyoti kabi barqaror va hokazo. Qidiruv gigantining obro'si o'z qanoti ostidagi loyihalar uchun shunday qiladi. Biz Robotium-da 2 yildan beri yozyapmiz, shuning uchun ishonch bilan ayta olamanki, beqarorlik va past tezlik uchun javobgarlik ko'proq ushbu testlarni yozgan mijozga tegishli. Keling, buni aniqlaylik. Tezlik bilan bog'liq muammolarning sababi ko'pincha Robotium algoritmlarining nomukammalligida emas, uning arxitekturasida emas, balki testlarda uyqu rejimi deb ataladigan suiiste'mollik mavjudligidadir. Uning mohiyati shundaki, muammo aniqlangan satr oldiga uyqu (N * 1000) qo'shish orqali har qanday muammoni hal qilish mumkin. Buning asosi quyidagi oddiy narsadir: testlar asosiy dastur ipidan (UI Thread) farqli bo'lgan ipda bajariladi. Shunga ko'ra, Sleep() yordamida amalga oshiriladigan sinxronizatsiya muammoning yaxshi yechimi emas. Natija shundan kelib chiqadi: testlardagi qadamlar orasida 10 soniya kutsangiz ham, natija kafolatlanmaydi. Instrumentation-asosidagi testlarda ilovaning UI Thread hozirda bajarilayotgan operatsiyalarni yakunlashini kutadigan narsa bor. android.app.Instrumentation sinfida quyidagi usul mavjud:

/** * Ilovaning ishlamasligi uchun sinxron tarzda kuting. Asosiy dastur chizig'idan * deb chaqirib bo'lmaydi -- o'z oqimida * asboblarni bajarish uchun (@link #start) dan foydalaning. */ public void waitForIdleSync() ( validateNotAppThread(); Idler idler = new Idler(null); mMessageQueue.addIdleHandler(idler); mThread.getHandler().post(yangi EmptyRunnable()); idler()For );
Uni ishlatish, biz boshdan kechirganimizdek, Ko'rish topilmasligi bilan bog'liq ko'p muammolarni hal qiladi, garchi skrinshotlar hamma narsa ko'rsatilishini ko'rsatadi, shuningdek, Ko'rinish oraliq holatda bo'lib, uning xususiyatlarini bir qiymatdan ikkinchisiga jonlantiradi va hokazo.

Tabiiyki, espresso haqidagi hikoyalar bizni ko'p marta yaxshi ta'qib qildi. Ushbu ramkaga o'tish rejasi uzoq vaqt davomida pishgan; Bundan tashqari, Google hozirda avtomatlashtirilgan testlar masalasiga katta e'tibor qaratmoqda, shuning uchun Espresso yanada faol rivojlanishi uchun zarur shartlar mavjud. Robotium-dan Espresso-ga o'tish uchun TestRunner-ni o'zgartirish kifoya, degan asosiy ishlab chiquvchining ishonchi ham aniqlandi. Biz buni sinab ko'rdik va testlar aslida ishladi. Endi biz bir vaqtning o'zida eski testlarni o'zgartirmasdan yangi skriptlarni yozishimiz va Espressoning barcha afzalliklaridan foydalanishimiz mumkin. Biz uchun bu yangi ramkaga o'tishni belgilab berdi. Biz sinovlarni boshladik va natijalarni kutib qotib qoldik.

Espresso haqiqatan ham tezroq edi, garchi dramatik o'zgarishlar bo'lmasa ham. Endi bizning barcha testlarimiz ~ 26 paketga bo'lingan va har birida tezlashuv kuzatildi. Ammo testlardan o'tish tezligidagi umumiy o'zgarishlar 4% ga to'g'ri keladi. Menimcha, bu muhim afzallik emas. Ko'p narsa, mening nuqtai nazarimga ko'ra, dasturdagi har qanday kutish uchun waitForIdleSync analogini yozish imkonini beradi: nafaqat interfeys va animatsiya vazifalari uchun, balki tarmoqdan va diskdan ma'lumotlarni yuklash vazifalari uchun - har qanday shovqinlar uchun Natijada test kodini tekshirish orqali ishlashimiz kerak. Bu xususiyat CustomIdlingResource deb ataladi va u haqiqatan ham Espressoni Robotium bilan solishtirganda ajralib turadi. G'oya juda oddiy bo'lishiga qaramay, ya'ni bo'sh holatni kutish interfeysini o'zingiz amalga oshirishni ro'yxatdan o'tkazish imkoniyatini taqdim etish, maxsus bo'sh turgan resurs testlar va dastur o'rtasidagi sinxronizatsiyani boshqarishga imkon beradi. Shu tarzda, siz ilovada barcha asinxron operatsiyalar tugashini kutishingiz mumkin, masalan, bu asosiy ish zarrachasining bo'sh holati bilan birga kutish tugallanishi va dastur holatini tekshirish boshlanishi mumkinligini ko'rsatadi.

Tabiiyki, espresso peri jin emas. U barcha muammolaringizni hal qila olmaydi, siz uchun testlar yoza olmaydi va test infratuzilmasini saqlash, testlarni o'tkazish va hisobotlarni yig'ish vazifalarini bajara olmaydi.

Ilova ichidagi haqiqiy funksionallikni sinab ko'rishdan tashqari, avtomatlashtirilgan sifat sinovi kontekstida duch keladigan keng tarqalgan muammo bu sizning mahsulotingiz foydalanuvchining telefoniga o'rnatilishi mumkin bo'lgan boshqa ilovalar bilan qanday o'zaro aloqada bo'lishidir. Misol sifatida, masalan, boshqa ilovadan almashish (bu elektron pochta mijozi uchun juda mos) yoki bildirishnomaning holat panelini olishingiz mumkin. Ikkala holatda ham skript boshqa jarayonda ishlaydigan boshqa dasturga ta'sir qiladi. Robotium/Espresso-ga o'xshash barcha ramkalar boshqa jarayon ishtirok etishi bilanoq ko'r bo'lib qoladi. Yaxshiyamki, ilovalar o'rtasida funktsional UI testlarini yozish imkonini beruvchi yechim allaqachon mavjud va UI Automator deb ataladi. Agar ilgari biz u yoki bu ramka o'rtasida tanlov qilishimiz yoki har biri turli tekshirishlar uchun mo'ljallangan turli loyihalarni qo'llab-quvvatlashimiz kerak bo'lgan bo'lsa, so'nggi Google I/O 2015 konferentsiyasida e'lon qilingan Testni qo'llab-quvvatlash kutubxonasi chiqarilishi bilan biz har bir yondashuvning afzalliklarini birlashtirib, har bir alohida holatda talab qilinadigan vositalardan foydalanishi mumkin. Bu shuni anglatadiki, masalan, elektron pochta mijozi uchun biz quyidagi skriptni avtomatlashtirishimiz mumkin:

  1. Ilovani ishga tushiring, harflar ro'yxatiga o'ting.
  2. Yangi xat yozishni oching, mavzuni, qabul qiluvchini, qo'shimchalarni kiriting.
  3. Ulangan pochta qutingizga push-bildirishnoma oling.
  4. Bildirishnomaga o'ting va yangi xatning mazmunini tekshiring.
  5. Orqaga tugmasi yordamida yangi harf ekranidan chiqing, biz xat yozish ekraniga qaytdik va barcha to'ldirilgan maydonlar saqlanganligiga ishonch hosil qiling.
Ushbu misolda biz oldingi ramkadan harflar ro'yxati modellari bo'ylab harakatlanish, xatni o'qish, yangi xat yozish va hokazolar uchun xavfsiz foydalanishimiz mumkin va 3 va 4-bosqichlarda biz bildirishnomani tekshirish uchun uiAutomator ramkasidan foydalanishimiz mumkin. matn, bildirishnomada kerakli tugmalar mavjudligiga ishonch hosil qiling va ilovaga bildirishnomaga amal qiling. Keyin test Espresso API-dan foydalanishni davom ettiradi va biz ikkinchi ramka uchun mavjud modellarning boshqa ilovasini yozishimiz shart emas. Ishlab chiquvchi sifatida men uchun bu sinovlarni avtomatlashtirish kutubxonalari kontekstida paydo bo'lishi mumkin bo'lgan eng yaxshi yangilik.

Albatta, bularning barchasi birinchi qarashda oddiy ko'rinadi. Sahna orqasida bir nechta to'plangan tırmıklar va eng yoqimsiz moddalarga kirishish bor edi - ba'zida bu butun g'oyani amalga oshirib bo'lmaydiganga o'xshardi.

Kelajakda biz infratuzilma qanday qurilganligi, qurilmalarning kun bo'yi ishlashga tayyor bo'lishi qanday ta'minlanganligi, turli xil mahsulot lazzatlari uchun sinovlar turli yig'ilishlar bo'ylab qanday taqsimlanishi, turli xil ilovalar versiyasiga qarab qanday sinovdan o'tkazilishi haqida alohida gaplashamiz. operatsion tizim, qurilma forma faktori va boshqalar. Axir, bizda adb, usb, VirtualBox va boshqa ko'plab vositalar va texnologiyalar bilan ikki yil davomida kurash bor. Oldinda amalga oshirilgan ishlardan ko'ra ko'proq ish bor, ammo bularning barchasi behuda emasligini tushunamiz.

Biz ushbu kursni "1C 8.3 da mobil ilovalarni ishlab chiqish" kursi bilan to'liq sotib olishni tavsiya qilamiz.

Ikkinchi kursda biz mobil ilovalarning monetizatsiyasini, shuningdek, ularni ishlab chiqishda nimalarga oldindan e'tibor berish kerakligini batafsil ko'rib chiqamiz.

Savatingizga ikkinchi kursni qo'shish imkoniyati Buyurtmani kiritish shaklida paydo bo'ladi - "Buyurtma bering!".

Kafolat

Biz 2008 yildan beri dars beramiz, biz o'z kurslarimiz sifatiga ishonamiz va o'zimizni beramiz standart 60 kunlik kafolat.

Bu shuni anglatadiki, agar siz bizning kursimizga o'tishni boshlagan bo'lsangiz, lekin birdan fikringizni o'zgartirsangiz (yoki, aytaylik, imkoniyatingiz bo'lmasa), unda sizda qaror qabul qilish uchun 60 kunlik muddat bor - va agar siz qaytib kelsangiz, biz 100 ni qaytaramiz. to'lovning %.

Bo'lib-bo'lib to'lash

Bizning kurslarimizni bo‘lib-bo‘lib yoki bo‘lib-bo‘lib, shu jumladan foizsiz to‘lash mumkin. Qayerda Siz darhol materiallarga kirishingiz mumkin.

Bu jismoniy shaxslardan 3000 rubl yoki undan ortiq miqdorda to'lovlar bilan mumkin. 150 000 rublgacha.

Buning uchun “Yandeks.Checkout orqali to‘lov” to‘lov usulini tanlash kifoya. Keyin, to'lov tizimining veb-saytida "Bo'lib-bo'lib to'lash" -ni tanlang, to'lovlar muddati va miqdorini ko'rsating, qisqa shaklni to'ldiring - va bir necha daqiqadan so'ng siz qaror qabul qilasiz.

To'lov imkoniyatlari

Biz barcha asosiy toʻlov shakllarini qabul qilamiz.

Jismoniy shaxslardan- kartalardan to'lovlar, elektron pullar bilan to'lovlar (WebMoney, YandexMoney), Internet-banking orqali to'lovlar, aloqa do'konlari orqali to'lovlar va boshqalar. Buyurtmani bo‘lib-bo‘lib (bo‘lib-bo‘lib), shu jumladan, qo‘shimcha foizlarsiz to‘lash ham mumkin.

Buyurtma berishni boshlang - ikkinchi bosqichda siz o'zingiz yoqtirgan to'lov usulini tanlashingiz mumkin.

Tashkilotlar va yakka tartibdagi tadbirkorlardan– naqd pulsiz to‘lov, yetkazib berish hujjatlari taqdim etiladi. Siz buyurtmani kiritasiz va darhol to'lov uchun hisob-fakturani chop etishingiz mumkin.

Bir nechta xodimlarni o'qitish

Bizning kurslarimiz individual ta'lim uchun mo'ljallangan. Bir to'plamda guruh mashg'ulotlari noqonuniy tarqatish hisoblanadi.

Agar kompaniya bir nechta xodimlarni o'qitishi kerak bo'lsa, biz odatda 40% arzonroq bo'lgan "qo'shimcha to'plamlarni" taklif qilamiz.

"Qo'shimcha to'plam" ga buyurtma berish uchun shaklda 2 yoki undan ortiq kurs to'plamini tanlang, ikkinchi to'plamdan boshlab kurs narxi 40% arzon bo'ladi.

Qo'shimcha to'plamlardan foydalanish uchun uchta shart mavjud:

  • Agar kamida bitta oddiy to'plam ilgari (yoki u bilan birga) sotib olinmagan bo'lsa, faqat qo'shimcha to'plamni sotib olmaysiz.
  • Qo'shimcha to'plamlar uchun boshqa chegirmalar yo'q (ular allaqachon chegirmali, bu "chegirmaga chegirma" bo'ladi)
  • aktsiyalar xuddi shu sababga ko'ra qo'shimcha to'plamlar uchun (masalan, 7000 rubl kompensatsiya) amal qilmaydi.

Qandaydir tarzda jimgina va ishning maxsus tavsiflarisiz 1C mobil ilovalarni ishlab chiqish uchun o'ziga xos tashkilotchi bo'lishga mo'ljallangan "Mobil ilovalar kollektori" konfiguratsiyasini chiqardi.

Joriy so'nggi 1.0.3.17 versiyasida bir qarashda xatolik kabi ko'rinadigan bir nechta kichik muammolar mavjud.

Biz duch keladigan birinchi muammo - bu foydalanuvchisiz konfiguratsiyani ishga tushirishning mumkin emasligi, biz quyidagi xatoni olamiz:

“Konfiguratsiya versiyasi infobase versiyasidan farq qiladi. Ilova yechimini Administrator huquqlariga ega foydalanuvchi sifatida ishga tushirish orqali konfiguratsiyani yangilash kerak

Bu muammoni juda oddiy hal qilish mumkin, siz shunchaki konfiguratorni ishga tushirishingiz va "Administrator" huquqlariga ega foydalanuvchini qo'shishingiz kerak.

Ikkinchi muammo "Mobil konfiguratsiyalar" katalogida element yaratishga harakat qilganda paydo bo'ladi. Biz "Yaratish" tugmasini bosamiz va "Elementlarni faqat guruhlarda yaratish mumkin" xatosini olamiz:

Muammo yo'q, biz "Guruh yaratish" tugmasini bosamiz va to'satdan yana "Elementlarni faqat guruhlarda yaratish mumkin" xato xabarini olamiz.

Yechim quyidagi amallarni bajarishdir:

Yuqori panelda pastki menyuni ochadigan "Yaratish" tugmasi mavjud. Unda "Mobil konfiguratsiya" bandini bosing:

Shundan so'ng, siz guruhlar yaratishingiz mumkin bo'lgan juda do'stona oyna ochiladi:

"Mobil ilovalar" katalogini yaratishda ham muammo bor, biz quyidagi xato xabarini olamiz:

"Ilova identifikatori prefiksi provayder sozlamalarida o'rnatilmagan":

Chiqish ham juda yaqin:

Va biz "Mobil yechim provayderlari" katalog elementiga ma'lumotlarni kiritishni boshlaymiz.

Prefiks ichida "nuqta" bo'lishi kerak. Va "Ishlab chiquvchi kalitini yaratish" tugmasini bosing.

Agar xatolikni sezsangiz, matn qismini tanlang va Ctrl+Enter tugmalarini bosing
ULOSING: