Qual è il ruolo che un servizio Android dovrebbe svolgere nel model MVP?

Sto sviluppando un'applicazione Android che fa il riconoscimento delle attività umane.

Funziona fondamentalmente in questo modo – il servizio legge costantemente i dati dell'acceleratore e memorizza l'attività riconosciuta (ad esempio, Walking, in esecuzione) in un database. L'utente può visualizzare tutte le attività riconosciute in un'attività di ListView (accede al database). Ogni tabella utente del database contiene un field pa_goal (attività fisica) che il servizio legge dal database e fa alcuni controlli.

  • Montare il sistema R / W in applicazione android per modificare i file di sola lettura
  • Cattura immagini con la camera in android e salva con un nome personalizzato
  • Come sapere il momento in cui la persona chiamata prende il suo telefono
  • Classe per android reusable layout
  • come creare una vista di elenco multipla in android
  • È un servizio android garantito per call onDestroy ()?
  • L'utente, ovviamente, può cambiare questo objective da un'attività. Dal momento che implementerò il model architettonico MVP.

    Non sono sicuro where mettere il servizio? Sicuramente non è View. Qualche consiglio?

  • posso utilizzare la shell adb per submit comandi alla mia applicazione
  • Il metodo FloatMath.sqrt () non è stato trovato
  • android.app.Application non può essere istanziato a causa di NullPointerException
  • NestedScrollView scorre in cima alla modifica di Recyclerview
  • Pulsante ionico android non funzionante
  • Denial di authorization di Android 6.0: richiede l'authorization android.permission.WRITE_SETTINGS
  • 3 Solutions collect form web for “Qual è il ruolo che un servizio Android dovrebbe svolgere nel model MVP?”

    In un'architettura pulita, che è quello che suppongo di utilizzare MVP, c'è l'idea di separare il framework dalla logica aziendale. Questo è essenzialmente quello che un normale presentatore ti permette di fare.

    In questo caso la sua non è una vista con cui hai a che fare ma il principio è simile. Non si desidera che tutte le logiche aziendali o applicative si mescolino nel codice Android quando è ansible separarle per una più bella e più classi di responsabilità. Quindi direi che mentre non è una vista si dovrebbe ancora avere una class di tipo presentatore (probabilmente meglio essere chiamato controller o manager forse).

    Questa class sarebbe un POJO che controlla il modo in cui il tuo servizio si comport, che è facilmente testabile con i test standard di junit e le prove di servizio. Questa class e il servizio potrebbero quindi essere messi in un proprio pacchetto di funzioni e interagire con i templates di back end allo stesso modo dei tuoi presentatori.

    Quindi, in sintesi, il ruolo è di un'altra caratteristica dell'applicazione che siti accanto alle altre funzionalità (che di solito sono solo viste nella mia esperienza).

    Spero possa aiutare

    Questo articolo mi ha aiutato in una situazione simile, sebbene non sia esattamente la tua, l'idea è la stessa:

    https://android.jlelse.eu/android-bound-services-and-mvp-12ca9f70c7c7

    Fondamentalmente, l'autore lavora intorno al fatto che un servizio legato è strettamente accoppiato ad un'attività, e aggiunge ulteriori chiamate al ciclo di vita ad esso.

    Sono nella stessa situazione. Infine ho deciso di fare qualcosa di simile:

    Le attività oi frammenti sono fuori field, non sanno niente di MVP MA voglio usare un bus di events come Otto per submit segnali / events, Così:

    Le mie classi che estendono un tipo di presentatore non conoscono niente di Android Context, ma avranno un'interface MvpView, con solo onAttachPresenter e onDetachPresenter.

    La class che estende il servizio avrà un attributo Presenter e implementa un'interface MvpView su onSucess, OnError, OnStart, OnComplete o qualcosa del genere e degli stessi events per Otto (onSucessEvent, OnErrorEvent, OnStartEvent, onCompleteEvent).

    Quindi, quando devo fare qualcosa, l'attività o il frammento inizieranno il servizio, il servizio "inizia" o parla con il presentatore e quando il presentatore finirà con successo, chiamerà mvpView.onSuccess () e memorizza le informazioni all'interno di un DB locale con SQLite (forse il negozio) e infine il servizio invoca Otto e passa il segnale (senza alcun dato su di esso), probabilmente completato. Infine il segnale sarà richiuso dal mio UI (forse frammento) e recuperare tutte le informazioni all'interno di un DB in SQLite.

    Quindi, quando l'onSucess accade l'UI mostrerà i dati più recenti e migliori, ma quando l'evento suError accada (alless) mostrerà alcune informazioni (o non se lo si desidera) dicendo all'utente "c'era un problema ma alless puoi vedere qualcosa" , bot onSuccess e OnError chiameranno onComplete dopo tutto.

    Non so se questa è la soluzione migliore ma in questo caso penso che non tratterò di attività o loops di vita dei frammenti e non ti preoccuperei di onSaveInstance e di ripristinare i dati quando l'utente ruota il dispositivo. Riceverà sempre i dati più recenti all'interno di DB e se qualcosa accade (senza connessione a Internet) puoi mostrare alless qualcosa quando ricevi il segnale onComplete.

    Alcuni fatti che sto ancora pensando:

    • Il Presenter non sarà una class singola
    • Il Presenter non sa nulla di Context ma sì con la class MyApplication
    • Cosa succede se per uno schermo (frammento) hai diversi servizi con differenti onSuccessEvents? Utilizza semplicemente un tipo di azione come ID, per identificarli.
    • Non fare mai il Fragment di Attività implementare il MvpView, dovrai trattare il ciclo di vita.
    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.