nrk.no

Hackday: WatchKit

Kategorier: Apps, Dev, Hackathon & Mobil

Slik ser Interface Builder ut etter endt hackday.

Tidligere denne uken hadde mobilteamet hackday, hvor alle i teamet fikk bruke en arbeidsdag på å eksperimentere med ny teknologi. Jeg har lekt med Apples WatchKit.

I dag, 24. april, lanseres Apple Watch i de delene av verden Apple mener er verdige. Her på berget må vi nok vente enda en stund før de dukker opp i butikkene, en endelig lanseringsdato har såvidt meg bekjent ikke blitt satt ennå. Salgstallene så langt i de markedene er høye til å være smartklokker, men sett i forhold til salgstall for telefoner og nettbrett er det enn så lenge et nisjeprodukt. Det er dermed usikkert når, hvorvidt og hvor mye vi kan utvikle større prosjekter for Apple Watch så lenge det finnes andre, viktigere områder for oss å fokusere ressursene våre på.

Som utvikler er det spennende å kaste seg over nye teknologier. Dette gir anledning til å få både nye muligheter og nye begrensninger man må løse problemer for. Dette gjelder også WatchKit, navnet på utviklingsmodulen for Apple Watch. Samtidig som det er en kikk inn i framtiden føles det på mange måter som å gå et par skritt tilbake, og det er tydelig at utviklerverktøyene fortsatt ikke er modne. Xcode kræsjer mange ganger daglig, simulatoren fryser støtt og stadig, og mange steg i utviklingsflyten virker litt lite gjennomtenkte.

Kaken som ble servert oss. En slags feiring av Android Lollipop, og et lite eple som blir spist av en av androidene.
Kaken som ble servert oss. En slags feiring av Android Lollipop, og et lite eple som blir spist av en av androidene.

Mål for dagen

Ettersom vi kun hadde én dag på oss, trengte jeg et enkelt prosjekt med et fokusert bruksområde for raskt å komme i gang med å lage noe nyttig. Valget falt på P3-appen, en app som jeg også tidligere har brukt som prøveklut for nye teknologier. Med sitt enkle UI med få funksjoner og lite informasjon som vises er det enkelt å tenke seg hvordan en klokkeapp skal se ut. I sitt aller enkleste brukerscenario ønsker man å se hva som spilles på radio akkurat nå, og å starte eller pause avspillingen. Ingen pushmeldinger, et par linjer metadata og én knapp. Easy peasy.

Hovedvisningen ferdig satt opp i Interface Builder. Slik skal appen se ut, med metadata og play/pause-knapp.
Hovedvisningen ferdig satt opp i Interface Builder. Slik skal appen se ut, med metadata og play/pause-knapp.

Alle som er kjent med Interface Builder, Xcodes editor for UI, har blitt vant til å kunne plassere elementer hvor man vil og ha uendelig mange måter å justere hvordan de ligger i forhold til hverandre. I WatchKit er det ikke helt slik. Her må man velge horisontal eller vertikal layout, elementer kan ikke ligge over hverandre, og man har ingen mulighet til å justere plasseringen på pixel-nivå. Man kan legge inn spacere for å justere plassering, men den graden av kontroll og muligheter man før hadde må man bare gi opp. I tillegg må forholde seg til ulike typer visninger, eller interfaces som de omtales i Xcode.

Bygge opp visningene

Hovedappens interface har få begrensinger annet enn at man må forholde seg til UI-elementer kun fra WatchKit. Dette er elementer som ligner, men ikke er de samme som, de som finnes i UIKit. UIKit er rammeverket som brukes for å utvikle ordinære iOS-apper.  Som i UIKit har man har knapper, labels, tabeller og bilder, men de er ikke arvemessig i slekt med sine motparter og svarer ikke på de samme metodekallene som man er vant til. Tabeller har ingen delegate, men cellene får hver sin egen controller-klasse som tar seg av populering av data. Labels oppfører seg som en blanding av labels og tekstfelt.

Velkjente UIView har blitt erstattet av WKInterfaceGroup som container av innhold, der man som tidligere beskrevet kun har mulighet til å legge ting i rekke, enten horisontalt eller vertikalt. Grupper kan legges inni hverandre, sånn at man får plassert ting nokså greit der man vil, men innhold kan ikke gå over flere grupper eller ligge lagvis med helt eller delvis gjennomsiktighet gjennom lagene.

En annen hovedkategori av app-grensesnitt er såkalte glance-interfaces. Dette er en hurtigvisning av appens tilstand, og er laget slik at man kan swipe sidelengs gjennom alle kjørende apps på klokken og umiddelbart få en kjapp visning av den mest relevante informasjonen fra hver app.

I et glance kan man ikke ha noen elementer som man kan interagere med, så ingen knapper, slidere eller tabeller. I tillegg er man låst til en layout der man har en gruppe på toppen, et mellomrom og en gruppe på bunnen. Innenfor disse kan man legge opp undergrupper hvordan man vil, men man får ikke endre på den grunnleggende strukturen. Den øverste gruppen låst til å dekke mesteparten, men irriterende nok ikke hele bredden av skjermen. Med litt filing fikk jeg plass til det viktigste av informasjon innenfor disse rammene, hva du hører på akkurat nå og hvor lenge det er igjen av programmet.

Slik må layouten være for glances
Slik må layouten være for glances
Slik ser glance-layouten ut i Interface Builder.
Slik ser glance-layouten ut i Interface Builder.

For apper som skal vise pushmeldinger finnes det ytterligere et interface med sine regler man må forholde seg til. Notification-interfacet har en applogo, som denne gangen skal være trill rund, et felt under som viser appens navn der du kan endre bakgrunnsfarge og lite annet, og litt plass til å vise en melding. På bunnen får man automatisk en dismiss-knapp, om man ønsker flere knapper kan man spesifisere dette i selve meldingen man sender til klokken. Ellers er begrensningene de samme som for glances, ingen elementer man kan trykke på eller gjøre noe annet med. Ergo ingen mulighet til å spesifisere opp knapper i Interface Builder, kun i meldingsteksten. Pussig.

Slik ser et tomt notification interface ut. Den runde logoen ligger delvis over en linje som viser appens navn, under den ligger meldingsteksten og en dismiss-knapp nederst.
Slik ser et tomt notification interface ut. Den runde logoen ligger delvis over en linje som viser appens navn, under den ligger meldingsteksten og en dismiss-knapp nederst.
Mock av hvordan et nyhetsvarsel kan se ut i nrk.no-appen
Mock av hvordan et nyhetsvarsel kan se ut i nrk.no-appen
Slik kan det tenkes at et nyhetsvarsel kan se ut i NRK.no-appen.
Slik kan det tenkes at et nyhetsvarsel kan se ut i NRK.no-appen.

Hente og vise informasjon

Når det kommer til kommunikasjon mellom klokka og telefonen endte jeg opp med å bruke et sett med metoder som heter
+ (BOOL) openParentApplication: (NSDictionary *) userInfo reply: (void (^) (NSDictionary *replyInfo, NSError *error)) reply
i WKInterfaceController og dens motsvar i moderappens AppDelegate,
- (void) application: (UIApplication *) application handleWatchKitExtensionRequest: (NSDictionary *) userInfo reply: (void (^) (NSDictionary *replyInfo)) reply
De sender og mottar NSDictionary, tilsvarende Map eller key-value-objekter i andre språk. Det er dermed så generelt at man i prinsippet kan gjøre det man vil, jeg endte opp med å ha et stringobjekt med nøkkel «action», der jeg spesifiserte operasjonen jeg ønsket, og et objekt jeg kalte «args», der jeg la ved alle argumentene som trengtes for den ønskede operasjonen. På den måten fikk jeg fort opp et halvveis definert og ryddig grensesnitt mellom klokke og telefon. Legg på et minimum av feilhåndtering og nullsjekker, så har man en enkel måte å hente ut nesten hva man ønsker. I dictionaryet kan man også legge ved bilder, enkodet som NSData, noe som kan være greit da klokkens mulighet til å gjøre grafikkoperasjoner er alvorlig begrenset.

I mitt tilfelle har jeg definert opp et par grunnleggende operasjoner:
-togglePlayPause, som sender melding til telefonen om at bruker har trykket på knappen og at sendingen skal pauses om den spiller, eller startes hvis den er pauset. Denne returnerer den nye tilstanden til spilleren, om den spiller eller er pauset, og bildet av en knapp i riktig tilstand lagt over logoen på kanalen som spiller.
-getPlayPause, som kun henter den samme informasjonen som over uten å endre på spillerens tilstand.
-metadataUpdate, som henter informasjon om hva som spilles nå, hvor langt programmet har kommet, og ca når metadatene trenger å oppdateres neste gang.

P3-appen, som den fremstår i dag på en iPhone
P3-appen, som den fremstår i dag på en iPhone
Slik ser samme skjermbilde ut på en Apple Watch.
Slik ser samme skjermbilde ut på en Apple Watch.

Med disse operasjonene kunne jeg enkelt populere opp grensesnittene med metadata, både for glance og inne i appen. Det endelige resultatet synes jeg selv ble ganske OK, for en dags arbeid med et rammeverk jeg ikke før har rørt. Noe opprydding og feilretting gjenstår før det er klart for publikum, så om det skal ut må jeg antakelig snike meg til en liten hackday til. Kanskje jeg til og med skal spandere på meg at en designer får se litt på appen sånn at den ikke bare er designet etter innfallsmetoden av en ingeniør.

Skjermbilde fra Urørt-kanalen.
Skjermbilde fra Urørt-kanalen.
Flere skjermbilder, her fra mP3.
Flere skjermbilder, her fra mP3.

Oppsummering

Alt i alt var det en spennende dag der jeg lærte mye. Det er helt tydelig at dette er første iterasjon av en ny produktkategori, en del ting var uvant og mye føles ikke helt ferdig og klart for utvikling på større skala.

Knytningen til telefonen er både en velsignelse og en hemsko, på den ene siden er det fint å delegere tyngre operasjoner, som manipulasjon av grafikk samt henting av data fra server og parsing av dette. På den andre siden virker det som Apple med hensikt har begrenset mulighetene for hva man får lov til i en sånn grad at alle apper som kommer ut til en viss grad kommer til å se like ut og gjøre nesten det samme. Men dette er kanskje akkurat det de ønsker nå i første omgang. Etterhvert som tiden går kommer nok utviklingsverktøyene til å modnes, utviklingsmulighetene økes og vi får en større forståelse for hva vi egentlig skal bruke en slik dings til.

8 kommentarer

  1. Bjørn Are Andreassen

    Synes det er imponerende at dere har tid og penger til å «leke» med utvikling av apps til Apples Watch. Når man spør om oppdatering og utvikling av app for Windows Phone, så får man beskjed om at det er få brukere og ikke forsvarlig økonomisk!

    Svar på denne kommentaren

    • Ola Nordbryhn (NRK) (svar til Bjørn Are Andreassen)

      Her var det altså snakk om en dag der vi kunne utforske nye teknologier. På en god andreplass over ting jeg ville bruke tid på lå Xamarin, men dette valgte jeg bort da dette er et betydelig større felt enn å ta ibruk et nytt rammeverk med alle de samme verktøyene som jeg er vant til. Hadde jeg hatt en uke hadde jeg heller satt meg ned med dette. Resultatet for min del etter en dag med Xamarin, eller native utvikling for WP for den del, hadde nok vært enda mindre imponerende enn det jeg fikk til med WatchKit.

    • Bjørn Are Andreassen (svar til Ola Nordbryhn)

      Dette svaret er ikke direkte knyttet til denne artikkelen men tar den likevel siden det handler om utvikling.

      Personlig så er jeg svært skuffet over hvordan NRK prioriterer når det lages app. Det er hele tiden snakk om iOS og Android (markedsandeler) men når det kommer til smale programmer, som noen få personer ser på TV, så er det ikke noe problem å bruker penger.

      Nå skal det jo også sies at dere har et par apper for Windows Phone. Jeg bruker appen NRK TV men den er ikke oppdatert på 1 år og er vel for WP 8 og ikke 8.1?

      Hvorfor lager ikke NRK universal-app for Windows 8.1? Da kunne apper fra NRK vært brukt både på Windows PC, Nettbrett og Windows Phone! Hvis man summerer antall personer som bruker disse variantene til sammen så er tallet rimelig høyt og burde forsvare pengebruken for å lage en slik app. Vi betaler også lisens for NRK TV.

      Problemet er at NRK er opphengt i mobile enheter som iPhone og iPad og bryr seg ikke om Windows-brukere. Der holder det med en nettleser.

  2. Ola Nordbryhn (NRK)

    Jeg forstår at det er frustrerende at vi ikke satser på akkurat din plattform, og at Windows-plattformen betyr mye for deg. Vi er et lite utviklingsteam på mobil med mange ansvarsområder, samtidig som vi utvikler nye ting må vi vedlikeholde eldre ting. Prioriteringen på hva vi bruker tid på blir derfor ganske hard.

    Enn så lenge har ikke Windows 8 / Windows Phone 8 / Xbox One en veldig stor brukermasse, hverken i landet som helhet eller på våre nettsider, sett i forhold til gigantene iOS og Android på mobil og Windows 7 på desktop. Verdien av å ha en native app på Windows 8 versus det å ha en god nettside har jeg heller ikke sett noen tall på som overbeviser meg helt.

    Ellers må jeg bare referere til tidligere svar du sikkert har lest:
    https://nrkbeta.no/2015/03/17/betateste-ny-radioapp/#comment-559595
    https://nrkbeta.no/2015/03/17/betateste-ny-radioapp/#comment-560488
    https://nrkbeta.no/2014/07/01/ny-tv-app-pa-ipad/#comment-172857

    Svar på denne kommentaren

    • har dere virkelig vurdert/forsøkt å lage EN (1!) kodebase for samme applikasjon uavhengig av hvor den skal lande?

      sånn rent teknisk (ok teoretisk da) er det jo mulig, og da slipper dere å gjøre jobben mer en enn gang, men man kan få ALLE («store») plattformer samtidig.

      for en blåruss så kunne dere da ha vist frem de linkene så mange ganger dere bare ville, men de ville vært veldig ubrukelige gitt at man faktisk kunne lage en kodebase, og distribuere over alt.

      forutsetningen om at en kodebase gir mindre timer og bedre økonomi ligger selvfølgelig til grunn her (og ja det er heller ikke garantert).

    • Ola Nordbryhn (NRK) (svar til navn)

      Dette er noe vi selvfølgelig har vurdert. Det er, så langt jeg kan se, tre hovedankepunkter akkurat nå mot dette:
      – Medieavspilling på tvers av plattformer er vanskelig. Det å få alle Android-enheter til å spille av har tatt mye tid, og stadig kommer det overraskelser med nye enheter eller oppgraderinger som brekker ting. WP har ikke problemer i samme utstrekning, men også her kreves spesialtilpasning.
      – Forskjellige OS ser forskjellige ut, med ulike navigasjonsparadigmer og ønsket oppførsel. Det å klemme alle inn i et minste felles multiplum vil gjøre at alle versjoner ser litt halvveis ut.
      – Jeg vet ikke hvor mye du har jobbet med store rammeverk som skal gjøre alt samtidig og løse alle problemer med samme kodebase, men jeg har vært innom en del. Felles for dem alle er at de fungerer strålende i en salgssammenheng, på en liten time kan man få til masse kult. Problemet kommer i det man når rammeverkets yttergrenser. Hvis man vil gjøre noe rammeverket ikke støtter, må man enten inn med hårete hacks eller tenke om hele problemstillingen. Hver gang det kommer en OS-oppdatering som medfører nye problemer må man sitte tålmodig og vente på at rammeverket oppdateres.

      Rent teoretisk er det en utrolig fin tanke, og noe mange trodde at HTML skulle løse for oss én gang for alle. Den gamle appen for TV og dagens løsning på radio viser vel at dette ikke er fullgode løsninger akkurat nå. Fortsatt er det mange gode initiativ, som sikkert fungerer veldig bra for veldig mange, men der vi er ønsker vi å gi brukere på hver plattform vi satser på en så god opplevelse som mulig, fremfor å forsøke å dytte alle brukere inn i en så liten kodebase som vi klarer. Hvor vi er om fem år, eller to år for den saks skyld aner jeg ikke.

    • Svein Are Karlsen (svar til Ola Nordbryhn)

      WP8> kjører jo på en NT kernel, med HAL.

      Apps til Windows 8 Windows 8.1, Windows 10, Windows RT, Windows Phone 8 og Windows Phone 8.1 kan alle bruke nøyaktig samme kodebase dersom det er tatt litt høyde for skjermstørrelsene.

      Dersom kodeken h264 brukes fornuftig vil bortimot alle enheter ha maskinvarestøtte for dekoding og avspilling.

      Tell da antall brukere av alle disse plattformene, og se hvor mange fler dere får med i ett jafs 🙂

      Kanskje tallene ser mer forsvarlige ut da?

      Å få dette på bordet FØR Windows 10 ville jeg sett på som proaktivt. Dere vil jo henge etter andre tilbydere dersom dere ikke tar dere til noe ganske snart.

      Mvh. Svein Are karlsen

    • Ola Nordbryhn (NRK) (svar til Svein Are Karlsen)

      Vi er fullt klar over at man kan benytte samme kodebase til alt du nevner. Om det viser seg at dette er en plattform som mange begynner å bruke er det interessant å utvikle til den. Windows 10 er også interessant, men jeg mistenker at også dette kommer til å bli brukt mest på desktop.

      Vi benytter h.264, det er ikke der problemet ligger. Det virkelig gufne kommer i noe så trivielt som i distribusjonscontaineren. Vi bruker to standarder, HDS som er utviklet av Adobe, og HLS som er utviklet av Apple. Konkurrerende standarder er et utall versjoner av SmoothStreaming, som ikke nødvendig vis er kompatible med hverandre, og MPEG DASH som vi følger med på, men som ikke enda er helt moden.

      Jobben til disse containerene er enkelt forklart å kutte opp videoen i segmenter på ti sekunder og overføre dem over HTTP. Vanskeligheten med dem er det å overføre et uendelig langt program man kan spole tre timer i, også kjent som direktesending med livebuffer.

      Mange spillere sier at de støtter HLS, men nesten ingen får til å spille av livestrømmen. HDS fungerer kun gjennom Adobes produkter, og Flash/Air er som kjent ikke høyeste mote på mobil. SmoothStreaming fungerer best på Microsofts produkter, men forskjellige versjoner fungerer best mot forskjellige devicer.

      MPEG DASH er, såvidt meg fortalt, en så vid standard at nesten hva som helst kan puttes inn i den. Forskjellige spillere som støtter forskjellige deler av standarden vil dermed ikke kunne spille av samme strømmen, og standarden står dermed i fare for å skape flere problemer enn den løser. Litt som beskrevet i denne legendariske XKCD-stripen: https://xkcd.com/927/

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *. Les vår personvernserklæring for informasjon om hvilke data vi lagrer om deg som kommenterer.