Table of Contents
Az elmúlt 3 hónapban egy nagyon érdekes projekten dolgoztam, amelynek keretein belül egy mobil applikációt készítettünk.
Ennek az applikációnak képesnek kellett lennie arra, hogy több típusú műszert vezéreljen, úgy, hogy a háttérben az eszközök egy eszközként vannak számon tartva, annak érdekében, hogy egyszerűbb legyen a munka velük.
Ezek a műszerek arra lettek kitalálva, hogy anyagösszetételt vizsgáljanak, legfőképp nedvességet. A műszert leginkább a föld és beton nedvességtartalmának a mérésére használják. A beton minősége fontos olyan országokban, ahol a népsűrűség nagyon nagy és az épületek minősége létfontosságú, pl: India. Ezekben az országokban törvény mondja ki, hogy milyen lehet a beton nedvességtartalma.
Maga a műszer két részből áll.
- A kommunikációért felelős modul, amely egy hídként szolgál az applikáció és a mérőműszer között.
- A mérőműszer, amit a különböző anyagokba helyeznek bele.
Hogyan mérik a beton minőségét?
A kliens azzal a szándékkal keresett fel minket, hogy a régi és elavult applikációit frissíteni szeretné. Az eddigi megoldás két különálló applikációt jelentett két mérőműszer számára. Mivel az, hogy több applikáció van több modulra, nem tetszett nekünk, ezért úgy döntöttünk, hogy mindent egy kalap alá hozunk, és egy applikáción belül lehet vezérelni az összes műszert.
A műszerek mellé kaptunk részletes technikai dokumentációt, amely leírja, hogy a Bluetooth kapcsolaton keresztül, hogyan vezérelhetjük. Ezen felül megkaptuk az előző applikációk forráskódját.
- Első két hét
Az első fontos lépésünk a mérőműszer működésének a megértése és implementálása volt, POC (proof of concept) formában. Ekkor körvonalazódott bennünk, hogy hogyan lenne érdemes felépíteni a mérési folyamatot, majd ezt felhasználva elkészítettük az első prototípus design-ját.
- Második három hét
A klienssel való többszörös iteráció után megszületett a design, amit elkezdtünk felépíteni. A második három hét végére, az applikáció alkalmas volt arra, hogy Androidon és iOS-en is stabilan működjön, ami azt mutatja, hogy az első mérföldkőig gyorsan elértünk és prezentáltuk is a kliensnek. Ekkor éreztem azt, hogy a projekt jó úton van.
- Harmadik két hét
A klienstől érkezett visszajelzés alapján jól haladtunk, viszont volt egy pont benne, ami egy kicsit megijesztett. A pont szerint, minden mérés után le kell csatlakozzunk a műszerről. Ezt akkor nem nagyon akartam elfogadni, mivel egy hangszóróról sem csatlakozunk le minden zene után. Ekkor tanultam meg a projekt legfontosabb tanulságát számomra. Amennyiben, olyan eszközzel dolgozunk, aminek van CE tanusítványa, abban több mint valószínű, hogy le van írva, hogy hogyan kell a kapcsolatot kezelni. Na ez a pont a projekt kezdeténél kimaradt, így maga a kód szerkezete ezt nem tette lehetővé. Ezért kénytelenek voltunk pár módosítást eszközölni az applikáció működésén.
- Negyedik három hét
Az utolsó három hétben design, illetve logikai változtatásokat eszközöltünk, amelyet egy mindent átfogó teszteléssel zártunk.
Kihívások és célok
- Egy olyan applikáció elkészítése, amely Bluetooth segítségével képes több műszert kezelni, függetlenül a műszer típusától.
- Egy olyan applikáció elkészítése, amelyet könnyű és magától értetődő használni.
- Minden mérési adat tárolása az eszközön, amelyet ki lehet exportálni excel táblákba.
Megoldások
Az applikációt React-Native-ben készítettük hibrid formában, amely egy monorepoban kapott helyet.
A hibrid formát, úgy értem, hogy a műszerekkel való kommunikációt platform specifikus módon implementáltuk. Android esetében Java-ban, iOS esetében Swift-ben, ezeket az API-okat JSI (Javascript Interface) keresztül kezeltük. Az eszközök kezelését abstract módon valósítottuk meg, amely alatt azt értem, hogy létezik egy fő osztály, amelyben definiálva vannak az alapvető műveletek az eszközökkel. Viszont, vannak olyan műveletek, amelyek függnek a műszertől, ezért ezeket a függvényeket abstractként definiáltuk, majd ezzel az osztállyal egészítettük ki az eszközök osztályait.
Devices
├── DeviceAbstractionLayer.java|swift
├── Device1.java|swift
└── Device2.java|swift
Az adatok tárolására Realm adatbázist használtunk, amely ennek a felhasználásnak tökéletesnek bizonyult.
Utólag visszatekintve, ezt C++-ban is készíthettük volna, hiszen akkor még nagyobb szerepet kaphatott volna a kód megosztása. De a következőkben ezt észben fogom tartani.
Tanulságok
Technikai szempontból egy nagyon érdekes projekt volt, hiszen megtanulhattam, hogyan lehet hatékonyan kommunikálni külső eszközökkel, és ezt platform nyelven megírva.
Ebből a projektől nagyon sok új dolgot tanultam.
Projekt menedzsment szempontból azon kívül, hogy a kommunikáció milyen fontos és miért kell mindent leírni, azt tanultam, hogy miért nézzek utána a CE tanúsítványnak, ha hardware-rel dolgozok.
Következtetés
Összességében a projektből sok új tapasztalatot szereztem, amit a későbbiekben fel tudok majd használni, mint a projekt menedzsment részét, mint a technikai részét.
Igyekeztem a legérdekesebb részleteket kiragadni a projekt életéből, remélem hasznosnak találod.