Italian Consigli struttura app

[HuZz]

Ciao a tutti...
Ho un dubbio su come strutturare la mia app e vorrei avere qualche consiglio/suggerimento.
Tempo fa ho creato una webapp (un sito...) dove è necessario registrarsi e pagare un abbonamento annuale per poter usufruire dei servizi del sito...
Diciamo che ho un discreto numero di utenti registrati.
Essendo un sito, ho fatto in modo che sia su Android che su iOs una volta aperto appaia esattamente come una app nativa, ma ora lo step successivo vorrei fosse la creazione della app nativa, sempre tentando di riutilizzare il più possibile quanto già esistente a livello base dati... al tempo usai Access (vabè... lo so...)

Il dubbio ora è:
continuo a mantenere l'architettura corrente, e quindi un utente mi scarica gratuitamente la app, ed è costretto a registrarsi sul mio sito e pagare per attivare l'account, o è meglio che pubblichi direttamente una app a pagamento e consenta poi di usufruire dei servizi immediatamente?
Ora l'abbonamento annuale è di 7€, e se pubblicassi una app a quella cifra, poi non avrei più gli introiti annuali da parte di ogni utente registrato... d'altro canto non penso che qualcuno sarebbe disposto a spendere diciamo 2 o 3 volte quella cifra in un colpo solo per acquistarla...

Ah, dimenticavo... l'intento sarebbe anche quello di slegare parte dei servizi del sito dall'essere online. ovviamente essendo una webapp, chi la usa sul cellulare deve essere costantemente collegato a internet, cosa non sempre possibile. Però vorrei anche mantenere alcune funzionalità "social"....

Secondo voi quale strada è la migliore?

 

[LordZenzo]

alcuni servizi puoi farli payperview paga pochi cent e usa il servizio 1 volta
poi cambia con mysql online, su android sqlite

 

[HuZz]

Grazie per il suggerimento, ma onestamente non saprei come implementarlo... è possibile da codice impostare che al click (ad esempio) su un pulsante, il codice successivo tipo l'apertura di una opzione avvenga solo se l'utente ha acconsentito al pagamento?
Comunque non so se sia questa la migliore soluzione percorribile...
La maggior parte dei contenuti che vorrei fossero pagati dovrebbero essere accessibili poi offline, perchè son quelli che servono di più. Gli altri contenuti dovrebbero essere ad esempio dei documenti condivisibili o altre info che vorrei fossero sincronizzate qualora la connessione internet sia attiva e/o a volontà dell'utente di sincronizzazione.
Per quello non so se conviene obbligare l'utente a registrarsi ancora come fa attualmente... Cioè, se l'utente deve registrarsi o loggarsi per avere accesso ai contenuti offline, ho comunque necessità di connessione internet... a meno che anche qui, dopo che l'utente si è loggato, io salvi su sqlite interno (o su file) le credenziali o qualcos'altro che mi consenta di stabilire se l'utente sia già registrato o meno... e addio sicurezza!

 

[Star-Dust]

Le App su Google Play che vendono servizi digitali (non fisici) devono per contratto farli pagare con Billing In App di Google e non con altri sistemi, quindi meglio se fai pagare un Abbonamento per l'iscrizione attraverso il sistema di Google.

Per Il DataBase lascia Access ma crea dei servizi (ASP/PHP/Pyton o come ti pare) che puoi utilizzare usanto GET e POST dall'App con le librerie OkHttp2 e OkHttUtils2... I dati assorbiti li salvi localmente su SQLite per la consultazione oflline che puoi aggiornare dopo un tot di tempo (o ogni volta che é connesso, anche se penso che oggi per via di WhatsApp siamo conessi 24h)...
... io farei cosi per non cambiare la struttura


Buon lavoro

 

[LordZenzo]

con Billing In App di Google

infatti io quello intendevo, usando firebase, che permette sia servizi a consumo che servizi in abbonamento annuale/mensile o come vuoi tu

 

[HuZz]

Le App su Google Play che vendono servizi digitali (non fisici) devono per contratto farli pagare con Billing In App di Google e non con altri sistemi, quindi meglio se fai pagare un Abbonamento per l'iscrizione attraverso il sistema di Google.

Per Il DataBase lascia Access ma crea dei servizi (ASP/PHP/Pyton o come ti pare) che puoi utilizzare usanto GET e POST dall'App con le librerie OkHttp2 e OkHttUtils2... I dati assorbiti li salvi localmente su SQLite per la consultazione oflline che puoi aggiornare dopo un tot di tempo (o ogni volta che é connesso, anche se penso che oggi per via di WhatsApp siamo conessi 24h)...
... io farei cosi per non cambiare la struttura


Buon lavoro

Si, ho già creato e sto appunto usando servizi ASP che vanno in POST... e l'intento era appunto quello di non riscrivere tutto da capo ma solo integrare i servizi ASP da usare con HttpUtils e comunicare poi con JSON... alcune prove le ho già fatte e fortunatamente ho visto che il lavoro non sembra tanto.
Mi devo un po istruire sul discorso billing in app che non conosco assolutamente... altrimenti opto per la app a pagamento e stop!

grazie a tutti dei consigli... qualunque altra idea o consiglio anche di altro tipo è ben accetta!

 

[Star-Dust]

App In Billing é semplicissimo. Nel pannello di Google crei un nuovo prodotto (come abbinamento , non prodotto a pagamento singolo) gli assegni un codice.
Seleziona la libreria InAppBilling3 e segui questa guida: https://www.b4x.com/android/forum/threads/in-app-billing-v3-library.29998/

Sul forum Cerca tutti i riferimenti InAppBilling3 e trovi tanta roba. L'unico neo è che Google si prende il 30% e vengono detratte già dell'iva (22%) quindi di €7 te ne arrivano circa €.4.

 

[LucaMs]

come strutturare la mia app e vorrei avere qualche consiglio/suggerimento.

Anch'io

Tempo fa ho creato una webapp (un sito...) dove è necessario registrarsi e pagare un abbonamento annuale per poter usufruire dei servizi del sito

Ottima idea/soluzione.

Diciamo che ho un discreto numero di utenti registrati.

Magari se lo fai conoscere anche a noi (tutti gli utenti di b4x, non solo del forum italiano) aumentano pure. Metti un link qui, nella tua signature.

Essendo un sito, ho fatto in modo che sia su Android che su iOs una volta aperto appaia esattamente come una app nativa, ma ora lo step successivo vorrei fosse la creazione della app nativa,

Probabilmente sono troppo ignorante ma che intendi per "app nativa"?

continuo a mantenere l'architettura corrente, e quindi un utente mi scarica gratuitamente la app, ed è costretto a registrarsi sul mio sito e pagare per attivare l'account, o è meglio che pubblichi direttamente una app a pagamento e consenta poi di usufruire dei servizi immediatamente?

SICURAMENTE la prima soluzione, perché se metti delle app a pagamento te le crackano ed i tuoi incassi sfioreranno lo zero assoluto!




Il resto lo leggerò con calma

 

[HuZz]

App In Billing é semplicissimo. Nel pannello di Google crei un nuovo prodotto (come abbinamento , non prodotto a pagamento singolo) gli assegni un codice.
Seleziona la libreria InAppBilling3 e segui questa guida: https://www.b4x.com/android/forum/threads/in-app-billing-v3-library.29998/

Sul forum Cerca tutti i riferimenti InAppBilling3 e trovi tanta roba. L'unico neo è che Google si prende il 30% e vengono detratte già dell'iva (22%) quindi di €7 te ne arrivano circa €.4.

Grazie mille! Per ora ho acquistato solo B4i, per cui son proiettato solo alle app iOS... appena mi impratichisco un po' nell'uso delle librerie e soprattutto appena imparo come si deve a usarlo vedrò di fare il porting su B4A...

Magari se lo fai conoscere anche a noi (tutti gli utenti di b4x, non solo del forum italiano) aumentano pure. Metti un link qui, nella tua signature.

Beh, non penso importi molto alle persone qui del forum di registrarsi, poichè il sito che ho creato è legato al mio hobby del modellismo dinamico... l'indirizzo del sito comunque è http://www.minizracing.net/mypit
In sostanza è una guida/bibbia sull'apprendimento delle tecniche per fare al meglio il setup della propria macchina telecomandata. Oltre alle sezioni esaustive in cui imparare nel dettaglio la scienza e la logica dietro ogni modifica di setup, c'è anche una sezione per l'aiuto rapido dove in pratica tu scegli il problema di setup che hai, e ottieni immediatamente visibilità su quali modifiche effettuare.
Oltre a queste due sezioni puramente tecniche, ci son altre due sezioni in cui calcolare il rapporto finale di trasmissione e per calcolare la durezza degli ammortizzatori.
Ecco, queste elencate sopra son le sezioni che vorrei portare nella app e consentire di accedervi offline

La parte più social è quella relativa alla sezione di condivisione dei propri setup. Ognuno può caricare online un pdf o una foto del proprio setup compilato e decidere se renderla pubblica a tutti, privata o accessibile solo alle altre persone che posseggono lo stesso modello di macchina...

Probabilmente sono troppo ignorante ma che intendi per "app nativa"?

Non sei sicuramente ignorante, magari mi son spiegato male io... Intendevo dire che l'intenzione è quella di sviluppare una app installabile su smartphone. In questo momento tutti gli utenti registrati accedono a un sito web... Potrei anche semplicemente aprire un progetto, metterci una webview e linkare il sito, vero... ma questo non rispetterebbe il mio primo intento, e cioè quello di offrire una app che consenta l'accesso ai contenuti offline da subito!

SICURAMENTE la prima soluzione, perché se metti delle app a pagamento te le crackano ed i tuoi incassi sfioreranno lo zero assoluto!

Grazie mille anche te del consiglio... devo trovare un sistema migliore dell'attuale che uso per far pagare direttamente con paypal chi si registra!

grazie ancora!

 

[udg]

Ciao, se capisco bene hai una larga sezione del sito accessibile a tutti e poi una serie di webapp (mypit, cso..) che fondamentalmente sono quelle che convertiresti in app native e che desideri essere a pagamento.
Personalmente preferisco il modello SaaS (Software as a Service) dove l'app è gratuita ma l'utente paga il servizio finchè lo ritiene; esaurito il credito/l'abbonamento a te non resta che chiudere il rubinetto e terminare di fatto l'utilizzazione del servizio da parte dell'utente.

Può il SaaS convivere con l'idea di rendere disponibili delle funzioni in modalità off-line? Certo. Basta consentire il download del materiale necessario mentre si è online (e quindi anche degli aggiornamenti) e salvarlo localmente in un apposito DB sqlite. Il rischio (così come oggi stesso) è che un utente possa "passare" il contenuto a pagamento ad un altro utente non registrato. Se ne vale la pena si potrebeb crittare il materiale una volta scaricato, ma un pirata saprà come aggirare la cosa in ogni caso.

Se ti è più semplice (nel senso che è già pronto e funzionante) potresti per ora lasciare il meccanismo di acquisto in essere: l'utente va sul sito, si registra e paga.
In cambio riceve una chiave di licenza che deve inserire nell'app mobile affinchè questa possa funzionare.
L'app mobile a comando si collega al server e preleva il contenuto destinato a quell'utente e/o l'avvisa di nuovi aggiornamenti opzionali. Poi l'app mobile torna in modalità offline e permette di utilizzare il materiale prelevato dal server.
Fondamentalmente l'app mobile parte vuota, dopo il primo collegamento preleva ciò che risulti necessario ad un primo utilizzo e poi l'utente sarà libero (nell'ambito di validità del suo abbonamento) di aggiornare i suoi contenuti quando vorrà (ovviamente mentre sarà sotto copertura di rete).

Qualcosa del genere potrebbe andare?

 

[HuZz]

Ciao udg, il dominio che hai visto è in realtà di proprietà del mio sponsor/negoziante, il quale mi ha lasciato usufruire del suo spazio su aruba per i miei "esperimenti"... La webapp CSO era nata come primo "esercizio di stile" per far qualcosa di specifico per un modello di macchinina che il negoziante vendeva... tutto gratuito e in effetti in tutto il mondo son stati parecchi e son tuttora parecchi gli iscritti.
Poi ho voluto approfondire e cercare di migliorare la cosa tentando anche di realizzare qualche spicciolo, e da li è nato MYPIT.

La tua spiegazione del SaaS è chiara, ma non so come potrebbe conciliarsi bene con quello che offre il sito... il target a cui è rivolto son persone dove la maggior parte non vuole/non sa smanettare più di tanto sul cellulare e vuole perderci il meno tempo possibile, ma quando ha bisogno di qualche info o di aiuto per il proprio setup vuole poter consultare rapidamente la guida e ottenere rapidamente soluzioni. Questo il motivo per cui vorrei portare la guida offline.

Per cui, o uno si abbona e può usufruire del sito, o niente... il resto dei servizi di calcolo della durezza degli ammortizzatori, del rapporto finale di trasmissione o della condivisione dei setup online diciamo che son add-on che ho aggiunto poi nel tempo giusto per far evolvere un po' il sito e dare qualche funzionalità in più. Ma il core del sito è senza dubbio la guida... non credo che far pagare un obolo per poter accedere a una sezione del sito quando serve all'utente sia la strada migliore... la vedo macchinosa, ma può essere tranquillamente che sbagli eh!

leggermente OT, ma sempre legato a questo progetto, aggiungo:
Se riuscissi a completare anche l'altra app che ho ancora in cantiere mi piacerebbe aggiungerla al "pacchetto" che offrirebbe iMYPIT allora si che avrebbe un valore anche maggiore il tutto.
Si tratta di un cronometro ad attivazione vocale (utile per tutti i piloti che son sul palco a guidare e non possono di certo premere il pulsante per stoppare il giro...).
Il tutto funziona, l'ho sto testando da tempo, solo che ancora qualche problema e penso di aver capito perchè non esiste nessuna app del genere sull'app store... Avere il riconoscimento vocale perennemente attivo nell'attesa del comando vocale che chiami determinati metodi non sembra essere molto performante, ma non ci son alternative per l'uso che vorrei farne... Prima di pubblicare pure questa app deve essere non dico perfetta, ma funzionare a dovere...

grazie ancora

 

[udg]

il target a cui è rivolto son persone dove la maggior parte non vuole/non sa smanettare più di tanto sul cellulare

Questo farebbe cadere l'ipotesi dell'app mobile..eheh
Avevo immaginato un utilizzo sul campo. A quel punto che sia il cellulare o che sia un portatile deve esserci stata la possibilità di accedere al server e scaricare in locale le informazioni necessarie.
La mia idea era basata sul fatto che, prima di andare sul campo, l'utente potesse scaricare il materiale aggiornato di suo interesse. Sul campo resterebbe sempre offline e potrebbe interagire con le sezioni dell'app che utilizzano i dati già scaricati. Oppure collegarsi "al volo" e prelevare altro materiale/aggiornamenti.
Il discorso del SaaS era solo per indicare una modalità di controllare chi e quando poteva accedere ai dati aggiornati presenti sul server (ed eventualmente di trasmetterne di propri).

Rileggendo il tuo post credo di dover chiarire un punto. Non è che suggerissi di far pagare per ogni accesso ai dati (la guida). Rimarrebbe la possibilità di un abbonamento annuale. La questione è se la guida è ad accesso gratuito sul sito, allora far pagare per consultarla tramite app non sarebbe carino.. vero è che l'app aggiungerebbe il servizio di poter avere in locale quelli stessi dati. Non so, valuta tu.

 

[HuZz]

eheheheheheheh non intendevo quello, altrimenti hai ragione!
Intendevo proprio che sul campo, l'utente ha bisogno ad esempio di capire cosa fare se la macchina gli sottosterza... apre la app, consulta la sezione o l'aiuto rapido sul sottosterzo, e via... fine, si ritorna a lavorare sulla macchina facendo le opportune modifiche... in questo senso l'utente vuole perdere meno tempo possibile.

La guida non viene aggiornata di frequente perchè comunque si basa su concetti di fisica e geometria che valgono sempre... le modifiche riguardano principalmente correzioni di errori o piccole aggiunte per migliorare la comprensione.
Ho creato un utente guest momentaneo... se vuoi/volete farvi un giro per farvi un idea di quello che intendo, accedete con user guest, pass guest...

 

[HuZz]

scusate...
user guest@mypit.com
pass guest

 

[udg]

Letto il tuo post e gironzolato velocemente sul sito.
Sinceramente non vedo problemi ad implementare ciò che ti dicevo. Prendi un tuo server e ricopi le pagine HTML che oggi vengono ospitate sul sito del tuo amico/rivenditore. Puoi decidere se includerle in tabelle MySql oppure lasciarle come file puri e gestirne i riferimenti nel DB.
Se concordate di mantenere sia la versione sul sito che su un'app mobile, dovrai aggiornare due copie della stesso codice HTML, ma come dici non è un caso frequente.

L'utente scarica liberamente l'app mobile che di suo non fa nulla finché l'utente non immette un codice di licenza valido.
L'utente si registra all'utilizzo dell'app mobile e riceve un codice di licenza (puoi codificare la durata, il tipo di moduli attivati, etc)
L'utente registra nell'app mobile il codice licenza e di conseguenza ha accesso al server da cui preleva (parte in automatico e parte a richiesta) le pagine che ora hai nella sezione mypit del sito.
Le pagine vengono memorizazte in locale sul device dell'utente.

Quando l'utente è sul campo, avvia l'app (che lavora in offline) la quale gli mostra le pagine e sezioni che ha scaricato l'ultima volta.

Il controllo sulla licenza puoi farlo anche solo quando l'utente decide di andare on-line e scaricare aggiornamenti, nuovo materiale o inviare sue schede. In pratica l'app potrebbe funzionare all'infinito (con i dati locali) se l'utente non avesse ulteriori necessità di collegarsi al server.

Potresti anche centralizzare l'acquisto del servizio: l'utente si registra sul sito e riceve la licenza dopo aver pagato. Ciò comporta che la generazione della chiave di licenza deve avvenire tramite un modulo sul webserver. Sempre dal sito potrà scaricare l'app mobile e quindi non dovrai neanche pubblicare per forza sullo store di Android/iOS.

 

[HuZz]

Grazie ancora dei consigli e degli spunti di implementazione che mi stai dando...

Potresti anche centralizzare l'acquisto del servizio: l'utente si registra sul sito e riceve la licenza dopo aver pagato. Ciò comporta che la generazione della chiave di licenza deve avvenire tramite un modulo sul webserver. Sempre dal sito potrà scaricare l'app mobile e quindi non dovrai neanche pubblicare per forza sullo store di Android/iOS.

Questa parte mi interessa, perchè un po' sicuramente per mia ignoranza non ho idea di come si possa creare una app iOS in tal senso (per la app Android ho già fatto l'apk scaricabile gratuitamente che altro non è che una webview che apre il sito)...

Adesso a tutti gli utenti iOS che si abbonano non posso fare altro che indicare l'indirizzo da aprire con Safari e poi salvare il link sulla springboard in modo che "sembri" una app quando si vuole utilizzarla...

 

[udg]

Sinceramente non mi sono mai interessato del lato iOS, quindi non saprei darti suggerimenti precisi. Mi aspetto che tutta la "glue-logic" sia trasportabile da B4A a B4i mentre la parte UI va riscritta più o meno interamente. Di recente sono apparse librerie di Erel che dovrebbero aiutare anche sotto questo aspetto.
Diciamo che da un 80% potresti sperare di passare al recupero di un 90% del codice scritto per B4A.

Presumo che il webserver utilizzi PHP come linguaggio di riferimento e quindi per la parte registrazione/licenze/pagamenti dovresti lavorare in quell'ambiente. A meno di non portare tutto sotto B4J (che personalmente adoro).

Leggerò volentieri i tuoi prossimi post mente sarò in viaggio, per ora mi tocca preparare la valigia..eheh

A presto.

 

[HuZz]

Presumo che il webserver utilizzi PHP come linguaggio di riferimento e quindi per la parte registrazione/licenze/pagamenti dovresti lavorare in quell'ambiente. A meno di non portare tutto sotto B4J (che personalmente adoro).

No, come avevo scritto più sopra tutta la parte server è in asp classico... come dicevo è un giocattolino che ho fatto tempo fa nel tempo libero, fa ancora il suo dovere quindi non ho avuto intenzione (ne tempo) di riscrivere il tutto in un linguaggio diverso...

Ok, ti terrò aggiornato!
Visto che (fortunatamente) questo forum italiano sembra essere piuttosto attivo, vi stresserò ancora per consigli e aiuti anche sugli altri progetti che ho in cantiere o anche solo ancora in testa... dopotutto son ancora neofita con B4i e in generale con tutta la suite..

 

[LucaMs]

Mi aspetto che tutta la "glue-logic" sia

Ecco, aspèttati e poi traduci ('ndo l'hai sentita questa? Non è che hai frequentato informatica ad Oxford e non ce l'hai detto? )

 

[udg]

eheh.. mi è sfuggito mentre preparavo la valigia..
E, volendo, non era neanche il termine più appropriato! La GL viene utilizzata in elettronica per indicare circuiti che consentono a chip logici differenti di lavorare insieme, una specie di interfaccia di collegamento.
Per estensione, nel sw potrebbe applicarsi a quella parte del programma che collega e mette insieme una serie di funzioni dedicate a scopi precisi. Una specie di direttore d'orchestra.

Nel caso di cui ai commenti precedenti (visto? ho evitato "post") credo sarebbe stato più appropriato qualcosa tipo "il codice relativo alle funzionalità" oppure "il codice relativo alla logica complessiva del programma".

Ove possibile, a me piace imbastire oggetti che siano in grado di vivere di vita propria e poi limitarmi a scrivere quel poco che serve per richiamarli in modo opportuno o per gestirne gli eventi.