Лабараторныя прымаюцца на адной з трох моў: беларускай, рускай ці ангельскай. Пры гэтым здача на ангельскай мове будзе станоўча ўплываць на вынік. Адкрыта сказаць пра тое, што беларуская мова будзе таксама падтрымлівацца павышанай адзнакай, у параўнанні з рускай, я не маю права, але ж...
Пры выстаўленні вынікаў здачы будзе ўлічвацца не толькі факт выканання ўмоў лабараторнай. Таксама будзе звяртацца ўвага на арганізацыю вашага рэпазіторыя, якасць коду праекту, ступень ужывання best practices, рэкамендаваных Google пры распрацоўцы, арыгінальнасць рэалізацыі, а таксама ступень аўтаматызацыі працэсаў, якія можна аўтаматызаваць. Таксама будзе звяртацца ўвага на інтэрфейс вашага прадукту. Пры здачы можаце чакаць дадатковыя пытанні па любой з гэтых абласцей. У асноўным яны будуць задавацца дзеля змены вашай адзнакі ў бок больш высокай. Ведаеце — добра. Не — нічога катастрафічнага. Пытанні, якія непасрэдна датычацца заданняў лабараторных і тых рэчэй, якія вы выкарыстоўвалі для іх выканання, лічацца асноўнымі і ў куды большай ступені ўплывыюць на вынік.
У выпадку, калі вам патрэбны дадатковыя каментарыі да заданняў / высвятленне незразумелых момантаў, прапануецца ствараць Issue з пытаннямі ў гэтым рэпазіторыі. Магчыма, вы не адзіны чалавек, каму гэта будзе карысна.
Заданні на лабараторныя наўмысна пішуцца не вельмі дэтальна, каб адчыніць прастору для творчасці і трэнераваць самастойны пошук інфармацыі (у горшым выпадку — SODD (Stack Overflow-driven development)).
- Стварыць рэпазіторый праекту на GitHub. Уся праца з зыходнікамі павінна весціся ў адпаведнасці з GitFlow.
- Стварыць праект, накіраваны на платформу Android 6.0
- Апрацоўка ўсіх runtime-permissions павінна выконвацца ў адпаведнасці з рэкамендацыямі Google.
- Наладзіць версіяніраванне праекту згодна з SEMVER (Semantic Versioning), дзе MAJOR версія — заўсёды 0, MINOR павялічваецца з кожным рэлізам (у нашым выпадку рэлізам будзе лічыцца здача лабараторнай), PATCH — парадкавы нумар каміту пасля апошняга рэлізу. Версія (і назва праекту) павінна адлюстроўвацца у назве APK файлу пры зборцы. (e.g. com.example-0.1.1.apk). Увага: версія праекту павінна генеравацца аўтаматычна, а не мяняцца праграмістам з кожным камітам.
- Рэліз версія APK файлу павінна быць падрыхтаваная да публікацыі на Google Play: файл павінен быць падпісаны пры дапамозе ўласнага сертыфікату. Усе налады гэтага павінны прысутнічаць у праекце, а не ўводзіцца кожны раз праграмістам праз опцыю Build->Generate Signed APK
- Праграма павінна мець на дадзены момант адзіны экран, на якім павінна адлюстоўвацца версія праекту і IMEI тэлефону. (Пры запуску на эмулятары дазваляецца, што IMEI можа быць некарэктным, але пры запуску на рэальным дэвайсе такіх праблем быць не павінна).
- Праграма павінна мець дзве варыяцыі ў межах аднаго праекту (не на розных галінах Git, а адначасова): асноўную версію і версію для распрацоўцы. На дадзены момант паміж імі існуюць наступныя адрозненні: асноўная версія працуе толькі ў партрэтнай арыентацыі (пры павароце тэлефону/планшэту арыентацыя не павінна змяняцца), а версія для распрацоўцы павінна мяняць сваю арыентацыю пры павароце дэвайсу; акрамя таго, версія праекту ў варыяцыі для распрацоўцы павінна дапаўняцца суфіксам
-dev. (e.g. 0.1.1-dev)
- Правесці міграцыю праекту. Замест выкарыстання Android Support Library, праект павінен працаваць з бібліятэкаю AndroidX (https://developer.android.com/jetpack/androidx/).
- Рэалізаваць на галоўнай старонцы праграмы адзін з двух рэкамендаваных патэрнаў навігацыі: Navigation drawer (https://material.io/design/components/navigation-drawer.html) ці Bottom navigation (https://material.io/design/components/bottom-navigation.html). Выкарыстоўваць Navigation Architecture Components library (https://developer.android.com/topic/libraries/architecture/navigation/).
- У арганізаванай сістэме навігацыі дадаць старонку профіля карыстальніка. Зрабіць адэкватны дызайн гэтай старонкі!!! На ёй павінна знаходзіцца наступная інфармацыя: аватар, імя, прозвішча, тэлефон, email адрас. Усе дадзеныя павінны выводзіцца ў TextView. Павінна існаваць кнопка, якая будзе пераводзіць старонку ў рэжым рэдактавання. У гэтым рэжыме карыстальнік мае магчымасць змяніць усе дадзеныя профілю. Рэалізаваць магчымасць зрабіць фотаздымак ці выбраць выяву з галерэі тэлефону і паставіць яе ў якасці аватару карыстальніка. Усе дадзеныя павінны захоўвацца паміж запускамі праграмы.
- Дадаць яшчэ 2-3 пустыя старонкі ў сістэму навігацыі.
- Рэалізаваць магчымасць апынуцца на любой з даданых старонак пры адчыненні URL віду sdapp://by.myapp/page/N, дзе N вызначае нумар старонкі, на якую трапіць карыстальнік. (Тэставаць пры дапамозе каманды ADB
am start -W -a android.intent.action.VIEW -d "sdapp://by.myapp/page/N" by.your.app) - Дадаць у AppBar кнопку, пры націсканні якой будзе адчыняцца новая старонка About, у якую трэба перанесці інфармацыю пра IMEI дэвайса і версію праграмы.
- Дадаць рэгістрацыю і аўтэнтыфікацыю (логін/пароль).
- Карыстальнік не павінен мець магчымасці трапіць на іншыя старонкі (акрамя створанай раней старонкі "About"), пакуль не выканае ўваход.
- Усе дадзеныя (у тым ліку і дадзеныя профілю) павінны захоўвацца ў лакальнай базе дадзеных, ці ў сэрвісе, падобным да Firebase. Пры выкарыстанні Firebase, аўтарызацыя таксама павінна выконвацца сродкамі гэтага сэрвісу.
- На адной са створаных раней старонак у сістэме навігацыі зрабіць ленту RSS reader'а. (У якасці прыкладу можна паглядзець на праграму Flipboard).
- Пры першым наведванні старонкі, карыстальніку даецца магчымасць увесці адрас, з якога будуць атрымлівацца дадзеныя. Павінна існаваць магчымасць змяніць яго пазней.
- RSS запісы выводзяцца ў выглядзе спісу на тэлефоне і ў выглядзе сеткі з картак (https://material.io/design/components/cards.html) для альбомнай арыентацыі на планшэце (на эмулятары з адпаведнымі параметрамі).
- Кожны запіс уяўляе сабою картку/элемент спісу, на якім прысутнічае выява, дата, загаловак і кароткі замест навіны. Карткі павінны выглядаць у адпаведнасці з Material design guidelines.
- Пры націсканні на запіс, навіна павінна адчыніцца цалкам у WebView, створаным у праграме.
- Зрабіць кэш: апошнія 10 RSS запісаў павінны быць захаваны на дэвайсе і паказвацца карыстальніку нават пры адсутнасці доступу ў інтэрнэт (навіна цалкам у такім выпадку не павінна адчыняцца). Карыстальнік павінен бачыць статус адсутнасці сувязі ў інтэрфейсе (напрыклад, у выглядзе паведамлення ці іконкі на AppBar). Пры змене карыстальника ці адрасу крыніцы навін кэш павінен быць выдалены.