Newsgroup: it.comp.hardware.palmari
Titolo: Per un ristorante e per gestire il magazzino in remoto , PocketPC vs PALM ?

Devo gestire gli ordini del mio ristorante ed anche muovermi nel mio
magazzino
per verificare le giacenze in remoto ( in collegamento con un PC con Win
XP )
La mia softwarehouse mi fornisce allo stesso prezzo
i programmi per POCKETPC  sia per PALM OS.
Quale mi consigliate ?

Il trasferimento dei dati viene fatto solo ,
su richesta. NON in tempo reale.
Premessa : Mi serve solo per lavoro.
TNX.

 ha scritto nel messaggio
news:rtyb9.28942$ub2.4...@news1.tin.it...


 ha scritto nel messaggio ...


> Con il ppc questa teoria non si applica...
Mi spieghi da dove vieni?
Qui stiamo veramente tirando bufale tanto per tirarle...
--
"You are not your job, the car you drive, how much you have in your bank.
You are not the clothes you wear, the content of your wallet.
You are not your fuc*ed Pocket PC."

 ha scritto nel messaggio
news:3D6FB38A...@supereva.it...


 
ho appena finito di sviluppare un'applicazione per la gestione delle 
comande in ristoranti e pub su PalmOS, l'applicazione è a detta del 
cliente venuta molto bene, i problemi che ho dovuto affrontare strada 
facendo sono:
- trasmissione della comanda in tempo reale alla cucina: bluetooth non 
va bene (10m di raggio di azione)... soluzione WI-FI con scheda XIRCOM
- per i ristoranti con distesa all'aperto o ambiente intimo è da tenere 
presente il fattore "illuminazione", i palm monocromatici NON vanno bene 
e dispositivi a colori per cui esista la scheda della xircom non sono 
molti (m505/515 o m130), visto che quegli str...i della handspring hanno 
deciso di abbandonare completamente i dispositivi con slot di 
espansione.
- sono convinto che per un uso verticale o orizzontale, ma senza 
velleità multimediali la piattaforma Palm sia migliore di quella PPC: 
durata ed affidabilità.
- i dispositivi palm sono più compatti: anche con l'accrocchio della 
xircom un palm è più piccolo e leggero di un ppc con scheda wi-fi... a 
meno di non andare su modelli con apparato wi-fi integrato... ma con 
costi di acquisto inaccettabili per uno strumento che prima o poi o 
davanti ad un tavolo o in cantina sarà destinato a cadere e a 
rompersi... meglio allora le macchine costosissime della symbol....
...per questi ultimi terminali entro pochi giorni avrò qualche 
quotazione (spero decente) e, soprattutto, potrò giocare un po' con i 
dispositivi tenendoli in mano e vi saprò dire.
Se sono andato completamente fuori strada e la necessità è quella di 
gestire solo il magazzino e gli ordini (nel senso di fornitori e non di 
clienti) allora un Palm con ThinkDB o HandDB con applicativo lato PC e 
driver ODBC configurato bastano e avanzano!
d.

 facendo sono:
Hai utilizzato POCKETSTUDIO
http://www.pocket-technologies.com
 ?
Come ti sei trovato ?
( io conosco molto bene delphi )
Hai avuto Problemi con PS ?
Hai utilizzato la nuova libreria PSLIBRARY ?

Ho qualche dubbio sul futuro di PALM.
.NET e' arrivato , e tra breve si potra'
creare applicazioni per POCKET PC con facilita'.

 creare applicazioni per POCKET PC con facilita'.
.NET non c'entra nulla con PPC2002, è un OS totalmente differente,
per utenze differenti... Che poi si riuscirà mai a creare applicazioni
con
facilità, o ti butti sul Flash (ed esiste già), o ti affidi agli sdk
della MS
(e dio ce ne scampi e liberi...)


 
dopo applicazioni verticali sviluppate in codewarrior questa è la prima 
sviluppata interamente in AppForge.
Mi sono trovato veramente bene! Soprattutto durante lo sviluppo 
dell'interfaccia wireless: mi sono fatto un protocollino di 
sincronizzazione (che non scomoda hotsync il quale è lentissimo!) e 
nemmeno interfacce meno idonee al mondo palmare (soap e .net)... 
Il mio cliente ha un buon applicativo per la gestione dei ristoranti 
(casse, magazzino, ecc.) scritto in delphi.
Il mio applicativo consta di tre parti:
- applicativo Palm;
- interfaccia (oggetto com, una dll) per la comunicazione su tcp/ip (in 
questo caso wireless) che è stata integrata nel suddetto programma in 
delphi;
- conduit per la sincronizzazione grossa di tutti gli archivi, il 
magazzino ecc. una volta ogni tanto.
Riconosco la lentezza dell'ambiente di sviluppo utilizzato, ma a parità 
di ore/uomo per l'implementazione non ci sono ambienti comparabili.
Per quanto riguarda l'affermazione sui protocolli idonei o meno ecco una 
spiagazione: un Palm è un oggetto intrinsecamente molto meno performante 
di tutte le altre piattaforme che i programmatori sono abituati ad 
utilizzare (PC Win, PC Linux, MacX, PPC) ed i protocolli di quel tipo 
inviluppano tutte le informazioni in strutture abbastanza complesse che 
ne garantiscono la portabilità e la flessibilità. 
Ritengo che ad oggi sia meglio fare un minimo sforzo (c'ho messo 2 
giorni tra l'applicazione client e server per la comunicazione 
bidirezionale) per lo studio e l'implementazione di un oggetto 
proprietario (magari basato su uno schema XML con DTD "cablato" 
nell'applicazione) piuttosto che l'utilizzo di oggetti onerosi da un 
punto di vista computazionale e di banda impegnata.
Nella mia applicazione questo tipo di approccio limita la comunicazione 
praticamente alla sola autenticazione di rete (sono necessari dai 2 ai 4 
secondi per inviare una comanda completa di autenticazione).
Per quanto riguarda il futuro di AppForge sembra che l'ambiente verrà 
aggiornato per sfruttare nativamente l'OS5 e l'ARM dei nuovi Palm. E' 
allo studio, sembra, anche una versione basata su .NET...
d.

 
come si evince dal mio post precedente... il probelma della facilità di 
sviluppo è una ridotta analisi del problema da risolvere, con 
conseguente non efficente implementazione degli oggetti software.
d.