Tworzenie aplikacji serwera i zdalnego interfejsu użytkownika na Androida

Witam.

Potrzebuję pomocy przy obmyśleniu koncepcji sposobu funkcjonowania pewnego zagadnienia
Plan jest taki. Chcę stworzyć aplikację główną, która będzie uruchomiona na komputerze pracującym 24h/7. Pomijam tutaj kwestię sprzętową, w każdym razie będzie to coś przystosowanego do pracy ciągłej. Aplikacja ta można powiedzieć, że będzie pełniła funkcję takiego jakby serwera, a więc będzie odpowiedzialna z wykonywanie całej logiki. Nie będzie posiadać interfejsu użytkownika ale użytkownik będzie miał wpływ na jej działanie, tylko, że zdalnie, przez internet.
I właśnie tutaj mam zagwozdkę. Bo chciałbym stworzyć drugą oddzielną aplikację na system Android, pełniącą właśnie funkcję interfejsu użytkownika. Użytkownik będzie mógł w tej aplikacji odczytywać różne parametry, ale też dokonywać zmian. I tutaj się zastanawiam jak to wykonać? Myślałem czy by nie zrobić tego na zasadzie pulpitu zdalnego, czyli aplikacja serwera generowała by interfejs który byłby jakoś przesyłany w postaci obrazu do aplikacji "klienta", czy lepiej aby aplikacja "klienta" miała całą logikę sterowania i wysyłała tylko parametry do serwera? Kurde, nie wiem jak to opisać czytelnie

Przesyłanie obrazu wymaga większej ilości danych, niż przesłanie samej informacji. I wymagałoby tworzenia tego obrazu na serwerze. Może prościej będzie zainstalować serwer WWW i używać skryptów PHP, a od strony klienta przeglądarki WWW? Wtedy nie potrzebujesz pisać aplikacji klienta, bo pewnie ten Android ma przeglądarkę.

Dobrze byłoby pomyśleć o weryfikacji użytkownika - żeby ktoś obcy nie poprzestawiał parametrów. Pamiętaj, że jeśli przesyłasz hasło przez medium publiczne, to ktoś może podsłuchać i użyć. I może określ, jakie masz ograniczenia - np. jakich portów i protokołów możesz używać. Nie znam Androida, nie wiem, na co pozwala. A serwer jaki ma mieć system?

Wrzucę ci kilka myśli (zastzregam, nie w pełni rozumiem):
a) aktualizacja i rozwój systemu. Czy / na ile cię stać aby użytkownicy często aktualizowali apkę androidwą. Jak nie są techniczni, i są daleko, to mzoę być problem. Jak widzisz, argument za stroną serwera obciążona logiką.
Co, gdy ktoś łaskawie NIE ZAKTUALIZUJE ?

b) integralność biznesowa (tak naprawdę, to kilka poziomów integralności) . Wartość faktury musi być różna sumie pozycji. Pozycje mogą zawierać tylko istniejące (czy dozwolone) towary itd. Ma się zrobić poprawna, sensowna operacja, albo wcale. Żadnej "samoobsługi na skróty":

Często używam anegdoty o okienku w restauracji między sala i kuchnią. Potrawy sie zamawia, czasem z uwagami o różnicach (mizeria zamiast surówki proszę), ale odpowiada kucharz. Co by było, gdyby ludkowie kręcili się sami po kuchni, nawet w dobrej wierze?

Mało wiem o Tobie i projekcie, może bym podrzucił jakieś pomysły i analogie
gruby klient, cienki klient, www, współcześnie jest wiele opcji.

Dodano po 3 [minuty]:

@_jta_

Troszkę za bardzo poziomem fizycznym operujesz, to nie ten etap moim zdaniem.

Czy będzie lepiej, to zależy, jakie są kryteria. Ale myślę, że przesyłanie obrazu wymaga takiego transferu danych, że wrażenia będą fatalne (podobne jak z używania czegoś na pulpicie zdalnym).

Czy to naprawdę ma działać przez Internet? Czy serwer jest osiągalny z Internetu (ma publiczne IP)? Jakie tam będzie środowisko, system?
Nie lepiej, żeby aplikacja dla klienta była webowa zamiast androidowa?

W sumie to daliście mi do myślenia z tym aby interfejs użytkownika był w formie strony www. Natrafiłem tym samym na coś takiego jak aplikacje PWA. Wygląda spoko, bo można odpalić zarówno na smartfonie jak i na komputerze. Ktoś się tym interesował? Jest jakieś IDE do tego czy wszystko trzeba w notatniku pisać?

Tak jak opisywałeś na początku możesz zrobić aplikację na Androida pełniącą jedynie funkcję interfejsu użytkownika oraz aplikację serwerową, która będzie odpowiadała za logikę i dostęp do danych. Te dwie aplikacje musisz połączyć za pomocą jakiegoś protokołu.
Możesz poczytać o mechanizmach zdalnego wykonywania procedur - RPC. Są gotowe biblioteki np. Thrift lub CORBA.
Możesz też zdefiniować własny protokół, korzystając z xml, json lub google protocol bufers i puścić go przez TCP. Lub skorzystać z REST api, czyli komunikatów protokołu http czy https.
Ale chyba rzeczywiście interfejs przeglądarkowy miałby najwięcej zalet. Wszystko zależy od oczekiwań co do tego GUI.

@rafels

Ładnie to wyłozyłeś.
Pomysł zaliczyć można do "cienkiego klienta" czyli "thin client"

Kilka drobnych uzupełnień.
CORBĄ już od lat się nie obraca. Wręcz straszy się Corbą młodych programistów "jakie złe było RPC". Nie złe jest RPC jako idea, ale niektóre implementacja zdecydowanie tak.

Najbliższą konkurencją Thrifta (znam go mogę powiedzieć nieźle) jest gRPC, a 'g' w tym skrócie to Google Protocol Buffers (który sam w sobie jest tylko protokołem serializacji - anlizowałem te dziedziny
mocno)
Bardzo fajne biblioteki, chyba najwięcej dają jak sprzęgamy języki kompilowane (Java, C#, nieco więcej wysiłku C++). Trochę mniej, jak np server side jest w Pythonie czy słabo z PHP

RPC vs REST to zupełnie inne patrzenie na dynamikę, mogę o tym gadać godzinami, ale nie o tym wątek.

@Michal_212
Po stronie serwera zrób sobie API

https://devszczepaniak.pl/wstep-do-rest-api/
https://code.tutsplus.com/pl/tutorials/android-from-scratch-using-rest-apis--cms-27117

Linki przykładowe tak żebyś wiedział o czym piszę.

I komunikujesz się z klienta z serwerem. Masz uniwersalne API zapewniające komunikacje a warstwę graficzną robisz jak Ci się podoba.
A w razie czego możesz i szczoteczkę do zębów z wifi oprogramować jako klienta tego API.

rafels napisał:

Możesz poczytać o mechanizmach zdalnego wykonywania procedur - RPC. Są gotowe biblioteki np. Thrift lub CORBA

Corbe można spotkać już chyba tylko w starym zaśniedziałym 20-letnim bankowym systemie. Nawet z JDK zostało wyrzucone wsparcie. Teraz już w ogóle rzadko się korzysta z RPC, a w technologiach mobilnych w ogóle. Poza tym powodzenia w postawieniu brokera i skonfigurowaniu reszty.

-----------------------
Nawet jak zrobisz stronę www to i tak jest ona "uruchomiona" po stronie klienta (telefonu) bez względu na wybraną technologię. Musisz jakoś tę stronę skomunikować ze swoim backendem. Masz więc dwie opcje (jeżeli chcesz wspierać tylko Androida):

Piszesz aplikacje natywną w javie/kotlinie czym tam chcesz. Do tego masz super środowisko Intellij IDEA lub bardziej wyspecjalizowane Android Studio na jego bazie. W miarę szybko można stworzyć coś co jako tako wygląda. Tutaj ciężko konkretnie doradzić bo możliwości jest mnóstwo. To już pytaj jak utkniesz. Do tego musisz napisać backend, który będzie uruchomiony na serwerze. Tutaj języków jest mnóstwo. Jeżeli to jakieś proste rzeczy to może być i python, przy bardziej skomplikowanych skłaniałbym się w stronę czegoś "bezpieczniejszego". Też wszystko zależy. Musisz pamiętać o kompatybilności wstecz po stronie backendu jeżeli ma być dużo użytkowników przy takim rozwiązaniu.

Inna opcja to strona www. Tu możesz wejść w jakieś JSP, JSF, ASP itd. Czyli generalnie strona serwowana z backendu, która zajmuje się komunikacją z nim. Trochę staroć, no ale jest Można też osobno klepnąć stronę tradycyjnie html+JS z odpowiednimi bibliotekami i komunikacja do backendu po REST.

Możliwości są miliony, kwestia kto tego będzie używał, ile ich będzie itd. itp.

Nie wiedziałem, że croba jest passe. Jeszcze niedawno była w użyciu w firmie w której pracowałem. Ale fakt, że to było już ładnych parę lat temu a i produkt nie był najświeższy. Wiec pewnie racja. Czas pędzi niezauważenie.
Jednak Thrifta używałem nie dalej niż 2 lata temu w sofcie, który jakoś teraz wchodzi na rynek. Ale to był złożony system z wieloma węzłami a nie aplikacja klient serwer.

Co do wyboru technologii, to jest ich mnóstwo i najpierw należało by poznać wymagania funkcjonalne i niefunkcjonalne aplikacji a dopiero później dobierać narzędzia.
Ale wydaje się, że autor tematu ma już tu pokaźny przegląd rozwiązań.

gaskoin napisał:

Teraz już w ogóle rzadko się korzysta z RPC, a w technologiach mobilnych w ogóle.

Jak dla mnie to wielka strata, RPC (nie wnikając w jakość implementacji) ma niepodważalne zalety (wady też, jak wszystko), nie powinien zniknąć. Zawsze powinna być panorama rozwiązań, nie monokultura.

REST w 3/4 przypadków jest restem zgwałconym, nie mającym nic wspólnego z ideą początkową (literka S oznacza State). trzeba wiele nałgać, aby Restem wyemulować ... RPC
Wg mnie to monokultura REST jest kulą u nogi, a nie złe czarownice czające się za RPC

BTW używam RPC Apache Thrift do integracji apki andoidowej z backendem ERP, i to jest bardzo dobry wybór z wielu powodów: CPU,, GC, pasmo sieci komórkowej, odwzorowanie procesów biznesowych, transakcyjnosć,

Straszny żargon... Czy autor tematu coś z tego zrozumie?

To, co zaproponował @_jta_ jest najsensowniejsze, jeśli chcesz autorze zakończyć to zadanie w ciągu roku. Postaw serwer www na komputerze, skonfiguruj go, dodaj ewentualne uwierzytelnianie i udostępnij dane (np. PHP), a aplikację po stronie telefonu już masz (przeglądarka). Odpada ci wtedy połowa pracy.

JacekCz napisał:

gaskoin napisał:

Teraz już w ogóle rzadko się korzysta z RPC, a w technologiach mobilnych w ogóle.

Jak dla mnie to wielka strata, RPC (nie wnikając w jakość implementacji) ma niepodważalne zalety (wady też, jak wszystko), nie powinien zniknąć. Zawsze powinna być panorama rozwiązań, nie monokultura.

REST w 3/4 przypadków jest restem zgwałconym, nie mającym nic wspólnego z ideą początkową (literka S oznacza State). trzeba wiele nałgać, aby Restem wyemulować ... RPC
Wg mnie to monokultura REST jest kulą u nogi, a nie złe czarownice czające się za RPC

Nie chcę wchodzić w takie tematy. Dla mnie są bardzo ciekawe i można dyskutować godzinami, ale dla autora to offtop. Pracujemy pewnie w tej samej branży i sam pewnie widzisz i wiesz, że wydanie agilea, resta, programowania obiektowego, Continous Integration, Continous Delivery itd. itp. to jeden wielki samogwałt Złą czarownicą czającą się za RPC z reguły byli programiści niepotrafiący oddzielić api od implementacji. REST częściowo rozwiązał ten i inne problemy, ale wprowadził nowe

Mimo wszystko REST jest najsensowniejszą opcją w przypadku integracji mobile/backend. Thrift mi się bardzo podoba i w idei i w wykonaniu, ale przemysł nigdy nie dorośnie do takich rozwiązań.

@_jta_ żargon jest powiedzmy... techniczny Można wygooglać wszystkie pojęcie. Problem polega na tym, że jest bardzo dużo możliwości rozwiązania problemu a autor nie zdradził więcej szczegółów. Można więc lać wodę godzinami używając różnych fancy technologii. Wciąż czekamy na SOAPa

Michal_212 napisał:

Jest jakieś IDE do tego czy wszystko trzeba w notatniku pisać?

Słyszałem, że ludzie nielubiący notatnika chwalą sobie Visual Studio Code. Jest też PhpStorm.

gaskoin napisał:

Nie chcę wchodzić w takie tematy. (...)

A to dobre

Stworzenie interfejsu w oparciu o stronę internetową wydaje się bardzo dobrym pomysłem, tym bardziej, że można by zrobić to w formie aplikacji webowej. Po dostrzeżeniu korzyści i zachęceniu przez kolegów do tego rozwiązania, postanowiłem obejrzeć kilka poradników związanych z tworzeniem aplikacji internetowej z wykorzystaniem ASP.NET. Co ciekawe można pisać w Visual Studio, z wykorzystaniem C#.
Niestety filmiki, które obejrzałem uświadomiły mnie tylko w tym, że to jest za skomplikowana sprawa i nie będę w stanie jej podołać Nie dość, że pisanie tego typu aplikacji jest bardzo skomplikowane, trzeba tworzyć jakieś kontrolery, itp to jeszcze potrzebna jest baza danych, nie mówiąc już o fakcie, że stworzenie interfejsu graficznego strony to dla mnie abstrakcja i się w tym gubię
Jednak porzucę pomysł tworzenia tej aplikacji bo aż tyle wiedzy nie posiadam W każdym razie dzięki za zainteresowanie

A znasz już jakiś język programowania? Np. W Pythonie jest sporo frameworków webowych, często łatwiejszych na start niż .NET.
Co do strony www to wystarczy trochę podstaw html+css. Jak byś chciał uczynić stronę bardziej dynamiczną, to przyszedł by czas na naukę JavaScript.
Warto poznać takie rzeczy 😃

CSS niekonieczny - to do takich "wodotrysków". Podstawy HTML koniecznie. I trzeba zdecydować, czy ma być automatyczne odświeżanie (jest taka książka "Dynamiczny HTML", w której to opisano), bo sama strona jest statyczna: otwierasz, coś się wyświetla i już takie pozostaje, żeby się odświeżyło i pokazały się nowsze informacje, trzeba kliknąć "odśwież" przeglądarki (stronę z prognozą pogody IMGW zrobili tak, że się nie odświeża - jak nie kliknę "odśwież" przeglądarki, to strona może mi pokazać prognozę np. sprzed miesiąca).

Ogólnie rzecz biorąc to chciałem zbudować aplikację pełniącą rolę interfejsu do sterowania automatyką domową własnej budowy. W skrócie, w domu jest komputer pracujący 24/7, uruchomioną aplikacją, którą jeszcze tworzę i która odpowiada za całą logikę, tzn. sterowaniem oświetleniem, zbieraniem danych z czujników, wykonywaniem zdarzeń, harmonogramów itp. Chcę mieć do tego dostęp przez internet i najlepiej z poziomu smartfona, dlatego pomysł stworzenia całego interfejsu w formie strony internetowej wydawał się być dobrym rozwiązaniem, bo mógłbym sterować też z poziomu zwykłego komputera podłączonego do sieci jak i z poziomu smartfona. Tym bardziej, że przewinął się pomysł aplikacji webowej gdzie na smartfonie można do niej by utworzyć skrót na ekranie, a z tego co czytałem to możliwe jest też generowanie powiadomień, więc jeszcze lepiej. Tylko widzę, że stworzenie czegoś takiego nie jest takie proste jak by mi się wydawało. Może faktycznie nie potrzebnie myśałem o ASP.NET i dało by się to zrobić jakoś inaczej. Ta strona/aplikacja internetowa w moim przypadku miałaby robić tylko za sam interfejs, cała obsługa zdarzeń i ogólnie logika automatyki odbywać się ma w aplikacji "serwera".
Dla przykładu, ja potrzebuję np. stronę główną z kilkoma buttonami, gdzie po wciśnięciu jednego z nich idzie informacja do serwera, że przycisk został wciśnięty, serwer wtedy np. odczytuje temperaturę z pomieszczenia X i wysyła jej wartość do odpowiedniej "kontrolki" na stronie internetowej.
Albo inny przykład, po uruchomieniu strony internetowej pojawiają się pola do logowania, wpisuję login, hasło, a po wciśnięciu buttona, dane te lecą do aplikacji serwera, ona sprawdza czy taki użytkownik istnieje i udziela mu dostępu do dalszego sterowania automatyką. Nie wiem czy dobrze to zobrazowałem ale chodzi mi o to, że całą logiką zajmowałaby się moja aplikacja serwerowa.

@_jta_ wystarczy odświeżać stronę przez tag meta nie trzeba od razu robić nie wiadomo czego. Tym bardziej jeśli to pierwszy projekt.

Ja bym proponował poszukać albo nawet kupić gotowy szablon strony i go zmodyfikować pod swoje potrzeby. Do tego dodać tylko obsługę wywołań http do serwera. Jeżeli chcesz sam pokleić to polecam https://getbootstrap.com/. Z ASP czy podobnymi frameworkami jest taki plus, że projekt "serwera" i strony dla użytkownika to jedno i to samo, bo strony wysyła część serwerowa i dość łatwo to zintegrować. Niektóre środowiska dają też możliwość wyklikania sobie interfejsu. Nie będzie pięknie, ale będzie

Mimo wszystko obsługa sesji logowania, integracji z całą resztą itd itp pewnie zajmie Ci niejeden wieczór

Sam Sung napisał:

gaskoin napisał:

Nie chcę wchodzić w takie tematy. (...)

A to dobre

No dobra, chcę, ale nie mogę

Tak się składa, że popełniłem kiedyś podobny system, i wciąż go rozbudowuję i używam. Opisałem jego architekturę kiedyś zdawkowo w tym poście: https://www.elektroda.pl/rtvforum/topic2711155.html#14817584 - od tego czasu "trochę" się pozmieniało (np. całkowicie hosting i GUI), ale architektura backendu wciąż się sprawdza.
W razie, gdyby akurat moje rozwiązanie wydało się interesujące, to służę szczegółami.
Jak widać, możliwości jest mnóstwo, a każdy zachwala to, z czym kiedyś miał do czynienia.
Przede wszystkim powinieneś sobie odpowiedzieć na pytanie, czy wytrzymasz np. tydzień roboczy programowania bez widocznych efektów Jeśli tak, to sukces prędzej czy później gwarantowany.

Witam,
Nie myślałeś użyć jakiegoś istniejącego systemu do swojego projektu? Takie przychodzą mi do głowy (w kolejności alfabetycznej): Blynk, Domoticz, Home Assistant, OpenAHB.

Pozdrawiam.

mpier napisał:

Nie myślałeś użyć jakiegoś istniejącego systemu do swojego projektu? Takie przychodzą mi do głowy (w kolejności alfabetycznej): Blynk, Domoticz, Home Assistant, OpenAHB.

Myślałem, nawet przymierzałem się zintegrować mój system z Suplą, ale jej główną wadą jest to, że działa w oparciu o WiFi, a ja potrzebuję w głównej mierze skomunikować różne moduły przy pomocy RS485. Na te systemy o których kolega pisze nie natrafiłem i nie wiedziałem, że istnieją. Powiem szczerze, że byłbym skłonny skorzystać z czegoś gotowego i połączyć z tym co już mam Czy kolega może korzysta z którego? Bo chciałbym się dowiedzieć czy one są bardziej na zasadzie - kupić gotowe moduły i podłączyć czy może jest możliwość wykorzystać własnoręcznie wykonane modułu, oczywiście po odpowiednim zmodyfikowaniu wsadów?

Kiedyś zainstalowałem blynka, ale widzę, że lokalny serwer przestał być rozwijany. Myśle, że do szybkich testów użyłbym teraz Node-RED. Oparte jest to o Node.js, które pewnie byś odkrył budując własną aplikację (było w poprzednich postach o REST). Wymienione systemy są otwarte i obsługują różne protokoły.