Week 01

úvod do problematiky, spôsoby vývoja, Android overview, aktivity, triedy Log a Toast

About

  • http://sli.do#ki-smart - anketa a otázky pre prednášajúceho

  • https://join.slack.com/t/ki-smart/signup - slack pre rýchlu komunikáciu

  • (slide) pravidlá

    • cvičenia - tento rok špeciálne - budeme sa snažiť v rámci cvičení vždy predstaviť niektorý zo senzorov mobilného zariadenia na jednoduchej aplikácii
    • zápočet - vypracovanie sport tracker aplikácie makač alebo príspevok k práve otvorenému OpenLab-u alebo voľný výber, preberať sa bude počas konzultačných cvičení pred udalosťou s názvom hackathon
    • skúška - samsink spešl

  • (slide) hackaton - úvodné informácie o tom, čo ich čaká - predbežný dátum je prelom november/december, účasť na hackaton-e znamená automatické absolvovanie skúšky

    • ak sa niekto hackathonu nezúčastní, bude musieť vytvoriť vlastnú aplikáciu porovnateľnú s výstupmi, ktoré urobíte na hackathone
    • rozsah a vhodnosť aplikácie odobrí cvičiaci
    • tento rok máme dokonca hackathony dva
      • (slide) AT&T Hackathon
      • (slide) T-Systems Hackathon
      Vybrať si môžete ktorý chcete. Nezabudnite sa však naň registrovať!

  • (slide) Tento predmet bude o vývoji aplikácií pre chytré (smart) zariadenia - na prednáškach nebudem robiť vyčerpávajúci výklad, ale budem vám predstavovať jednotlivé technológie na živých ukážkach. Čítať dokumentáciu pri vlastnom vývoji budete až doma :-P

The 3 Types of Mobile Experiences

  • (slide) Skôr, ako sa začneme venovať samotným technológiám, pozrieme sa na 3 rozličné spôsoby vývoja aplikácií pre chytré zariadenia
  • toto delenie je na základe jednoho z Research Guides portálu DZone, takže iný zdroj môže uvádzať iné rozdelenie, ale v princípe sa jedná o:
    1. natívna aplikácia
    2. webová aplikácia
    3. hybridná aplikácia

Native Applications

  • (slide)
  • sú napísané v jazyku danej mobilnej platformy (Android - Java, iOS - Objective C/Swift, Windows Phone - C#)
  • aplikácie sú prekladané a spúšťané priamo na danom zariadení
  • vďaka SDK vie aplikácia komunikovať s platformou a pristupovať tak napr. k uloženým údajom, senzorom alebo komunikovať s externou službou pomocou HTTP dopytov
  • výhody:
    • priamy prístup k natívnemu API
    • natívne aplikácie dosahujú v porovnaní s ostatnými typmi aplikácií najvyšší výkon
  • nevývhody:
    • aplikácie nie sú platformovo nezávislé - pre každú platformu je potrebné aplikáciu vytvoriť zvlášť
    • obyčajne je ich vývoj náročnejší a tým pádom aj drahší

Web Applications

  • (slide)
  • známe aj ako Mobile Websites
  • aplikácie sú dostupné prostredníctvom mobilného webového prehliadača
  • sú umiestnené na vzdialenom serveri
  • obyčajne sú to naozaj len webové stránky optimalizované pre zobrazovanie na mobilnom zariadení, napr. http://m.ebay.com, http://m.facebook.com a pod.
  • výhody:
    • aplikácie sa neinštalujú na zariadenie - sú umiestnené na vzdialenom serveri
    • jednoduchá správa a údržba aplikácií - nevyžaduje od používateľa žiadne špecifické oprávnenia pre inštalovanie/aktualizáciu
    • aplikácie sú prenositeľné aj na iné systémy - postačujúci je len webový prehliadač
  • nevýhody:
    • aplikácie nemajú prístup k natívnemu API alebo ku samotnej platforme - sú spustené v prehliadači
    • pre spustenie je potrebné napísať adresu do prehliadača alebo si urobiť vlastný spúšťač
    • obmedzené možnosti používateľského rozhrania - dané možnosťami technológií HTML5

Hybrid Applications

  • (slide)
  • je to mobilná aplikácia obsahujúca tzv. Web View (izolovanú inštanciu prehliadača), ktorý umožňuje spustiť webovú aplikáciu vo vnútri natívnej aplikácie
  • Web View využíva wrapper, pomocou ktorého dokáže webová aplikácia komunikovať s natívnou platformou a mať tak prístup ku zdrojom zariadenia (napr. GPS, databáza, súbory atď.)
  • wrapper nie je súčasťou natívnej platformy, ale sú to produkty tretích strán (napr. Apache Cordova)
  • výhody:
    • aplikácie sú cross-platformové - rovnakú aplikáciu je možné spustiť na niekoľkých platformách
    • na tvorbu hybridných aplikácií stačia znalosti pre tvorbu webových stránok alebo webových aplikácií - technológie HTML5
    • aplikácie majú prístup ku samotnému zariadeniu
    • jednoduchý vývoj - rýchly, používajú sa rovnaké nástroje ako pri tvorbe webových stránok/aplikácií
  • nevýhody:
    • obmedzenie vzhľadom na možnosti Web View-u
    • nemusia byť implementované všetky možnosti natívneho API - implementácia formou rozširujúcich modulov (plugin-ov)
    • žiadna natívna podpora pre ovládacie prvky - bez rozširujúcich nástrojov/knižníc si takéto prvky musí vytvoriť sám používateľ

Prieskum DZone

  • prieskum z roku 2016, ktorého sa zúčastnilo vyše 400 IT profesionálov (v rokou 2015 ich bolo vyše 500), ktorí sú nejakým spôsobom zahrnutí v oblasti mobilných technológií

  • niekoľko otázok:

    • (slide) otázka č. 1 - “What platforms do you develop mobile apps for?” - aplikácie sa primárne vyvíjajú pre OS Android
    • (slide) ak sa však pozrieme na túto otázku do predchádzajúceho roku, môžeme vidieť rozdiel medzi druhým a tretím miestom, kde si platforma iOS oproti roku 2015 pohoršila a hybridný vývoj aplikácií si naopak polepšil. Táto zmena môže napr. odrážať aj aktuálny trend v oblasti - zvýšený záujem o tvorbu hybridných mobilných aplikácií.
    • (slide) V roku 2015 bola súčasťou prieskumu aj otázka - “Which programming language do you or your organization use for developing mobile apps?” - dominujúce jazyky, v ktorých sa píšu aplikácie pre mobilné zariadenia. Tento zoznam sa však dá odvodiť už z pohľadu na trendy v oblasti konkrétnych mobilných platforiem.

  • vzhľadom na (nie len) výsledky uvedené v prieskume serveru Dzone je možné vyvodiť záver, že sa oplatí venovať najmä vývoju natívnych aplikácií, aj keď náskok hybridných aplikácií už nie je taký výrazný, ako bol vlani

  • (slide) v našom predmete sa budeme snažiť venovať hlavne vývoju natívnych aplikácií pre OS Android (ukážeme si aj ukážku vývoja pre iOS) a hybridných aplikácií pomocou rámca Apache Cordova

Android Overview

  • (slide)

  • za androidom stojí spoločnosť Google

  • Android je open-source (aj keď konkurencia mala k tomuto termínu výhrady, pretože tvrdila, že Android nie je až taký open, ako o sebe hovorí; odpoveď Andyho Rubina na sebe nenechala dlho čakať ;) (slide)

  • (slide) v súčasnosti už Android nie je len doménou mobilných telefónov, ale aj tabletov, automobilov, TV, a tzv. wearables (hodinky, okuliare)

Android and Java

  • (slide)
  • aplikácie sa v Androide píšu v Jave (natívny vývoj), ale môžu sa aj v jazyku C pomocou tzv. NDK (Native Development Kit)
  • spôsob prekladu Android aplikácií vyzerá o niečo ináč v porovnaní s tým, ako prebieha preklad aplikácie v štandardnej Jave - po preklade do bytecode-u sa výsledný kód preloží ešte pomocou Dex prekladača, z ktorého vznikne aplikácia vo forme apk balíku
  • samotná Java v Androide sa od štandardnej Javy líši tým, že bola odstránená časť rámca Swing pre tvorbu UI a bola rozšírená o Android API

Kotlin

Torch Application

  • (slide)
  • Miesto štandardnej Killer App s názvom Hello world sa pustíme rovno do niečoho použiteľnejšieho. Vytvoríme si aplikáciu, ktorá nemôže chýbať v žiadnej aplikácii typu Swiss knife - flashlight (baterku). My ju však nazveme poetickejšie - (slide) Torch
  • Aby sme si ukázali, ako táto aplikácia bude vyzerať a ako sa bude správať, jednoduché demo sa nachádza na nasledujúcom slajde (slide).

New Project

  • Začneme s tým, že vytvoríme nový projekt. V prvom okne nastavíme základné veci a teda:
    • projekt pomenujeme Torch,
    • doménou bude smart.tuke.sk, z ktorého sa automaticky vytvorí menný priestor pre aplikáciu sk.tuke.smart.torch, a
    • umiestnenie projektu na disku.
  • V ďalšom okne vyberieme typ našej aplikácie (Phone and Tablet) a nastavíme minimálnu verziu Android SDK, na ktorom aplikácia pobeží. V našom prípade to bude API 23: Android 6.0 (Marshmallow) (slide).
    • Android Studio ponúka aj pekný prehľad jednotlivých verzií Android-u a ich aktuálne zastúpenie na trhu. Keďže vždy budeme chcieť, aby sa naša aplikácia dostala k čo najväčšiemu počtu používateľov, musíme zvoliť vhodný kompromis medzi vlastnosťami príslušnej verzie a zastúpením na trhu.
  • V ďalšom okne pridáme do našej aplikácie aktivitu - základný stavebný prvok každej Android aplikácie. V našom prípade to bude základná (prázdna) aktivita Empty Activity.
  • V nasledujúcom kroku upravíme vlastnosti tejto aktivity. Tentokrát si však vystačíme s predvolenými vlastnosťami a teda len potvrdíme voľby kliknutím na tlačidlo Finish.

Spustenie aplikácie

  • Máme dve možnosti, ako, resp. kde spustiť vytvorenú aplikáciu:

    1. na fyzickom zariadení s OS Android, alebo
    2. na emulátore so systémom Android

  • Ak aplikáciu spúšťame na fyzickom zariadení, tak:

    • potrebujeme mať zariadenie pripojené k počítaču,

    • zariadenie musí mať zapnutý režim pre vývojárov (je potrebné 7 krát kliknúť na položku Build number v menu System > About phone, a

    • zariadenie musí byť identifikované nástrojom adb, čo vieme zistiť príkazom

      adb devices

  • V druhom prípade si vieme spustiť emulátor, na ktorom môžeme emulovať zariadenia so systémom Android. Môžeme si vybrať niektoré z predvolených zariadení alebo si môžeme vytvoriť zariadenie podľa vlastného vkusu (parametrov).

  • Následne už len aplikáciu spustíme. Tým dôjde k prekladu aplikácie, vytvoreniu .apk súboru a jeho nainštalovanie na príslušné zariadenie.

Activity

  • Poďme sa však pozrieť späť na kód, ktorý sa spustil a pokúsme sa nájsť štartovací bod celej aplikácie.

  • (slide) V Androidovej aplikácii neexistuje hlavná metóda main() podobne ako v iných jazykoch, ktorá predstavuje vstupný bod programu/aplikácie.

  • Android aplikácia sa skladá z tzv. aktivít, ktoré reprezentujú samotné “obrazovky” aplikácie (slide). V porovnaní s hlavnou metódou nás teda bude zaujímať, ktorá aktivita je teda hlavná, resp. ktorá aktivita sa má spustiť ako prvá.

  • (slide) Aktivitu si je možné predstaviť ako webovú stránku, ktorá sa skladá z podstránok. Podobne aj Android aplikácia je zložená z niekoľkých aktivít.

  • Príkladom môže byť aplikácia na posielanie/prijímanie správ (SMS-iek):

    • aktivita so zoznamom všetkých prijatých/odoslaných správ
    • aktivita pre zobrazenie konkrétnej správy, resp. konkrétneho vlákna správ
    • aktivita pre napísanie novej správy

Vzhľad aktivity

  • definovaný pomocou tzv. layout súboru vo formáte XML

  • vzhľady jednotlivých aktivít sa nachádzajú v priečinku app/res/layout/, v našom prípade to bude priamo po vytvorení súbor activity_main.xml

  • po kliknutí na tento súbor sa nám v prostredí zobrazí aktuálne rozloženie aplikácie - Hello world aplikácie

  • upravíme rozloženie tak, že do neho pridáme jedno tlačidlo a samotný popisok presunieme do stredu aplikácie - ten bude zatiaľ slúžiť na zobrazovanie sprievodného textu o tom, či žiarovka svieti alebo nie:

    Rozloženie aplikácie Torch

  • V spodnej časti obrazovky sa nachádzajú dve záložky - Design a Text. My práve používame tú dizajnovú, v ktorej môžeme priamo navrhnúť vzhľad aplikácie.

  • po prepnutí sa do záložky Text uvidíme samotný design opísaný v XML formáte. Aktuálne sa v ňom budú nachádzať dva elementy - <TextView> a <Button>

  • jednotlivé elementy budeme mať možnosť v kóde identifikovať na základe ich atribútov android:id - pre element <TextView> aktuálne chýba, tak ho vytvoríme:

    android:id="@+id/label"

  • vzhľad bude teda aktuálne pre aplikáciu definovaný takto:

    <?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <TextView
        android:id="@+id/label"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello World!"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintLeft_toLeftOf="parent"
        app:layout_constraintRight_toRightOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

    <Button
        android:id="@+id/button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginStart="8dp"
        android:layout_marginEnd="8dp"
        android:layout_marginBottom="8dp"
        android:text="Button"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent" />

</android.support.constraint.ConstraintLayout>

Ošetrenie kliknutia na tlačidlo

  • Ak chceme zabezpečiť, aby sa po kliknutí na tlačidlo rozsvietilo svetlo (zatiaľ samozrejme len zmenil text v elemente <TextView>), pridáme do elementu <Button> atribút android:onClick, ktorého hodnota bude meno metódy, ktorá sa zavolá. Táto metóda sa však musí nachádzať v triede, ktorej vzhľad je definovaný práve týmto súborom.

  • Metódu nazveme toggle a príslušný atribút elementu <TextView> bude vyzerať nasledovne:

    
android:onClick="toggle"

  • V triede MainActivity následne vytvoríme metódu, ktorá:

    • sa bude volať toggle()
    • bude (a musí) mať jeden parameter typu View, ktorý je referenciou na pohľad (v našom prípade tlačidlo), na ktorý bolo kliknuté

  • Jej prázdna definícia bude vyzerať nasledovne:

    
public void toggle(View view){
}

  • Najprv veľmi jednoducho overíme len to, či je táto metóda naozaj po kliknutí na tlačidlo zavolaná. Aktualizujeme preto túto metódu a vložíme do nej volanie metódy System.out.println() na vypísanie textu na štandardný výstup:

    public void toggle(View view){
  System.out.println("Button was clicked");
}

Trieda Log a Android LogCat

  • V štandardnej Jave sa volanie System.out.println() používa na vypísanie textu na štandardný výstup. Kde sa však vypíše v prípade mobilného zariadenia v OS Android, keďže tu žiadny štandardný výstup (textová konzola) nie je?

  • V OS Android je výstup z metódy System.out.println() presmerovaný do tzv. LogCat-u.

  • (slide) Logcat is a command-line tool that dumps a log of system messages, including stack traces when the device throws an error and messages that you have written from your app with the Log class.

  • Okno LogCat-u môžeme zobraziť priamo vo vývojovom prostredí Android Studio stlačením kombinácie kláves ALT + 6 alebo z príkazového riadku spustením príkazu:

    
adb logcat

  • Ak sa teda pozrieme do LogCat-u uvidíme záznam v tvare:

    
10-03 05:00:18.453 2544-2544/sk.tuke.smart.torch I/System.out.println: Button was clicked.

  • Volanie metódy System.out.println() bolo totiž presmerované do LogCat-u pomocou volania metódy Log.i(), pričom trieda (slide) Log poskytuje API pre logovanie.

  • Je dobrou praxou vytvoriť pre každú triedu statickú premennú TAG, ktorá sa potom používa v rámci volania jednotlivých metód nad triedou Log. Hodnotou tejto premennej je meno triedy, v ktorej logujeme. Neskôr je možné na základe tohto mena napr. jednotlivé správy filtrovať v LogCat-e.

  • (slide) Existuje 6 úrovní logovacích správ:

    • VERBOSE - nemal by byť nikdy zahrnutý do výslednej aplikácie!
    • DEBUG - ladiace informácie
    • INFO - všeobecné informácie (štartovanie/vypínanie aplikácie)
    • WARN - upozornenia
    • ERROR - závažné chyby, problémy ovplyvňujúce funkcionalitu aplikácie
    • WTF - skratka pre What a Terrible Failure, označuje stav, ktorý by nikdy nemal nastať

  • Pri logovaní platí, že ak logujem v úrovni logovania X, tak v rámci logov sú zahrnuté aj všetky vyššie úrovne (úroveň >=X).

  • Môžeme teda upraviť náš kód tak, že miesto volania System.out.println() budeme správu logovať pomocou triedy Log:

    
public String TAG = "MainActivity";

public void toggle(View button){
  Log.i(TAG, "Button has been pressed.");
}

  • Ak sa pozrieme do LogCat-u uvidíme záznam v tvare:

    
10-03 05:01:18.453 2544-2544/sk.tuke.smart.torch I/MainActivity: Button was clicked.

  • Rozdiel oproti záznamu po volaní metódy System.out.println() je len v TAG-u, ktorý aktuálne obsahuje hodnotu MainActivity, pričom pri volaní pomocou metódy System.out.println() obsahoval hodnotu System.out.println.

Trieda Toast

  • (slide) Výstup z metód triedy Log však nemôžeme používať v prípade, ak chceme správu zobraziť priamo aj pre používateľa. Na rýchle zobrazovanie správ však môžeme s výhodou použiť triedu Toast.

  • Toast poskytuje jednoduchú spätnú väzbu o činnosti v malom vyskakovacom okne. Vyplní na obrazovke len toľko miesta, koľko je potrebného pre zobrazenie správy. Samotná aktivita pod správou zostáva viditeľná a rovnako ju je možné aj naďalej používať.

  • Toast automaticky zmizne po uplynutí časového limitu.

  • Náš kód môžeme opäť upraviť tak, aby po kliknutí používal triedu Toast:

    
public String TAG = "MainActivity";

public void toggle(View view){
    Log.i(TAG, "Button has been pressed.");
    Toast.makeText(this, "Button has been pressed.", Toast.LENGTH_SHORT).show();
}

  • Na získanie spätnej väzby o stlačení tlačidla teda môžeme s výhodou použiť práve Toast. Po kliknutí na tlačidlo zabezpečíme, aby sa na obrazovke zobrazila správa Light is On, ak dôjde k zapnutiu baterky alebo Light is Off, ak dôjde k vypnutiu baterky. Na to však budeme v aktivite potrebovať jednu členskú premennú typu boolean, ktorá bude držaž aktuálny stav baterky (zasvietená/zhasnutá):

    
private boolean isOn;

  • členskú premennú isOn inicializujeme v metóde onCreate() aktivity na hodnotu false (zhasnutá)

    
this.isOn = false;

  • vytvoríme telo metódy toggle(), ktoré zabezpečí zmenu stavu po kliknutí na tlačidlo, o čom budeme informovaní vypísaním príslušného textu do konzoly (tentokrát text nájdeme v okne Android > logcat)

    
public void toggle(View button){
    this.isOn = !this.isOn;
    if(this.isOn == true){
        Toast.makeText(this, "Light is Off", Toast.LENGTH_SHORT).show();
    }else{
        Toast.makeText(this, "Light is On", Toast.LENGTH_SHORT).show();
    }
}

Conclusion

Keďže nám na viac nezvýšil čas, obrázky reprezentujúce aktuálny stav pridáme až nabudúce.

Additional Resources