Apputveckling i Linköping
Vi hjälper produktteam i Linköping att pröva och bygga en app som gör uppkopplad utrustning begriplig. Börja med att visa rätt enhet, rätt status och när informationen senast kom fram.
Läsbar status för en uppkopplad produkt
- Enhet
- Tid
- Status
Testfall: en tidigare status får inte presenteras som ny när anslutningen bryts. Skissen läser data; den skickar inga kommandon.
En uppkoppling är inte samma sak som ett användbart besked.
Linköping Science Park beskriver i en artikel från 2020 hur ACTIA i Mjärdevi arbetar med uppkopplade fordon och utrustning, insamling av information och diagnostik. Det är ett konkret lokalt exempel på produkter där ett gränssnitt behöver förklara data. Det säger inget om företagets nuvarande appbehov eller om ett samarbete med oss.
Vårt förslag till produktägare: pröva en läsande app för en avgränsad produkt. Användaren ska kunna välja sin enhet och skilja ett aktuellt besked från gammal eller saknad data. Styrning av maskiner, säkerhetslarm och automatiska diagnoser ingår inte i detta första flöde.
En app är relevant om användaren återkommer till produktens status eller behöver enhetens funktioner. Om uppgiften bara är att läsa produktblad eller skicka en offertfråga är en bra webbplats oftast rätt beställning.
Lokal bakgrund: Linköping Science Park: uppkopplade produkter i Mjärdevi. Källan visar ett användningssammanhang, inte ett uppdrag eller ett inköpsbehov hos den namngivna aktören.
Från avgränsning till körbar app.
Ett avgränsat läsflöde
Vi definierar vilken enhet användaren får se och vilket besked som hjälper i nästa steg. Ingen katalog av funktioner före behovstestet.
Prototyp med felstater
Pröva första användningen, saknad enhet, gammal data och avbrott med avsedda användare innan gränssnittet låses.
Avtal om produktdata
Bestäm identiteter, tidsstämplar, behörighet och vad varje status betyder tillsammans med systemägaren. Ett publikt exempel ger ingen API-rättighet.
Körbar första version
Bygg det överenskomna läsflödet med testdata och avtalad anslutning. Bluetooth eller andra enhetskopplingar kräver en separat teknisk prövning.
Test av åtkomst och tid
Verifiera att fel konto inte ser enheten och att gammal information förblir märkt även efter paus, omladdning och återanslutning.
Release och mottagare
Dokumentera drift, kod, beroenden och konton. Ange vem som tar emot fel när appen och produktens datatjänst utvecklas var för sig.
Pröva beskedet före kopplingen.
Samma enhet. Tre datalägen.
Definiera
Produktägaren bestämmer vad varje status betyder och när den inte längre är aktuell.
Simulera
Låt prototypen växla mellan ny, gammal och saknad data utan att röra fysisk utrustning.
Anslut
Först efter godkänt test kopplas en avtalad läsande datakälla till samma gränssnitt.
Fortsätt bara när användaren kan se skillnad på produktens tillstånd och appens anslutning.
Välj plattform efter uppgift.
Webbapp
Pröva länkbaserad åtkomst först när webben klarar funktionen. Även lagring och användning utan nät behöver provas i rätt miljö.
Delad kodbas
Pröva cross-platform när iOS och Android behöver dela flöde. Plattformarnas olika beteenden måste ändå testas.
Native
Separata appar blir relevanta när telefonens funktioner eller prestandakrav motiverar extra utveckling och förvaltning.
En mottagare för varje beslut.
Vi ansvarar för
- avtalat förarbete, prototyp och tekniskt bygge
- testunderlag, dokumentation och överlämning
- tydliga gränser för drift och release
Ni bidrar med
- produktägare och avsedda testanvändare
- rättigheter, godkänt innehåll och säkra testdata
- systemåtkomst, era konton och mottagare efter leverans
Vi utgår från Borås och arbetar främst på distans. Resor och möten kan planeras efter överenskommelse. Kod, konton, licenser och rättigheter dokumenteras i avtalet; tredjepartsvillkor behöver granskas separat.
Avgränsa innan ni beställer.
Prototyp och bygge
Omfattningen styrs av produktvarianter, datakällor, behörighet och plattformar. Ett läsande flöde offereras separat från styrning, hårdvara och säkerhetskritiska funktioner.
Förvaltning
Bestäm vem som bevakar ändrade API:er, produktversioner och mobilplattformar. Appförvaltning ersätter inte ansvar för utrustning eller säkerhetsklassning.
Vi lämnar förslag på pris och tid efter avgränsning. Inga belopp, leveransveckor eller externa godkännanden garanteras på förhand.
Inför er första beställning.
Kan ni styra vår utrustning från appen?
Inte inom det här föreslagna första flödet. Vi avgränsar en läsande vy. Styrning, larm och säkerhetskritiska beslut kräver separat kompetens, riskanalys och avtal innan något kan utlovas.
Måste det bli en native-app?
Nej. Vi prövar en webbapp om en länk och en avtalad datatjänst räcker. Åtkomst till exempelvis Bluetooth eller bakgrundsfunktioner behöver testas på avsedda telefoner före teknikvalet.
Har ni byggt ACTIA:s appar?
Nej, vi använder inte ACTIA som kundcase. Science Parks artikel är lokal bakgrund till ett föreslaget användningsområde. Den bevisar varken ett uppdrag för oss eller ett aktuellt inköpsbehov hos ACTIA.
Hur arbetar ni med oss i Linköping?
Vi utgår från Borås och arbetar främst på distans. Fysiska möten kan planeras efter överenskommelse när uppdraget motiverar det. Vi påstår inte att vi har ett lokalt kontor i Linköping.
Vad behöver ni för att lämna en offert?
En avgränsad användaruppgift, ett anonymiserat dataexempel, valda plattformar och en ansvarig systemägare. Pris och tid bestäms efter att åtkomst och beroenden har prövats.
Avgränsa er statusvy.
Beskriv produkten, vem som ska läsa statusen och vilket beslut beskedet ska stödja. Ta med ett anonymiserat dataexempel och vem som kan godkänna åtkomst. Vi börjar med omfattning och testbarhet, inte ett löfte om integration.