Italian [B4A] quale approccio

giannimaione

Well-Known Member
Licensed User
Longtime User
buongiorno brava gente;
non rubate la mia idea :)

ho una applicazione win desktop (NO B4X);
questa applicazione win può comunicare tramite socket con un dispositivo android (per esempio un tablet);
l'applicazione win invia una stringa tipo "aranciata 1,50€" oppure "caramelle 2,25€" ed ancora "farina 1kg 0,98€" ..... ;
ogni invio ha in intervallo diverso (dipende dall'operatore che sta alla cassa del negozio), quindi qualche secondo tra un invio e l'altro;
bisogna considera anche un periodo di "fermo"... non c'è nessun cliente alla cassa;
TUTTO QUESTO SULLA POSTAZIONE CASSA E CON UNA APPLICAZIONE WIN NON B4X;

ho creato una demo in B4A che riceve la stringa tramite socket e sembra funzionare;
ora dovete mettere in campo tutta la vostra esperienza, le vostre conoscenze e la vostra pazienza per analizzare questi punti:
1) l'app win apre una connessione, verifica la stato di connesso, invia la stringa e chiude la connessione?
questo flow avviene ad ogni "lettura" dell'articolo presente nel carrello della spesa
2) l'app b4a è in attesa di stabilire una connessione socket con l'app windows?
3) a connessione avvenuta e successiva ricezione della stringa, chiudo la connessione?
4) devo scambiare un messaggio di avvenuta ricezione tra la due applicazioni ?

tutto questo per creare una app B4A che possa visualizzare / presentare una sorta di "ANTEPRIMA SCONTRINO" e con l'integrazione di TTS in modo da avere uno
SCONTRINO PARLANTE
 

LucaMs

Expert
Licensed User
Longtime User
visualizzare / presentare una sorta di "ANTEPRIMA SCONTRINO"
Ti vendo la mia, sviluppata 7 anni fa (malgrado questo, migliore 😄 )


P.S. Ma non ho capito... secondo te la cassiera dovrebbe usare un'applicazione Windows Desktop per mandare al cliente (app del cliente) una stringa contenente i dati dell'articolo che il cliente ha messo nel proprio carrello?
 
Last edited:

Star-Dust

Expert
Licensed User
buongiorno brava gente;
non rubate la mia idea :)

ho una applicazione win desktop (NO B4X);
questa applicazione win può comunicare tramite socket con un dispositivo android (per esempio un tablet);
l'applicazione win invia una stringa tipo "aranciata 1,50€" oppure "caramelle 2,25€" ed ancora "farina 1kg 0,98€" ..... ;
ogni invio ha in intervallo diverso (dipende dall'operatore che sta alla cassa del negozio), quindi qualche secondo tra un invio e l'altro;
bisogna considera anche un periodo di "fermo"... non c'è nessun cliente alla cassa;
TUTTO QUESTO SULLA POSTAZIONE CASSA E CON UNA APPLICAZIONE WIN NON B4X;

ho creato una demo in B4A che riceve la stringa tramite socket e sembra funzionare;
ora dovete mettere in campo tutta la vostra esperienza, le vostre conoscenze e la vostra pazienza per analizzare questi punti:
1) l'app win apre una connessione, verifica la stato di connesso, invia la stringa e chiude la connessione?
questo flow avviene ad ogni "lettura" dell'articolo presente nel carrello della spesa
2) l'app b4a è in attesa di stabilire una connessione socket con l'app windows?
3) a connessione avvenuta e successiva ricezione della stringa, chiudo la connessione?
4) devo scambiare un messaggio di avvenuta ricezione tra la due applicazioni ?

tutto questo per creare una app B4A che possa visualizzare / presentare una sorta di "ANTEPRIMA SCONTRINO" e con l'integrazione di TTS in modo da avere uno
SCONTRINO PARLANTE
Non c'è nulla da copiare, é un idea vecchia come la cicca, una cosa così l'ho fatta 5 anni fa e pubblicata su Google Play, senza scontrino parlante ... questione di privacy. Lo scontrino gli arrivava in pdf su Whatsapp
 
Last edited:

Star-Dust

Expert
Licensed User
Comunque se non vuoi tenere la connessione sempre aperta usa UDP, mando pacchetto e conferma di ricevimento.

altrimenti ci deve essere un server. L'App della cassa può essere il sw desktop su Windows. tutti i dispositi si collegano al server e mantengono la connessione fino a conclusione. la conferma di ricezione è importante io farei un ping dove chi riceve risponde inviando l'ok e un checksum.

Comunque ci vogliono maggiori dettagli. L'App mobile è su dispositivo privato del cliente o fisso nell'esercizio?

Mandando i prezzi crea un cartellino virtuale collegato a un cliente che presentandosi alla cassa paga?
 
Last edited:

giannimaione

Well-Known Member
Licensed User
Longtime User
nessuna idea da rubare;
un dispositivo android fisso in prossimità del nastro trasportatore della cassa;
vorrei che il cliente potesse "vedere e sentire" le informazioni (descrizione e prezzo) dell'articolo/i che la cassiera sta "passando" sull'applicazione desktop;
quindi niente pdf, niente dispositivo cliente, niente whatsapp;

nelle grandi distribuzioni esiste già; ci sono le casse dove l'acquirente esegue la lettura dei prodotti in modalità self;
per quanto riguarda il "colloquio" tra app desk e app andoid posso anche considerare il fatto che il dispositivo android possa essere collegato tramite UBS al pc win (se questo semplifica il tutto)
ho considerato anche una cartella condivisa dove il pc win scrive le info in un file txt.....
Ti vendo la mia, sviluppata 7 anni fa (malgrado questo, migliore 😄 )
how much?
 

Star-Dust

Expert
Licensed User
Quindi un semplice "schermo"/"audio" secondario (esterno) che fa vedere ciò che è stato battuto e a voce ti dice cosa hai comprato.

Es. dice: Anticoncezionali confezione da 48 pezzi, costo 50euro. E appare sullo schermo del Dispositivo il prezzo e il nome del prodotto (certo che poi la gente ti guarderebbe come uno appena uscito di prigione che si deve rifare)

Io personalmente userei UDP, ma una connessione stabile va bene li stesso.
USB, bluetooth o altro credo complicherebbe.
 
Last edited:

LucaMs

Expert
Licensed User
Longtime User
Es. dice: Preservativo confezione da 48 pezzi, costo 500euro. E appare sullo schermo del Dispositivo il prezzo e il nome del prodotto (certo che poi la gente ti guarderebbe come uno appena uscito di prigione che si deve rifare)
A oltre 10€ l'uno, più che altro la gente ti vedrebbe come uno scemo 😄

how much?
La mia è tutt'altra cosa; ed è arcaica, sviluppata coi mezzi di allora.
La feci solo per giocherellare con la funzionalità scanner; poi, in realtà, sarebbe stata molto utile (mai usata, nemmeno da me) anche per gestire tutte le proprie spese e scadenze (ma anche le scadenze delle uova, che butto molto spesso, o della carne congelata!), per statistiche sulle spese, per sapere dove acquistare lo stesso prodotto o analogo a prezzo migliore.
 

udg

Expert
Licensed User
Longtime User
Per la cassa puoi pensare a PC con secondo schermo "di cortesia". In un caso del genere, tra l'altro, le due schermate non devono essere necessariamente identiche.
Io adottai questa soluzione per lo stadio del Lugano calcio e ha funzionato benissimo. In quel caso mi ero ritrovato (nel senso che ne avevano già una ventina) un PC Windows con il doppio schermo ed il sw fu quindi scritto in B4J.

Se cerchi, trovi anche dispositivi Android con il doppio schermo, ma molti si limitano a proporre lo stesso contenuto su entrambi i monitor. Alcuni sono molto belli esteticamente.
Sempre in ambito Android, se vuoi risparmiare all'osso, prendi due tablet da 80 euro, uno fa da "server" ovvero da cassa (nel tuo caso) e l'altro si limita a ricevere tramite socket in wi-fi stringhe che poi mostrerà tramite grafica carina al cliente.
In assenza di wi-fi (o non potendo contare su quello del negozio), aggiungi ai due tablet un ESP32, ne attivi la funzionalità relativia (DHCP server) e crei così una micro-rete tra i due tablet e l'ESP (che potrebbe fornire anche pagine pubblicitarie tra un cliente e l'altro). Volendo uno stesso ESP ti gestisce più punti cassa, ma a quel punto devi ricordarti di configuare gli indirizzi delle coppie cassa-cortesia in modo opportuno (ovvero in modo che ognuno mostri il contenuto corretto).
 

giannimaione

Well-Known Member
Licensed User
Longtime User
Per la cassa puoi pensare a PC con secondo schermo "di cortesia"
si ho pensato anche a questo, ma "posizionare" un schermo (cavo alimentazione, caso segnale, supporto, ecc) risulta complicato rispetto ad un tablet;
non ho evidenziato che il tutto si base anche con l'uso della connessione wi-fi del negozio (è avvio);
Io personalmente userei UDP,
scusa se la mia conoscenza non è superiore alla tua, ma ....UDP! chi era costui?;
differenza tra UDP e websocket ???
Preservativo confezione da 48 pezzi, costo 500euro.
non concordo; noto, anche in presenza di regole di distanziamento sanitario, una calca alle casse e quindi "ciao ciao privacy e covid";
le casse self "parlanti" sono presenti ormai nei market della grande distribuzione, quindi non solleverei questo problema;
 

Star-Dust

Expert
Licensed User
non concordo; noto, anche in presenza di regole di distanziamento sanitario, una calca alle casse e quindi "ciao ciao privacy e covid";
le casse self "parlanti" sono presenti ormai nei market della grande distribuzione, quindi non solleverei questo problema;
E' un mio punto di vista, a me non piacerebbe che altri possano sentire cosa ho comprato, adesso che devono essere distanti e non vedono perchè dovrebbero sentire .... Carta igienica CartVetrata da 10 rotoli piuttosto che Crema Ascellare Anti_puzza.....
Ma ripeto è una mia umile opinione, ma molto umile

scusa se la mia conoscenza non è superiore alla tua, ma ....UDP! chi era costui?;
differenza tra UDP e websocket ???
Nemmeno la mia è superiore alla tua, ma con internet ci ho sbattuto il muso per diversi anni.
UDP a differenza di TCP è un pacchetto che non richiede connessione, si manda e basta.... ma bisogna verificare l'arrivo perchè non avendo connessione non c'è un check di controllo ne dell'ordine di arrivo.
WebSocket o Socket normale o siti internet usano il protocollo TCP/IP

Erel ha dato un esempio in cui con pacchetto UDP il server invia il proprio indirizzo in broadcasting a tutta la sottorete e i client apprendono l'indirizzo IP del server ascoltando i pacchetti UDP in una porta specifica.

E simile a BLE di bluetooth, si lancia un segnale (un Faro nella notte) e tu (se sei in ascolto) lo ricevi
 
Last edited:

giannimaione

Well-Known Member
Licensed User
Longtime User
non potendo utilizzare UDP (il software desktop NO B4X, utilizza una connessione socket ... SOCKET = OPEN.SOCKET(IPClient, 3000, SKT$BLOCKING) )
dove IPClient è l'indirizzo ip del dispositivo android in ascolto;
la domanda:
è possibile assegnare un indirizzo al ServerSocket ?
 

Star-Dust

Expert
Licensed User
Puoi impostare l'indirizzo IP della macchina che servirà da server dal sistema operativo
Ovviamente deve essere un indirizzo IP all'interno della maschera della sottorete

O Puoi impostare da router, se lo consente, L'IP di una specifica postazione.

_______________________
Aggiornamento: Ho riletto la domanda adesso da casa e ho capito meglio cosa chiedevi. In android se è collegato in WIFI puoi eliminare il DHCP e settare l'ip fisso sempre all'interno della sottorete. E' una cosa che gestisco con il s.o. android nelle impostazioni della rete, non da codice
 
Last edited:

Star-Dust

Expert
Licensed User
Però c'è una cosa che non ho capito, parli di Client che sta in ascolto ad una porta.
Quindi il programma client, ha un socket in ascolto come se fosse server?
 

LucaMs

Expert
Licensed User
Longtime User
Dettatura vocale. Ero con il telefonino
Certo, lo avevo intuito; era per sorridere e perché... non mi intendo di UDP e sono troppo pigro per cercare (perlomeno adesso), benché grosso modo sappia cosa sia (non so perché si possa preferire a TCP, visto che mi pare abbia solo limiti rispetto a questo secondo, ma fa lo stesso 😄).
 

Star-Dust

Expert
Licensed User
Certo, lo avevo intuito; era per sorridere e perché... non mi intendo di UDP e sono troppo pigro per cercare (perlomeno adesso), benché grosso modo sappia cosa sia (non so perché si possa preferire a TCP/IP, visto che mi pare abbia solo limiti rispetto a questo secondo, ma fa lo stesso 😄).
UPD è semplice. Dipende da cosa devi fare, spesso è usato per lo streaming audio/Video, VoiceIp, DNS...
 

Star-Dust

Expert
Licensed User
ApplicazioneProtocollo strato applicazioneProtocollo strato trasporto
Posta elettronicaSMTPTCP
Accesso a terminale remototelnetTCP
Trasferimento fileFTPTCP
WebHTTPTCP
Streaming Audio/VideoRTSP/RTPTCP (comandi) + UDP (flusso)
Server di file remotoNFStipicamente UDP
Telefonia su internet (VoIP)SIP, H.323, altritipicamente UDP
Gestione della reteSNMPtipicamente UDP
Protocollo di routingRIPtipicamente UDP
Risoluzione dei nomiDNStipicamente UDP
 

LucaMs

Expert
Licensed User
Longtime User
UPD è semplice. Dipende da cosa devi fare, spesso è usato per lo streaming audio.
Quando lessi 🐶, circa un migliaio di anni fa, che non c'era certezza di ricevere tutti i dati, che alcuni pacchetti potrebbero perdersi per strada, non ne volli più nemmeno sentir parlare :) (ecco perché non approfondii). Per me semplicemente UDP non esite (un po' come la tizia che disse: "Qui da noi non ce n'è coviddi" 😄)
 

giannimaione

Well-Known Member
Licensed User
Longtime User
Però c'è una cosa che non ho capito, parli di Client che sta in ascolto ad una porta.
Quindi il programma client, ha un socket in ascolto come se fosse server?
1) ho una applicazione windows "NO B4X" che invia una stringa tramite socket (in questo caso DEVO conoscere l'indirizzo IP del device android)
2) l'app android resta in attesa di ricevere i dati dall'applicazione windows (anche in questo caso devo specificare IP del pc windows, ma in questo caso gia conosco il valore)

in b4a ho utilizzato questo:
B4X:
client.Connect("192.168.1.50", port, 10000) 
Wait For Client_Connected (Successful As Boolean)
e poi il device resta in attesa di una connessione
B4X:
Private Sub ListenForConnections
    Do While working '  working as Boolean (in Process_Globals è TRUE)
        server.Listen
        Log("in ascolto")
        Wait For Server_NewConnection (Successful As Boolean, NewSocket As Socket)
        If Successful Then
            Log(Server.GetMyIP) '' posso assegnare questo indirizzo al dispositivo android ???
            ChiudiConnessione
            client = NewSocket
            astream.Initialize(client.InputStream, client.OutputStream, "astream")
        End If
    Loop
End Sub
il tutto funziona bene (solo perchè ho identificato in partenza l'IP android!!!)
 
Top