488 Частина IV. Ajax у прикладах

і викликає сервер, який динамічно створить відповідні дані, ґрунтуючись на відправленому значенні рядка запиту. Першим параметром функції LoaciXMLXSLTDoc () є URL сторінки РНР, яка генерує XML-документ, об'єднаний з рядком запиту, сформованим посиланням на значення поля HTML-форми О. Другий параметр - це ім'я XSLTфайла ©, що використовується в перетворенні XML-даних. Третій параметр, необхідний функцією LoadXMLXSLTDoc(), є ідентифікатором елемента div, в який слід поміщати результати пошуку. Ідентифікатор – це рядкове ім'я вихідного елемента, а не посилання на об'єкт; у разі як ідентифікатора використовується рядок "results" .

На наступному етапі ми за допомогою методів DOM додаємо на Web-сторінку зображення-індикатор. Створюється елемент зображення © та встановлюється атрибут джерела зображення О. Цей створений елемент додається до елемента div із результатами ©. Таким чином, коли наша функція викликається з оброблювача подій абооб'єднує форми, на сторінку міститься файл зображення. Взагалі, для користувача важливо створити візуальну Зворотній зв'язок- повідомлення або зображення, - що вказує на те, що обробка знаходиться в процесі. Завдяки цьому користувач не повторно клацатиме на кнопці відправки фори, думаючи, що нічого не відбувається (пам'ятаєте, процес Ajax - "непомітний").

Останній етап - це виклик функції LoadXMLXSLTDoc()®, що ініціює процес відправлення інформації на сервер. Функція LoadXMLXSLTDoc (), описана в розділі 12.4, обробляє виклик об'єкта ContentLoader (), який запитує документи із сервера. Задаючи як параметр вихідне положення (а не кодуючи значення жорстко у функції LoadXMLXSLTDoc ()), ми можемо багаторазово використовувати цю функціюна одній сторінці, не вимагаючи поділу функціональних можливостейдодавання безлічі процедур або операторів if. Отже, ми перенаправляємо результати різних пошукових запитіврізні частини сторінки. Однак, перш ніж ми це зробимо, давайте подивимося, як створити на сервері документи XML і XSLT.

12.3. Код серверної частини програми: РНР

В даному розділі ми створимо для проекту динамічний XML-документ, використовуючи РНР – популярна мова підготовки сценаріїв з відкритим вихідним кодом (як ви знаєте, інфраструктура Ajax сумісна з будь-якою серверною мовою чи платформою). XML-документ генерується динамічно за набором результатів, отриманим у відповідь запит клієнта до бази даних. Крім того, ми покажемо, як створити статичний документ XSLT, який розташований на сервері і виймається щоразу, коли запитується динамічний файл. Обидва вказані документи повертаються клієнту незалежно, коли об'єкт ContentLoader запитується у двох окремих запитах (листинг 12.7). XSLT-код перетворює наш динамічний XML-документ на стороні клієнта та створює HTML-таблицю, яка відображається користувачеві.

Розділ 12 "Живий" пошук з використанням XSLT 489

12.3.1. Створення XML-документу

Оскільки ми використовуємо XSLT, нам потрібен структурований XMLдокумент, що є простим записом інформації, щоб XSLфайл міг виконати стандартне перетворення. У цьому проекті ми створимо динамічний XML-файл, коли клієнт потребує файлу РНР.

Розробка XML-структури

Перш ніж ми розпочнемо створення XML-файлу, необхідно створити шаблон для нього. Цей шаблон повинен відображати структуру даних, що повертаються під час пошуку. У вибраному формулюванні завдання (телефонна книга) ми повертатимемо назву компанії, ім'я контактної особи, країну та телефонний номер. У лістингу 12.3 показаний базовий XML-шаблон, що містить чотири поля.

Лістинг 12.3. Базовий файл XML

Company Name Contact Name Country Name Phone Number

Першим елементом є phonebook. Наступний - елемент entry, що містить поделементи з усіма деталями, пов'язані з усіма контактними телефонами, знайденими у запиті. Якщо ми маємо п'ять результатів, у XML-документі буде п'ять елементів entry. Ім'я компанії відображається в елементі компанії. Крім того, ми додали ім'я контактної особи, назву країни та номер телефону. Ми не обмежені лише вказаними полями; залежно від того, яку інформацію необхідно відобразити, поля можна додавати та видаляти.

Якщо результати не знайдені, замість відображення попереджувального повідомлення можна створити елемент, який відображає цю інформацію для користувача. STO полегшить нам завдання повернення результату користувачеві і не вимагатиме додаткового кодуу клієнтській частині програми. Код, наведений у лістингу 12.4, практично не відрізняється від коду з лістингу 12.3, але цього разу ми вводимо текст до елементів XML, які бажаємо показати користувачеві, щоб повідомити, що результатів не знайдено.

Лістинг 12.4. Файл XML без результатів

No Results

// Про Замість імені компанії відображається "No R e s u l t s" N/A

490 Частина IV. Ajaxв прикладах

// © Замість поля, що залишилися, відображається "N/A"

N/A

N/A

За допомогою цього коду ми відображаємо користувачеві єдиний рядок, що повідомляє, що потрібна інформація відсутня. У дескрипторі company Про відображається інформація, що повідомляє, що результатів немає. В інших дескрипторах 0 користувачеві повідомляється, що інформації немає. Якщо ми не бажаємо відображати текст "N/A" ("не доступно"), можна додати замість нього нерозривний пробіл, що дозволить показати осередки таблиці. Якби ми не додали взагалі жодної інформації, осередки у таблиці не з'явилися б.

Як бачите, формат XML має дуже просту структуру. Якщо цей XML-файл був статичним, користувачеві було б відносно просто додати у файл нового абонента. Оскільки він створюється динамічно, нам знадобиться цикл, який створює XML-документ з набору результатів.

Створення динамічного XML-документу

Як завжди ми створюємо XML-документ на сервері. Дотримуючись політики використання прикладах різних серверних мов, серверний код дайної глави написаний на РНР. Ще раз нагадаємо, що інфраструктуру Ajax можна створити за допомогою будь-якої серверної мови, і ми будемо описувати лише сам принцип реалізації серверного коду, не вдаючись до деталей. Отже, у лістингу 12.5 показаний код серверної частини програми. Код отримує параметр рядка запиту та генерує безліч результатів запиту бази даних. Потім ми проходимо по безлічі результатів, створюючи в XML-файлі згідно з наведеним у лістингу 12.4 шаблон елемент для кожного номера телефону, отриманого у відповідь на запит.

Лістинг 12.5. Сценарій phoneXML.php: генерація XML-документа на сервері

// Про Оголошення типу MIME header("Content-type: text/xml"); echo("\n");

// © З'єднатися з базою даних

$db = mysql__connect ("localhost", "ajax", "action"); rnysql_select_db("ajax", $db);

$result = mysql_query("SELECT *

FROM Contacts WHERE ContactName як "%". // © Заповнити запит

$_GET["q"] ."%"",$db); ?>

// Про Перевірити результати

if ($myrow = mysgl_fetch_array($result)) ( do (

// © Пройти по безлічі результатів

Розділ 12. "Живий" пошук з використанням XSLT 491

001">

)while ($ myrow - mysql_fetch_array ($ result)); )else(

телефонної книгиабо видаємо повідомлення "No Results" 0.

12.3.2. Створення документа XSLT

Використовуючи XSLT, наш XML-файл за допомогою пари рядків коду можна перетворити на красиву таблицю HTML. XSLT-документ дозволяє зіставлення з шаблоном, якщо воно потрібне для відображення даних у будь-якому потрібному форматі. У порівнянні з шаблоном для відображення даних застосовується структура-шаблон. При цьому ми проходимо по вузлах дерева.

492 Частина IV. Ajax у прикладах

джерела, використовуючи XSLT. XSLT-документ приймає структурований XML-файл і перетворює його на формат, який зручний для перегляду, оновлення та зміни. У нашому випадку XSLT-документ визначається статично.

Структура XSLT

XSLT-перетворення містить правила для перекладу вихідного дерева на кінцеве. Весь XSLT-процес полягає у зіставленні зі структурою шаблоном. Коли елементи вихідного дерева відповідають заданій структурі, згідно шаблону документа створюється кінцеве дерево.

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

XSLT-перетворення називається таблицею стилів, оскільки вона визначає стильове оформлення кінцевого дерева. Таблиця стилів містить правила шаблону, що з двох частин. Перша частина - це структура шаблон, з якою порівнюються вузли вихідного дерева. Виявивши відповідність, XSLT-процесор використовує другу частину - шаблон, що містить дескриптори для побудови дерева.

Створення XSLT-документу

Сформувати XSLT-перетворення для цього проекту порівняно просто. Оскільки ми збираємося отримати таблицю, ніяке незвичайне зіставлення із шаблоном не буде потрібно; ми просто послідовно пройдемо по всіх вузлах-елементах вихідного дерева. Нижче ми розробимо шаблон, який формує таблицю HTML із чотирма стовпцями. Відповідний XSLT файл для цього проекту показаний у лістингу 12.6.

i Лістинг 12.6. XSLT-файл

"ISO-8859-l"?>

// Про Встановити версію XML та кодування

// © Задати простір імен XSLT"http://www.w3.org/1999/XSL/Transform">

// © Встановити правила шаблону

// Про Додати елемент table

// © Створити рядок заголовка

Розділ 12 "Живий" пошук з використанням XSLT 493

// 0 Послідовно пройти елементами телефонної книги

select="phonebook/entry"> // © Відформатувати вихідні дані

Під час створення XSLT-перетворення необхідно вказати кодування та версію XML О, а також встановити простір імен XSLT ©. Простір імен визначає правила та специфікації, яким має відповідати документ. Елементи у просторі імен XML розпізнаються у вихідному документі, але не розпізнаються у документі результатів. Для визначення всіх наших елементів у просторі імен XSLT застосовується префікс xsl. Далі можна встановити правило шаблону - шукати структуру / ©, яка відповідає всьому документу.

Тепер можна починати створення шаблону таблиці, де відображаються наші результати. Ми додаємо дескриптор table О, який зіставляє з таблицею ідентифікатор. Після цього вводиться рядок заголовка таблиці ©, що містить імена стовпців, що вказують користувачеві, яка інформація міститься в таблиці.

Послідовно проходячи по безлічі вузлів вихідного дерева, ми отримуємо інші рядки таблиці. В даному випадку використовується цикл for-each ©, в процесі обробки записів, що видає вузли, розташовані в phonebook/entry.

Оскільки ми послідовно проходимо дерево документа, необхідно вибрати значення стовпців. Щоб вибрати значення з вузлів, використовується оператор value-of, що витягує значення елемента XML і додає його у вихідний потік перетворення. Щоб задати елемент XML, текст якого ми бажаємо вийняти, використовуємо з іменем елемента select атрибут. Сформувавши XSLT-файл та створивши код для динамічної генерації документа XML, можна завершити створення JavaScript-коду та подивитися, як об'єднання XSLT-перетворення зі структурованим XML-файлом дозволяє отримати зручну для перегляду таблицю.

На наступному етапі ми знову повертаємось на бік клієнта, який витягує файли, створені щойно за допомогою НТТР-відгуку.

Розробка серверної частини клієнт- серверної програмипочинається із проектування архітектури. Від архітектури залежить багато чого: починаючи від розширюваності програми і закінчуючи його продуктивністю та зручністю підтримки/супроводу.

Насамперед слід визначити, як будуть розміщені дані на сервері та як будуть оброблятися запити, що надходять з боку клієнта. Також необхідно продумати організацію серверного кешування даних.

Необхідно визначитися з протоколами обміну даними та форматами передачі даних.

API (application programming interface) – інтерфейс прикладного програмування. Якщо виражатися більш зрозумілою мовою, це набір запитів до серверу, який останній розуміє і може дати коректну відповідь. API визначає функціональність серверної логіки, при цьому API дозволяє абстрагуватися від того, як ця функціональність реалізована. Іншими словами, API – це потрібна частина загальної клієнт-серверної інфраструктури.

Порівняти JSON та XML. Навести приклад протоколу залежно від типу програми.

Багатопоточність

Одним із ключових аспектів у сучасному програмуванні є багатопоточність. За допомогою багатопоточності ми можемо виділити у додатку кілька потоків, які виконуватимуть різні завдання одночасно.

Багатопоточність – властивість платформи (наприклад, операційної системи, віртуальної машиниі т. д.) або програми, що полягає в тому, що процес, породжений в операційній системі, може складатися з декількох потоків, що виконуються «паралельно», тобто без вказаного порядку в часі.

Сутью багатопоточності є квазимного завдання на рівні одного виконуваного процесу, тобто всі потоки виконуються в адресному просторі процесу. Окрім цього, всі потоки процесу мають не лише спільний адресний простір, а й спільні дескриптори файлів. Процес, що виконується, має як мінімум один (головний) потік.

Багатопоточність (як доктрину програмування) не слід плутати ні з багатозадачністю, ні з багатопроцесорністю, незважаючи на те, що операційні системи, що реалізують багатозадачність, як правило, реалізують багатопоточність.

До переваг багатопоточності в програмуванні можна віднести наступне:

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

Найменші щодо процесу тимчасові витрати на створення потоку.

Підвищення продуктивності процесу рахунок розпаралелювання процесорних обчислень та операцій вводу-вывода.

Потік(threаd) – це керована одиниця виконуваного коду. У багатозадачному середовищі, заснованої на потоках, у всіх працюючих процесів обов'язково є основний потік, але їх може бути більше. Це означає, що в одній програмі може виконуватися кілька завдань асинхронно. Наприклад, редагування тексту в текстовому редакторіпід час друку, тому ці завдання виконуються в різних потоках.

На звичайному процесорі керування потоками здійснюється операційною системою. Потік виконується доти, доки не відбудеться апаратне переривання, системний викликабо поки не закінчиться відведений для нього операційною системою час. Після цього процесор перемикається на код операційної системи, який зберігає стан потоку (його контекст) або перемикається на стан іншого потоку, якому теж виділяється час виконання. За такої багатопоточності достатньо велика кількістьтактів процесора витрачається на код операційної системи, що перемикає контексти. Якщо підтримку потоків реалізувати апаратно, процесор сам зможе перемикатися між потоками, а в ідеальному випадку - виконувати кілька потоків одночасно за кожен такт.

– Тимчасова багатопоточність (один потік)

– Одночасна багатопоточність (кілька потоків одночасно)

Багатопотоковість, як широко поширена модель програмування та виконання коду, дозволяє кільком потокам виконуватися в рамках одного процесу. Ці потоки виконання спільно використовують ресурси процесу, але можуть працювати самостійно. Багатопотокова модель програмування надає розробникам зручну абстракцію паралельного виконання. Однак, мабуть, найбільш цікаве застосування технології є в тому випадку, коли вона застосовується до одного процесу, що дозволяє паралельне його виконання на багатопроцесорній системі.

Ця перевага багатопотокової програми дозволяє їй працювати швидше на комп'ютерні системи, які мають кілька процесорів, процесор з кількома ядрами або на кластері машин - через те, що потоки виконання програм природно піддаються дійсно паралельному виконанню процесів. У цьому випадку програмісту потрібно бути дуже обережним, щоб уникнути стану гонки та іншої неінтуїтивної поведінки. Щоб правильно маніпулювати даними, потоки виконання повинні часто проходити через процедуру рандеву, щоб обробляти дані в правильному порядку. Потокам виконання можуть також знадобитися м'ютекси (які часто реалізуються з використанням семафорів), щоб запобігти одночасній зміні загальних даних або їх читання під час процесу зміни. Необережне використання таких примітивів може призвести до тупикової ситуації.

Іншим використанням багатопоточності, що застосовується навіть для однопроцесорних систем, є можливість застосування реагування на введення даних. В однопотокових програмах, якщо основний потік виконання заблокований виконанням тривалого завдання, вся програма може опинитися в замороженому стані. Переміщаючи такі тривалі завдання в робочий потік, який виконується паралельно з основним потоком, стає можливим для додатків продовжувати реагувати на дії користувача під час виконання завдань фоновому режимі. З іншого боку, здебільшого багатопоточність – не єдиний спосіб зберегти чутливість програми. Те саме може бути досягнуто через асинхронне введення-виведення або сигнали в UNIX.

Усього розрізняють два різновиди багатозадачності: на основі процесіві на основі потоків. Відмінності багатозадачності на основі процесів і потоків зводиться до такого: багатозадачність на основі процесів організується для паралельного виконання програм, а багатозадачність на основі потоків – для паралельного виконання окремих частин однієї програми.

Усього розрізняють два типи потоків:

Потоки переднього плану (foreground threads) чи пріоритетний. За замовчуванням кожен потік, створюваний через Thread.Start(), автоматично стає потоком переднього плану. Цей типпотоків забезпечують захист поточної програми від завершення. Середовище CLR не зупинить програму, доки не будуть завершені всі пріоритетні потоки.

Фонові потоки (background threads). Цей видпотоків називається також потоками-демонами, сприймаються середовищем CLR як розширювані шляхи виконання, які у час можуть ігноруватися. Таким чином, якщо всі потоки переднього плану припиняються, всі фонові потоки автоматично знищуються при вивантаженні домену програми. Для створення фонових потоків необхідно надати властивості IsBackground значення true.

Розповісти про стани потоків: занедбаний, призупинений, занедбаний, але чекає чогось.

Проблема синхронізації потоків та загальні ресурси.

Взаємодія потоків

У багатопотоковому середовищі часто виникають проблеми, пов'язані з використанням паралельно виконуваними потоками одних і тих же даних або пристроїв. Для вирішення подібних проблем використовуються такі методи взаємодії потоків, як м'ютекси, семафори, критичні секції та події

М'ютекс– це об'єкт синхронізації, який встановлюється в особливий сигнальний стан, коли не зайнятий потоком. Тільки один потік володіє цим об'єктом у будь-який момент часу, звідси і назва таких об'єктів (від англійського mutually exclusive access - взаємно виключає доступ) - одночасний доступ до загального ресурсу виключається. Після всіх необхідних дій м'ютек звільняється, надаючи іншим потокам доступ до спільного ресурсу. Об'єкт може підтримувати рекурсивне захоплення другий раз тим самим потоком, збільшуючи лічильник, не блокуючи потік, і вимагаючи потім багаторазового звільнення. Така, наприклад, критична секція Win32. Проте є й такі реалізації, які не підтримують таке і призводять до взаємного блокування потоку при спробі рекурсивного захоплення. Це FAST_MUTEX у ядрі Windows.

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

Події. Об'єкт, що містить у собі 1 біт інформації «просигналізований чи ні», з якого визначені операції «просигналізувати», «скинути у непросигналізований стан» і «очекувати». Очікування на просигналізованій події є відсутність операції з негайним продовженням виконання потоку. Очікування на непросигнализированном події призводить до призупинення виконання потоку до тих пір, поки інший потік (або друга фаза обробника переривання в ядрі ОС) не просигналізує подія. Можливе очікування кількох подій в режимах будь-якого або всіх. Можливе також створення події, що автоматично скидається в непросигналізований стан після пробудження першого ж – і єдиного – очікуваного потоку (такий об'єкт використовується як основа для реалізації об'єкта «критична секція»). Активно використовуються в MS Windows як у режимі користувача, так і в режимі ядра. Аналогічний об'єкт є в ядрі Linux під назвою kwait_queue.

Критичні секціїзабезпечують синхронізацію подібно до мьютексам, за винятком того, що об'єкти, що представляють критичні секції, доступні в межах одного процесу. Події, мьютекси і семафори також можна використовувати в однопроцессному додатку, проте реалізації критичних секцій в деяких ОС (наприклад, Windows NT) забезпечують швидший і ефективніший механізм взаємно-виключної синхронізації – операції «отримати» та «звільнити» на критичній секції оптимізовані для випадку єдиного потоку (відсутності конкуренції) з метою уникнути будь-яких провідних в ядро ​​ОС системних викликів. Подібно до м'ютексу об'єкт, що представляє критичну секцію, може використовуватися тільки одним потоком в даний момент часу, що робить їх вкрай корисними при розмежуванні доступу до загальних ресурсів.

Умовні змінні(Condvars). Схожі з подіями, але не є об'єктами, що займають пам'ять – використовується тільки адреса змінної, поняття «вміст змінної» не існує, як умовна змінна може використовуватися адреса довільного об'єкта. На відміну від подій, встановлення умовної змінної в просигналізований стан не тягне за собою жодних наслідків у разі, якщо на даний момент немає потоків, що очікують змінної. Установка події в аналогічному випадку тягне за собою запам'ятовування стану «просигналізовано» всередині самої події, після чого наступні потоки, що бажають очікувати на події, продовжують виконання негайно без зупинки. Для повноцінного використання такого об'єкта необхідна також операція «звільнити mutex і чекати на умовну змінну атомарно». Активно використовуються в UNIX-подібних ОС. Дискусії про переваги та недоліки подій та умовних змінних є помітною частиною дискусій про переваги та недоліки Windowsта UNIX.

Порт завершення введення-виводу(IO completion port, IOCP). Реалізований в ядрі ОС і доступний через системні виклики об'єкт «черг» з операціями «помістити структуру у хвіст черги» та «взяти наступну структуру з голови черги» - останній виклик призупиняє виконання потоку у разі, якщо черга порожня, і доти, доки інший потік не здійснить виклик "помістити". Найважливішою особливістю IOCP є те, що структури в нього можуть бути не тільки явним системним викликом з режиму користувача, але й неявно всередині ядра ОС як результат завершення асинхронної операції введення-виводу на одному з дескрипторів файлів. Для досягнення такого ефекту необхідно використати системний виклик "зв'язати дескриптор файлу з IOCP". У цьому випадку вміщена в чергу структура містить код помилки операції введення-виводу, а також, для випадку успіху цієї операції - число реально введених або виведених байт. Реалізація порту завершення також обмежує кількість потоків, що виконуються одному процесорі/ядрі після отримання структури з черги. Об'єкт специфічний для MS Windows, та дозволяє обробку вхідних запитів з'єднання та порцій даних у серверному програмне забезпеченняв архітектурі, де кількість потоків може бути меншою за кількість клієнтів (немає вимоги створювати окремий потік з витратами ресурсів на нього для кожного нового клієнта).

Пул потоків

Розповісти про пул потоків

Розробка серверної частини програми

Вступ

Присутність в інтернеті стала потребою для сучасних компаній. Без цього неможливо побудувати повноцінну взаємодію з клієнтами. Часто для вирішення подібного завдання вдаються до створення клієнт-серверних програм. Кожне з них складається з клієнтської частини та Back-end. Під останнім терміном мається на увазі серверна частинапрограми. Якщо надалі потрібно самостійно змінювати контент мобільної програми, то Back-end має бути створено особливо якісно. Компанія Appomart гарантує виконання поставлених завдань відповідно до вимог. Тому, замовляючи створення серверних програм, можете бути впевнені в належному результаті.

Навіщо потрібен Back-end?

Розробка клієнт-серверних додатків передбачає створення двох елементів. Перший, Front-end, приймає запити від користувачів. Вона видно з екранів мобільних пристроївклієнтів. Друга, серверна програма, обробляє отримані запити, виконує роль адміністративної панелі. Тут зберігаються бази даних, логіка програми. Без цього не буде працювати жодне клієнт-серверний додаток. По суті Back-end – це серце програми. Це інтелект, який відповідає за обробку запитів клієнтів, швидкість роботи програми. Тому важливо, щоб архітектура серверної програми була продумана до дрібниць, щоб навіть високонавантажені сервіси працювали безперебійно та швидко.

Як вибрати мову програмування?

У ході підготовки технічного завдання(Частини робочої документації за проектом), архітектор проектує систему баз даних і зв'язків, описує об'єкти та їх властивості, а також розробляє необхідні методи сервера (запити, якими будуть "користуватися" мобільні додатки звертаючись до сервера).

Важливість документації та "кинуті" проекти

В Appomart досить часто звертаються замовники, яких "кинули" з тих чи інших причин інші підрядники. І ми беремо чужий, часом навіть некоректно працюючий проект, здійснюємо його аудит та подальше доопрацювання та підтримку. У процесі вивчення вихідного кодуі матеріалів, отриманих від замовника, ми стикаємося з тим, що багато розробників навмисно не документують методи сервера, щоб прив'язати до себе клієнта, за рахунок незрівнянності трудовитрат передачі проекту на підтримку іншому розробнику, через відсутність документації до серверної частини, а іноді просто з- через непрофесіоналізм. Цей факт, на жаль, є не лише сумним, а й поширеним. Замовнику, у цьому випадку, необхідно оплачувати розробку документації за існуючим проектом, а також аудит вихідного коду, перш ніж можна буде судити про працездатність, зручність та доцільність підтримки проекту. Співробітники Appomart завжди ведуть електронну документацію методів серверної частини у форматі, підтримуваному Postman та Swagger, для подальшого використання.

Як перевірити підрядника до підписання договору?

Ми закликаємо Вас уважно вибирати підрядника, і орієнтуватися не тільки на привабливу ціну, але й на перелік документів, які ви отримаєте разом з проектом, а також умови передачі вихідного коду, та покриття коду коментарями, схеми баз даних (будь то Mongo DB чи MySQL ). Запорукою успіху, як правило, стає грамотна робоча документація, яка явно вказує на вимоги до переданої Вам по завершенню кожного з етапів роботи матеріалів.

Особливості розробки

PHP для серверної частини

Створення серверної частини програм (не плутати з серверами як "залізом" або комп'ютерами, оскільки йдеться про програмну частину) вимагає специфічних професійних навичок та знання мови програмування, яка застосовується на стороні сервера. Якщо розглядати приклади клієнт-серверних додатків, то видно, що користується популярністю PHP. Це безперечний лідер у галузі розробки серверних програм. Цією мовою написано у тій чи іншій конфігурації більше половини сайтів у світі. PHP зручний для розробки та підтримки, і крім того існують спеціальні framework-і для прискорення розробки на PHP.

Framework

Framework ( програмна платформа) - використовується для систематизації та підвищення рівнів абстракції, що дозволяє зробити проект більш гнучким та масштабованим. Однак, варто розуміти, що роботароботи повинна бути обрана коректно, на основі глибинного аналізу робочої документації проекту, без якої неможливо розробити якісний продукт.

Delphi, JAVA, Python

Є інші мови, які використовуються для створення Back-end. Так, поширені створені в середовищі Delphiсерверні програми. З її допомогою програма отримує покращене налагодження, у середовищі також просто сформувати унікальні програми, передбачено візуальне створення, що дає можливість зробити красивий, зрозумілий та зручний інтерфейс. Також популярність набули серверні програми на Java. Такі легко доповнюються, легко виконуються на будь-яких платформах та відрізняються гідним рівнем безпеки. Ще однією популярною мовою вважається Python. Серверні програми з його допомогою створюються швидко, без серйозних витрат.

Поширення

Створення клієнт-серверних додатків має попит у корпоративному середовищі. Часто подібні програмивикористовуються для робочих груп або створення інформаційних системусередині підприємства. Переважна частина мобільних додатківдля підтримки зв'язку з клієнтом також має таку архітектуру. Популярність обумовлена ​​тим, що використання можливостей сервера дозволяє забезпечити контроль та цілісність системи, зменшуючи при цьому навантаження мережі.

Створимо клієнт-серверний додаток Android, iOS якісно та вчасно

Розробка "під ключ"

Програмісти Appomart досвідчені та кваліфіковані, щоб реалізувати завдання найрізноманітніших рівнів. Ми однаково добре реалізуємо соціальні мережі, високонавантажені бізнес-проекти або програмну частину для невеликих стартапів. При необхідності ми створимо клієнтську частину програми під керуванням Android, iOS відповідно до наявних потреб, що висуваються вимогами.

Back-end в Appomart

Наші програмісти працюють з різними технологіями і роблять це однаково добре. В Appomart ви можете замовити клієнт-серверну програму на Java, PHP і Node.JS. Системні вимогианалізуються для кожного із проектів індивідуально, що дозволяє забезпечити оптимальну продуктивність програми. Створимо клієнт-серверну програму Java, PHP і Node.JS з нуля або візьмемо в саппорт існуюче для покращень та оновлень. Якщо Вас цікавить розробка нової серверної частини або підтримка існуючої – залиште заявку, щоб отримати детальний розрахунок вартості робіт та варіантів співробітництва.

Зворотній бік мобільних клієнтів- сервер.

Додаткові вимоги залежать від специфіки:
масштабованість сервера – для SaaS, соціальних додатків, де в ідеалі очікується великий потік відвідувачів, ця умова є обов'язковою. Для бізнес-додатків, де є обмеження за кількістю користувачів або чисельність прогнозується, дана властивість не потрібна;
інтерактивність: ряд додатків потрібно забезпечити механізмом нотифікацій – повідомити додаток (користувач) про настання певних подій, передати повідомлення користувачеві. Ця властивість повинна мати, наприклад, біржову систему або автоматичний диспетчертаксі.
відкрите API: передбачається, що сторонні розробники можуть користуватися функціоналом системи у вигляді документованого протоколу. Адже клієнтом може бути як мобільний, так і зовнішній серверний додаток.
інші вимоги…

Команда

Уважний читач зауважить, що у разі написання серверної програми з графічним інтерфейсом, наприклад, на HTML5 можна заощадити. В цьому випадку не потрібна розробка клієнтських програм - інтерфейс користувача надає браузер. Ця стаття не розглядає такого випадку, йдеться про розробку ”рідних” (native) додатків для мобільних пристроїв.

Мені доводилося працювати в команді з повним складом, але буде реалістами – не завжди людські ресурси та бюджет дозволяє зібрати таку команду. І іноді ролі доводиться поєднувати: менеджер проекту + розробник серверної програми, розробник клієнтської програми + тестувальник.

Технології, інструменти, бібліотеки

Залежно від специфіки системи та вимог до неї використовую один з двох варіантів реалізації протоколу обміну даними.
Коли потрібні кросплатформенність, швидкодія, простота, ефективність, масштабованість, відкрите API, то беру Jersey - реалізацію Web-сервісів REST (RESTful Web services). Ця бібліотека дозволяє використовувати серіалізацію даних у форматі JSON або XML. Конфігурація REST ведеться у вигляді анотацій. Для обміну з мобільними пристроями взято формат JSON через те, що має простішу реалізацію на стороні клієнта (з цієї причини не використовуємо "класичні" Web-сервіси), генерується менший обсяг трафіку. Jersey дозволяє налаштуватися на найбільш відповідний вид JSON.
В іншому випадку, якщо потрібні кросплатформенність, висока швидкодія, простота, ефективність, інтерактивність, то беру
Apache MINA – framework для створення мережевих програм,
Google protobuf – бібліотека кодування та декодування структурованих даних. Структура даних визначається заголовними файлами *.proto, компілятор генерує з них Java класи (також є можливість генерації для інших мов програмування: C++, Objective-C і т. д., що забезпечує властивість кроссплатформенності);
java.util.concurrent – ​​використовуємо стандартний пакет.
Цей варіант може масшабироваться, але цього потрібно закладатися на етапі проектування лише на рівні архітектури, враховуючи бізнес логіку.

Розглянемо гіпотетичну завдання з прикладу вибору технологій для реального SaaS сервісу – “Аукціон послуг “Аукнем” , який дозволяє людям сформувати замовлення виконання необхідних послуг чи робіт, а організаціям своєю чергою залишити їм свої пропозиції. Беремо усі базові вимоги за замовчуванням. Зважаючи на те, що реєстрація в цій системі вільна та безкоштовна, то однозначно до них потрібно додати масштабованість. А що щодо інтерактивності? Було б чудово повідомляти підрядникам (виконавцям) про створення нових замовлень, а замовників інформувати про пропозиції, що надійшли, тієї ж миті в додатку, а не тільки по електронній пошті. На підставі цього візьмемо задля реалізації Apache MINA, Google protobuf. Дивимося таку властивість – відкрите API. Сервіс доступний, тому припустимо, що зовнішні розробники можуть виявити інтерес до інтеграції з ним. Стривайте! Не все так просто. Протокол на базі Apache MINA досить сильно залежить від реалізації та інтеграція без знання нюансів аж ніяк не прозора. У такій ситуації доведеться зважити, який фактор важливіший і зробити вибір.

Висновок