Привіт! Я Лінда Лю, студентка Массачусетського технологічного інституту. Останні три місяці я провів тут, в edX, як стажер із програмної інженерії в команді мобільних пристроїв, під час яких у мене була можливість працювати в діапазоні від серверної частини до розробки iOS і Android. Я хотів би поговорити про два проекти – перший, переробка фреймворку контролю доступу edX, а другий, дослідження фреймворку React та його потенціалу для edX.
Система контролю доступу
Цей проект фактично розпочався як виправлення помилок щодо дат початку курсу для мобільного додатка. Якщо автор курсу не вказує дату початку свого курсу, за замовчуванням буде 1 січня 2030 року. На веб-платформі виконується перевірка, щоб користувач бачив «незаплановано» замість явно помилкової дати. Однак мобільний додаток не виконує еквівалентну перевірку, тому студенти бачили, що курси почалися в 2030 році.
Першим потенційним виправленням, яке спало на думку, було виконання перевірки на стороні сервера в кінцевій точці реєстрації на курс мобільного API, щоб побачити, чи була дата початку за замовчуванням, і API надсилання ніхтозначення в цьому випадку. Це виправлення було приємним, оскільки воно не вимагало змін на стороні клієнта. Однак я виявив, що додатки очікували позначку часу від мобільного API, і вийшли з ладу, коли це очікування було порушено. Таким чином, зміна виключно на стороні сервера не спрацює.
Розмова про потенційні виправлення переросла в обговорення того, як на платформі виконуються перевірки дати початку. Платформа має велика функція, яка називається has_access Для цієї мети. Він приймає користувача, дію та об’єкт і перевіряє, чи має користувач належні дозволи для виконання дії над об’єктом. Наприклад, використання цієї функції полягає в тому, щоб перевірити, чи має студент дозвіл на запис на курс. У той час ця функція просто повертала логічне значення – Правда якщо доступ надано, Помилковий якщо доступ заборонено. Враховуючи, що існує багато причин, чому доступ може бути заборонено, і різні причини можуть викликати різну поведінку, здавалося, що has_access може отримати користь від типу повернення, який містить більше деталей. Потім мобільний API може надіслати результати has_access перевірити клієнта, який потім міг би використати інформацію для відображення відповідного повідомлення.
Наступним кроком було розроблення нового типу повернення. Викликається новий об'єкт AccessResponse. Це об’єкт Python, який містить логічний еквівалент початкового значення has_access повернувся б рядковий код помилки та повідомлення користувача та розробника. Його підкласи представляють помилки, з якими ми зараз хочемо мати справу, а саме StartDateError (якщо для користувача курс не почався), VisibilityError (якщо користувач не має необхідних прав доступу), і MilestoneError (якщо користувач має невиконаний етап). Я реалізував зміни в чотирьох окремих запитах на отримання: по одному для кожного «має_доступ», мобільний API, клієнт Android та клієнт iOS. Хоча ця зміна виходить за межі початкового обсягу виправлення помилок, ця зміна дозволяє перенести перевірку дати початку з боку клієнта на сторону сервера. Як побічний ефект, ця зміна значно полегшує впровадження майбутніх функцій (наприклад, етапів) у мобільному додатку. Завдяки цій роботі я мав змогу торкнутися багатьох фрагментів кодової бази edX, що було справді круто!
React Native для iOS і React.js
Мій наступний проект мав більш дослідницький характер і мав менше конкретних цілей. В edX багато функцій потрібно розробляти тричі – один раз для Інтернету, один раз для iOS і один раз для Android. Для боротьби з цією проблемою існували різноманітні кросплатформні інструменти для мобільної розробки під девізом «напиши один раз, використовуй скрізь», але вони надто намагалися стандартизувати розробку – програми не могли використовувати рідні компоненти платформи, тому вони з’явилися відчуття прославлених мобільних веб-сторінок. Facebook розробив рішення цієї проблеми: фреймворк під назвою React Native який дозволяє розробникам створювати нативні додатки за допомогою React (платформа інтерфейсу користувача для Інтернету).
Рушійною ідеєю React Native є «навчись один раз, пиши будь-де». Це означає, що платформи мають різні структури та стилі, тому розробники повинні писати різні програми для кожної, але з React Native ці програми можна писати з тими самими основними технологіями. Він обіцяє найкраще з обох світів – розробка, яка є ефективною та схожою на різних платформах, але все ще має те гарне рідне відчуття. Нещодавно Facebook відкрив вихідний код версії фреймворку для iOS. Є надія, що React Native (щойно він також буде відкритий для Android) і React.js дозволять розробникам повторно використовувати код і таким чином зменшать роботу, необхідну для розробки для всіх трьох платформ.
XBlocks є хорошим кандидатом для цього проекту, оскільки вони є невеликими модульними частинами, і мобільні програми наразі не мають їх нативних реалізацій. Зокрема, я використовував перетягування XBlock, тому що взаємодії, які він використовує (зокрема рух перетягування), виграють від плавного рендерингу, який обіцяє React. Я почав із простого оцінювання за допомогою перетягування окрема програма для iOS, щоб отримати відчуття розробки за допомогою React Native. React виправдав свою обіцянку – візуалізація була справді плавною, а компоненти та інформацію організовано так, щоб справді мало сенс.
Цей початковий експеримент породив два подальших запитання: як легко можна було б перенести код у оцінку перетягування React.js для браузера? По-друге, наскільки легко можна було б інтегрувати оцінку перетягування з інфраструктурою XBlock, щоб оцінка могла правильно спілкуватися з сервером?
Останні кілька тижнів я працював над відповідями на ці два запитання. Я зробив веб-версію свого додатка для iOS, і хоча не було прямого перекладу коду з iOS на веб (React Native-to-React.js), інформація передається та зберігається таким же чином, і це означало, що багато функцій можна використовувати повторно. Наприклад, усі функції, які обробляють перетягування, вимагали лише кількох невеликих налаштувань. Це багатообіцяюче, тому що це означає, що ми можемо розробляти XBlocks, адаптовані до різних платформ, але при цьому мати можливість повторно використовувати структуру коду.
Я також працював над інтеграцією оцінювання з верстаком XBlock, оскільки це було б важливою частиною його роботи з платформою. Це передбачало модифікацію самого блоку перетягування XBlock, а також впровадження правильних викликів AJAX із компонента React, щоб сервер знав, коли студент відкриває або намагається вирішити проблему. React полегшив здійснення необхідних дзвінків, і тепер у нас є версія React Native і React.js цього XBlock! Я сподіваюся, що edX зробить компоненти React постійною частиною платформи в майбутньому.
Скріншоти React Native Drag and Drop XBlock
Ліве: початковий погляд користувача на проблему. правий: надсилання відгуків через сповіщення iOS.
Резюме
Мені сподобалося, що цього літа я працював над різноманітними проектами з точки зору технологій, які я використовував, і людей, з якими я працював. Я навчився багато конкретних речей, а також отримав навички спілкування, наприклад, як ефективно спілкуватися в команді розробників програмного забезпечення. Це була чудова можливість, і дякуємо всім, хто це зробив! Я хотів би особливо подякувати своїм наставникам Крісу Лі, Аківі Лефферту та Німіші Астагірі, решті мобільної команди та іншим стажерам.
