Android app for weather and local air quality - now updated with feedback UI!

For my BA project I'm making a contextual app for Android 2.3+ that targets the users context (time and place). It shows the forecast and weather now as well as local air quality.

Weather is shown for the entire globe where as the air quality is limited to stations in Norway. It uses my service bus that runs on a LEMP server with Redis for key/value storage.

My App asks my servicebus for the closest stations, the service bus runs geospatial queries and then query the API's if it's not already stored in Redis.

The user can then enrichen the data by submitting how the local weather is, as some times it's not the closest station that is most correct (maybe you live at a different elevation, maybe there is a mountain between you and the closest station or other factors that would mean that other stations should be weighted above the closest ones.).

Current data sources:

• yr.no
• nilu.no

Redis service bus for API calls

Redis service bus for API calls means that I can store the
users context (geo fence) as a time+place context.

Instead of having all the users query the same API calls for the same context, why not geo fence the API queries and let redis act as a remote storage for the results? That's what I asked my self in my undergoing bachelors project.

My Android app "Kontekst" (Norwegian for Context) will query data sources like YR and NILU – Norsk institutt for luftforskning.

The context of the user shold show data relevant for the user and the user should not have to wait for the same data delivered to other users in the same context. There is the dimension place (location) and there is time. Time doesent stand still even though the user does and after 10 minutes, the data is considered stale when it comes to air quality and the local weather situation.

Yet there are hundreds of thousands of inhabitants, even in the city of Bergen, Norway! So why not use the contexts and harvest the great powers of Redis?

Innføringsguide - Utvikling for Google Chrome APP

Denne innføringsguiden vil ikke ta for seg noen ting rundt det å skrive kode, eller å publisere en App. Formålet med guiden er å gjøre deg kjent med de tre typene apper man kan snakke om

1. Hosted App (webapp)
2. Extension (utvidelse / innstikk)
3. Packaged App (app som er mulig å pakke for nedlasting)

Før man i det hele tatt skal vite noe om hvor mye jobb det er, må man finne ut hvilken av de tre typene som er mest egnet for det man vil få til, med de rammene man har.

Jeg anbefaler som et første steg å kikke på: Choosing an App type

Det er enkelt å følge flytskjemaet og finne ut hvilken type App man bør lage.

Bloggen min er nå tilgjengelig som en hosted app
det vil si at den kan installeres i Google Chrome
sin applikasjonskuff. >> Installer bloggen <<

For noen vil det være viktig å få en viss type funksjonalitet, i så fall vil man muligens utelukke noen av typene. Eksempelvis vil en extension fungere som en utvidelse av nettleseren. En extension kan være en App som tar skjermbilder av nettsider, finner relevant innhold eller annet. Extension har tilgang til en del APIer.

En hosted App, altså en Webapp - ser ofte ut som en vanlig nettside. Den kjører på ditt eget webhotell. I praksis er dette den enkleste formen for App du kan lansere i Google Chrome Appstore. Hosted app fremstår mer som en lenke, den vil dog havne i applikasjonsskuffen.

Packaged app er best egnet for apper som skal fremstå som det folk forbinder med apper. Men det stiller krav til innhold og funksjonalitet, at du kan pakke det ned - for nedlasting. Eksempel kan være en kalkulator, et tegneprogram eller lignende.

Når du har valgt hvilken type app du skal ha, er det neste steget å ta fatt på igangsettingsguidene til Google.

Eksterne lenker

• Getting started (enkel app, hosted)
• Getting started (extension)
• Create your first App
• Github (Hello World)
• Hello World (i chrome app store)
• Github (alle eksempler)
• Informasjon om ikoner
• Sublime text (teksteditor)

Bloggen kan installeres som en Google Chrome APP

icon_128.png og manifest.json komprimeres og lastes opp på
Google Chrome sin utviklerside, deretter laster man opp
skjermbilder og promo-bildene.

Etter litt programmering for en klient, fant jeg ut at jeg skulle lage en Chrome APP.
Jeg har større planer enn det jeg endte opp med, men jeg måtte jo lage min egen "hello world" (det er en slags basic / helt enkel kode man lager, for å se om man får til noe).

Det var veldig enkelt å lage en slik type app (self hosted). I praksis betyr det at Appen fungerer som en lenke til nettstedet. Den vil dog ligge i applikasjonsskuffen til chrome. Du må også lage ikon til Appen, samt du må lage skjermbilde(r) og du må lage minst en stk. banner (helst tre, men jeg lagde bare en).

Det er også en JSON manifestfil du må fikle litt med.

Resultatet blir en app ala: https://chrome.google.com/webstore/detail/olav-alexander-mjelde/bcmlknapffmfojgppldoidendbiiendg?utm_source=plus

Mitt neste prosjekt blir nok en extension (utvidelse / innstikk).

Leksikonsøk på TVen?

Hver søndag, starter jeg som regel dagen min med litt surfing fra sengekanten, før jeg drar meg ut av sengen, trer inn i dusjen og deretter lager egg og bacon til frokost.

Jeg er vel neppe alene om dette, å sitte på sengekanten for å lese litt nyheter eller andre artikler. I morges tenkte jeg over: Hvordan gjør JQuery Mobile seg på en SmartTV? Jeg har jo to SmartTVer og flere JQuery Mobile sider jeg har laget før - så det var jo en enkel sak å teste.

Ransake fant jeg ut var en god kandidat, her er det utstrakt bruk av CORS (Cross-Origin Resource Sharing), gjennom min egenutviklede API-PROXY, som mellomlagrer resulatene. Ransake benytter seg også av NSF (Norsk Scrabbleforbund) sin ordliste, for "tilfeldig"-funksjonen (søk etter tilfeldige emneord).

Testen min var ikke -om det virker-, dagens SmartTVer baserer seg nemmelig - som de fleste nettleserne på WebKit. At det virket, var nesten forventet - og det virket!

Universell utforming

Når det kommer til grad av universell utforming, vil jeg si at her er det TVen som ødelegger moroen.
Teksten, bilder og alt annet fungerer utmerket og som forventet, knapper er store og tydelige, illustrsajoner like så. Men tekst-inntasting gjennom en fjernkontroll er fremdeles en utfordring.

Nå kan jeg riktignok fjernstyre TV-en min gjennom en APP, slik at jeg kan bruke tastaturet jeg foretrekker på telefonen (eller nettbrettet). Eller, jeg kan velge å koble til et tastatur til TVen.

Hvor mange som kobler tastatur eller mobile enheter til TV-apparatene, vet jeg ikke. Hvis mange gjør dette, er kanskje ikke inndata et like stort problem som jeg personlig føler det er. 

Funksjonalitet

Som forventet, fungerte funksjonaliteten på lik måte som på mobil, nettbrett eller PC.
Jeg må egentlig si at jeg var overrasket over hvor raskt det gikk, særlig når jeg henter tilfeldige ord og så søker opp fra 8 API-tilbydere og laster dette inn asynkront i Ransake. Jeg fikk opp bilder fra Flickr, artikler fra Store Norske Leksikon, artikler fra Bergen byleksikon, Norsk Kunstnerleksikon, WikiPedia og flere andre kilder. Alt fungerte sømløst og kjapt, selv om SmartTVer har svakere prosessor enn dagens telefoner.

Her skinner selvsagt den asynkrone lastingen godt, man laster nemmelig inn data - uavhengig av grensesnittet. Grensesnittet lastes bare en gang og innholdet lastes uavhengig. I motsetning til synkrone webapplikasjoner, vil man ikke her måtte vente på svartider, domeneoppslag og annet. At jeg har laget en proxy for API-er, som både omgår CORS-problemet (same origin policy) og mellomlagrer JSON-treff, betyr at jeg får enda raskere søketreff.

Erfaringer fra bruk

Tilfeldig-knappen synes jeg er enda mer på sin plass på TV, enn på mobil. Jeg er glad i den på mobilen også, men på TV-en er inndata enda kjedeligere enn på mobilen. Jeg liker ikke å skrive på OSD (On-Screen Display) tastatur. At jeg kan ligge på sengekanten og trykke på "tilfeldig" og enten laste tilfeldige bilder, basert på ord fra NSF-listen (eller se artikler), er ganske kult. Jeg vil si det er minst 80% kult, en måte å snuble over innhold på.

Jeg tror ordskyen (som jeg ikke har utviklet) - der jeg skal visualisere brukerskapte spørringer og utbredelsen (relativ forekomst hos datatilbyderne) - vil være enda en god kilde for bruk. Særlig gjelder nok dette på TV, hvor man da kan lese seg gjennom en strøm av hva andre folk har søkt etter! Man har da en "trending", ved at brukerne skaper metadata om bruken.

Andre kule ting å gjøre på mobil/tv-APP

Jeg har tenkt på å implementere SSE (Server Sent Events), som betyr at jeg kan fra serverens side påtvinge oppdateringer av grensesnittet til brukeren. Eksempel på dette er et parkeringssystem jeg lagde i HTML5, med kartbobler, som viste kapasite på 3 parkeringshus i Bergen. Her brukt jeg AppCache, LocalStorage, SSE og selvsagt responsivt design. Jeg har tenkt litt tanker rundt dette i morges, når jeg lå på sengekanten.

Hva er egentlig vitsen med informasjonstavler, når man kan lage HTML5 APPS med SSE?

Man trenger ikke dyre infotavler med proprietær programvare, man kan like gjerne lage HTML5-baserte APPs som fungerer på alle plattformer.

Tanker om ransake

Jeg er usikker på hva jeg skal gjøre med ransake, den fungerer fint som en demo og jeg kan utvikle mer på den. Men jeg tenker at Ransake -navnet ikke er bra nok. Hva er det for noe? Enten må jeg finne på et "hipt navn" og skape assosiasjoner, eller jeg må prøve å få en bedre definisjon av hva ransake er for noe. Det er ikke utelukkende leksikon, samt jeg vil koble på mer.. Men hva er det egentlig (hvis man ser bort i fra at det er en slags proof of concept).

Hvis jeg for eksempel skal lansere Ransake som en APP, på TV og mobil, hva kaller man det? :-)
Den vil jo gi treff i alt fra WikiPedia til forskjellige nettleksikon, til flickr og enda flere kilder jeg kobler på.
Jeg er usikker på hvordan jeg skal definere ransake, hva er det, er det håndfast? Hvorfor skal folk bruke ransake? Må jeg snevre inn "scopet" til bare leksikale kilder, ellre bør jeg koble på populære tjenester som instagram, facebook og annet? Jo flere datakilder jeg kobler på, jo mer "ullent" føler jeg tjenesten blir.

Men samtidig blir en mer ullen tjeneste kanskje mer morsom å bruke, med NSF-ordlisten og tilfeldig-funksjonen, ser jeg jo lett at mange søkerod ikke får treff i flickr. De fleste ordene har artikler i en av de autoritative kildene, men bilder er en annen ting - her må jeg nok eventuelt koble meg på flere bildetjenester!

Smartere SmartTV, la oss lage gode APPer!

Utallige ganger har jeg hørt folk si ting som

• "Jeg trenger ikke smartTV"
• "Jeg bruker aldri funksjonene på smartTVen"

I en viss grad er det vel stort sett bare NetFlix og HBO som blir benyttet svært aktivt.

Hva er årsaken?

• Kan det ha noe å gjøre med at fjernkontrollen ikke er egnet for interaksjon?

Hva kan vi gjøre?

Mange savner nok APPer på sine Smarte TV-er, smarte DVD-spillere og andre enheter i hjemmet. Men få vet vel at man kan faktisk gjøre noe med det selv (så fremt man er en utvikler). Mange smart-tver støtter HTML5 APPer og har API-er, SDK-er, samt dokumentasjon som er enkel å beherske.

Case for dette innlegget, er Samsung sine APIer for smartTV.
Jeg skal ikke i denne casen ta for meg alt man kan gjøre, bare noen ting jeg her og nå synes er fascinerende og en slags ièmyldring med meg selv på begge sidene av bordet.

Utviklingsguide

Samsung har en svært omfattende utviklingsguide, med gode skjermbilder. Her ser man alt fra hvordan man setter opp en emulator, til hvilke taster man kan bruke på et tastatur, som er tilkoblet. Alt i alt er det veldig lett å skumme seg gjennom manualen, jeg er svært positivit overrasket av hvor lettfattet dette er å sette seg inn i. Jeg liker særlig at de også viser hvordan man kan emulere en smarttv inne i Google Chrome, som betyr at man ikke nødvendigvis trenger å kjøpe en smarttv for å starte APPfabrikken sin.

Før man kommer så langt, bør man lese startguiden for å lage apps, samt UX-guide som tar for seg alt fra fontstørrelser til skalering fra 720P til 1080P, ytelsesprobelamtikk, vanlig visningsavstand, standardavvik i farger, fontstørrelser, linjelengde og mye annet som er relatert til UXD. Noen av eksemplene viser rèelle eksempler fra en demo APP man kan lese utviklerguiden av, nyhetsleseren.

Bilde i bilde

Hvis du ønsker å ha bilde i bilde (eller tvbilde inne i APPen din), kan man ganske enkelt finne eksempelkoden i dokumentasjonen til Samsung. Som man ser av eksempelet, er det svært få linjer kode, men dette forutsetter jo at man har bygget rammeverket rundt på forhånd.

Multi Screen SDK

Dette begrepet høres bedre og mer logisk ut på engelsk, det er i praksis en måte å muliggjøre APP på en telefon (IOS, Android, Windows eller hva som helst), som interagerer med SmartTV APPen gjennom en kanal man åpner for kommunikasjon. 

Jeg fikk umiddelbart her idèer som at man kunne utnyttet NFC-leseren  til å interagere med APPen man lager i SmartTVen. I tillegg kan man selvsagt bruke kamera med QR-koder, eller sosial deling gjennom SmartTVen. Jeg tenker at litt av akkilleshælen til dagens Smarte TVer, er at å taste inn tekst på en vanlig fjernkontroll er noe herk! Med Multi Screen SDK, kan man selvsagt sende tekst/data fra telefon, nettbrett eller PC. Inndatamulighet som ikke føles som sirup, endelig!

Men hvorfor stoppe der? 

Kontekstualiserte APPer i SmartTVen din

Hva med å bruke Android Tasker for å automatisere APPer du har på smarttven din, for eksempel kan du slå på TV-en, bytte til riktig kanal og så starte APP-en din og få bilde inn i APPen. Kanskje du vil aggregere nyhetsstrømmer inn i en ny flate, der du også kan se på din favorittkanal, i det du kommer inn døren :) 

Man må møte brukerne der brukerne ønsker å møtes - og hvem ønsker ikke å bli møtt i døren?

Det krever ikke all verden utvikling, men for å fjernstarte APPer, må du registrere APPen i DIAL-registeret. 

Hvis du flytter interaksjonen ut på din favoritt-telefon eller nettbrett, enten om den er IOS, Android eller Windows Phone, får du en flate som du selv har valgt. Du valgte selv din telefon, med mindre du var så heldig at du fikk den i jule- eller bursdags-gave, men det var nå egentlig en unødvendig digresjon.

Konseptet gjelder uansett, du kan bruke telefonen sine sensorer, alt fra temperatursensor, magnetsensor, digitalt kompass, gps, høydemåler, g-sensor og annet. Du kan høste informasjon fra fysiske objekter, for å utføre interaksjon i form av augmentert virkelighet, ved å bruke NFC-leser og kamera.

Mulighetene er uendelige og kanskje noen endelig lager en APP som alle vil ha.

Relaterte lenker

• Samsung sin SDK
• Dette er altså utviklingsmiljøet du bruker for å lage APPen
• Hovedutviklingsguiden fra Samsung
• Navet i din APPutvikling for Samsung SmartTVer
• BrightCove åpenkildekode Samsung SmartTV
• App (nr. 22 på listen)
• Rotten tomatoes åpen kildekode APP
• Filmsøk, enkel APP