MVC-patroon op Android

Is het mogelijk om het model-view-controller-patroon in Java voor Android te implementeren?

Of is het al geïmplementeerd via Activiteiten? Of is er een betere manier om het MVC-patroon voor Android te implementeren?


Antwoord 1, autoriteit 100%

In Android heb je geen MVC, maar wel het volgende:

  • U definieert uw gebruikersinterfacein verschillende XML-bestanden op resolutie, hardware, enz.
  • U definieert uw bronnenin verschillende XML-bestanden per landinstelling , enz.
  • Je verlengt klassen zoals ListActivity, TabActivityen maak gebruik van het XML-bestand van inflaters.
  • U kunt zoveel klassen maken als u wilt voor uw bedrijfslogica.
  • Er zijn al veel Hulpprogramma’svoor u geschreven – DatabaseUtils, Html.

Antwoord 2, autoriteit 97%

Er is geen universeel uniek MVC-patroon. MVC is eerder een concept dan een solide programmeerraamwerk. U kunt uw eigen MVC op elk platform implementeren. Zolang je je aan het volgende basisidee houdt, implementeer je MVC:

  • Model:wat te renderen
  • Bekijken:hoe te renderen
  • Controller:gebeurtenissen, gebruikersinvoer

Denk er ook zo over na: wanneer u uw model programmeert, hoeft het model zich geen zorgen te maken over de weergave (of platformspecifieke code). Het model zou tegen de weergave zeggen: het kan me niet schelen of je weergave Android of iOS of Windows Phone is, dit is wat ik je moet laten renderen.
De weergave zou alleen de platformspecifieke weergavecode verwerken.

Dit is met name handig wanneer u Monogebruikt om het model in volgorde te delen om platformonafhankelijke applicaties te ontwikkelen.


Antwoord 3, autoriteit 20%

De acties, weergaven en activiteiten op Android zijn de ingebakken manier van werken met de Android-gebruikersinterface en zijn een implementatie van het model-view-viewmodel (MVVM)-patroon, dat qua structuur vergelijkbaar is (in dezelfde familie als) model-view-controller.

Voor zover ik weet, is er geen manier om uit dit model te ontsnappen. Het kan waarschijnlijk worden gedaan, maar u zou waarschijnlijk alle voordelen van het bestaande model verliezen en uw eigen UI-laag moeten herschrijven om het te laten werken.


Antwoord 4, autoriteit 12%

Na enig zoeken is het meest redelijke antwoord het volgende:

MVC is al geïmplementeerd in Android als:

  1. View = lay-out, bronnen en ingebouwde klassen zoals Buttonafgeleid van android.view.View.
  2. Controller = Activiteit
  3. Model = de klassen die de toepassingslogica implementeren

(Dit houdt trouwens in dat er geen toepassingsdomeinlogica in de activiteit zit.)

Het meest redelijke voor een kleine ontwikkelaar is om dit patroon te volgen en niet te proberen te doen wat Google heeft besloten niet te doen.

PS Houd er rekening mee dat Activiteit soms opnieuw wordt gestart, dus het is geen plaats voor modelgegevens (de gemakkelijkste manier om een ​​herstart te veroorzaken is door android:configChanges="keyboardHidden|orientation"weg te laten uit de XML en uw apparaat).

BEWERKEN

We hebben het misschien over MVC, maar het zal als het ware FMVCzijn, Framework–Model–View–Controller. Het Framework(het Android-besturingssysteem) legt zijn idee van de levenscyclus van componenten en gerelateerde gebeurtenissen op, en in de praktijk de Controller(Activity/Service/BroadcastReceiver) is in de eerste plaats verantwoordelijk voor het omgaan met deze Framework-opgelegde gebeurtenissen (zoals onCreate()). Moet gebruikersinvoer afzonderlijk worden verwerkt? Zelfs als het zou moeten, kun je het niet scheiden, gebruikersinvoergebeurtenissen komen ook van Android.

Hoe dan ook, hoe minder code die niet Android-specifiek is, u in uw Activity/Service/BroadcastReceiverstopt, hoe beter.


Antwoord 5, autoriteit 7%

Er is geen enkel MVC-patroon waaraan u kunt gehoorzamen. MVC stelt alleen min of meer dat je data en view niet door elkaar moet halen, zodat b.v. weergaven zijn verantwoordelijk voor het bewaren van gegevens of klassen die gegevens verwerken die rechtstreeks van invloed zijn op de weergave.

Maar door de manier waarop Android omgaat met klassen en bronnen, ben je soms zelfs gedwongen om het MVC-patroon te volgen. Ingewikkelder naar mijn mening zijn de activiteiten die soms verantwoordelijk zijn voor de weergave, maar tegelijkertijd als verwerkingsverantwoordelijke optreden.

Als je je weergaven en lay-outs definieert in de XML-bestanden, je bronnen laadt vanuit de res-map, en als je vermijdt om deze dingen min of meer in je code te mengen, dan volg je hoe dan ook een MVC-patroon.

p>


Antwoord 6, autoriteit 6%

Je kunt MVC in Android implementeren, maar het wordt niet “natively ondersteund” en kost wat moeite.

Dat gezegd hebbende, neig ik persoonlijk naar MVPals een veel schoner architectonisch patroon voor Android-ontwikkeling. En met MVP bedoel ik dit:

voer hier de afbeeldingsbeschrijving in

Ik heb hierook een gedetailleerder antwoord geplaatst.

Na te hebben gespeeld met de verschillende benaderingen van MVC/MVP-implementatie in Android, kwam ik op een redelijk architectonisch patroon, dat ik in dit bericht beschreef: MVP- en MVC-architectuurpatronen in Android.


Antwoord 7, autoriteit 5%

De beste bron die ik heb gevonden om MVC op Android te implementeren, is dit bericht:

Ik volgde hetzelfde ontwerp voor een van mijn projecten en het werkte prima. Ik ben een beginner op Android, dus ik kan niet zeggen dat dit de beste oplossing is.

Ik heb één wijziging aangebracht: ik heb het model en de controller voor elke activiteit in de toepassingsklasse geïnstantieerd, zodat deze niet opnieuw worden gemaakt wanneer de landschapsportretmodus verandert.


Antwoord 8, autoriteit 5%

Ik ben het eens met JDPeckham en ik geloof dat XML alleen niet voldoende is om het UI-gedeelte van een applicatie te implementeren.

Als u de activiteit echter als onderdeel van de weergave beschouwt, is het implementeren van MVC vrij eenvoudig. U kunt Applicatieoverschrijven (zoals geretourneerd door getApplication() in Activiteit) en hier kunt u maak een controller die overleeft voor de levensduur van uw toepassing.

(U kunt ook het singleton-patroon gebruiken zoals gesuggereerd door de toepassingsdocumentatie)


Antwoord 9, autoriteit 5%

MVC- Architectuur op Android
Het is beter om elke MVP te volgen in plaats van MVC in Android. Maar toch volgens het antwoord op de vraag kan dit een oplossing zijn

Voer hier de afbeeldingsbeschrijving in

Beschrijving en richtlijnen

    Controller -
        Activity can play the role.
        Use an application class to write the
        global methods and define, and avoid
        static variables in the controller label
    Model -
        Entity like - user, Product, and Customer class.
    View -
        XML layout files.
    ViewModel -
        Class with like CartItem and owner
        models with multiple class properties
    Service -
        DataService- All the tables which have logic
        to get the data to bind the models - UserTable,
        CustomerTable
        NetworkService - Service logic binds the
        logic with network call - Login Service
Helpers -
        StringHelper, ValidationHelper static
        methods for helping format and validation code.
SharedView - fragmets or shared views from the code
        can be separated here
AppConstant -
        Use the Values folder XML files
        for constant app level

OPMERKING 1:

Hier is het stukje magie dat je kunt doen. Nadat u het stuk code hebt geclassificeerd, schrijft u een basisinterfaceklasse zoals IEntity en IService. Verklaar gemeenschappelijke methoden. Maak nu de abstracte klasse BaseService en declareer uw eigen set methoden en zorg voor scheiding van code.

OPMERKING 2:Als uw activiteit meerdere modellen presenteert, is het beter om de weergaven in fragmenten te verdelen in plaats van de code/logica in activiteit te schrijven. Dan is het beter. Dus als er in de toekomst nog een model nodig is om in de weergave te verschijnen, voeg dan nog een fragment toe.

OPMERKING 3:Scheiding van code is erg belangrijk. Elke component in de architectuur moet onafhankelijk zijn en geen afhankelijke logica hebben. Als je toevallig iets afhankelijke logica hebt, schrijf dan een toewijzingslogica-klasse ertussen. Dit zal je in de toekomst helpen.


Antwoord 10, autoriteit 5%

Het maken van een Android-gebruikersinterface met behulp van lay-outs, bronnen, activiteiten en intenties is een implementatie van het MVC-patroon. Zie de volgende link voor meer informatie hierover – http: //www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

spiegel voor de pdf


Antwoord 11, autoriteit 4%

Android’s MVC-patroon is (soort van) geïmplementeerd met hun Adapterklassen. Ze vervangen een controller door een ‘adapter’. In de beschrijving van de adapter staat:

Een Adapter-object fungeert als een brug tussen een AdapterView en de
onderliggende gegevens voor die weergave.

Ik ben dit alleen aan het onderzoeken voor een Android-applicatie die leest uit een database, dus ik weet nog niet hoe goed het werkt. Het lijkt echter een beetje op Qt’s Model-View-Delegate-architectuur, waarvan ze beweren dat het een stap verder is dan een traditioneel MVC-patroon. Op de pc werkt het patroon van Qt in ieder geval redelijk goed.


Antwoord 12, autoriteit 4%

Hoewel dit bericht oud lijkt, wil ik de volgende twee toevoegen om te informeren over de recente ontwikkeling op dit gebied voor Android:

android-binding– Biedt een raamwerk dat maakt de binding van Android-weergavewidgets aan het gegevensmodel mogelijk. Het helpt om MVC- of MVVM-patronen in Android-applicaties te implementeren.

roboguice– RoboGuice haalt het giswerk uit de ontwikkeling. Injecteer uw View, Resource, System Service of een ander object en laat RoboGuice voor de details zorgen.


Antwoord 13, autoriteit 4%

Model View Controller (MVC)

voer hier de afbeeldingsbeschrijving in


Beschrijving:

  • Als we grote projecten moeten leiden in de softwareontwikkeling, MVC
    wordt over het algemeen gebruikt omdat het een universele manier is om de
    projecten.
  • Nieuwe ontwikkelaars kunnen zich snel aanpassen aan het project
  • Helpt bij de ontwikkeling van grote projecten en ook cross-platform.

Het MVC-patroon is in wezen dit:

  • Model: wat moet worden weergegeven. Dit kan de gegevensbron zijn (bijv. Server, Raw
    gegevens in de app)
  • Bekijken: hoe het wordt weergegeven. Dit kan de xml zijn. Het werkt dus als een
    presentatiefilter. Een aanzicht is gekoppeld aan het model (of modelonderdeel)
    en krijgt de gegevens die nodig zijn voor de presentatie.
  • Controller: Gebeurtenissen zoals gebruikersinvoer afhandelen. Dit is de activiteit

Belangrijk kenmerk van MVC:We kunnen het model of de weergave of de controller wijzigen, maar hebben nog steeds geen invloed op de andere

  • Stel dat we de kleur in de weergave, de grootte van de weergave of de positie veranderen
    van het uitzicht. Door dit te doen heeft dit geen invloed op het model of de controller
  • Stel dat we het model wijzigen (in plaats van gegevens die van de server zijn opgehaald)
    gegevens ophalen van activa) maar het heeft geen invloed op de weergave en
    controleur
  • Stel dat we de controller wijzigen (logica in de activiteit) heeft dit geen invloed
    het model en het uitzicht

Antwoord 14, autoriteit 3%

Het was verrassend om te zien dat geen van de berichten hier de vraag beantwoordde. Ze zijn ofwel te algemeen, vaag, incorrect of gaan niet in op de implementatie in Android.

In MVC weet de laag Viewalleen hoe de gebruikersinterface (UI) moet worden weergegeven. Als hiervoor gegevens nodig zijn, haalt het deze uit de laag Model. Maar de View vraagt ​​het model NIET rechtstreeks om de gegevens te vinden, het doet dit via de Controller. Dus de Controller belt het Modelom de vereiste gegevens voor de Viewte leveren. Zodra de gegevens gereed zijn, informeert de Controllerde Viewdat de gegevens klaar zijn om te worden verkregen van het Model. Nu kan de Viewde gegevens van het Modelophalen.

Deze stroom kan als volgt worden samengevat:

voer hier de afbeeldingsbeschrijving in

Het is vermeldenswaard dat de Viewop de hoogte kan zijn van de beschikbaarheid van de gegevens in het  Model ofwel via Controller— ook bekend als Passieve MVC— of door de gegevens in het Modelte observeren door er waarneembare waarden voor te registreren, wat Actieve MVCis.

Bij het implementatiegedeelte is een van de eerste dingen die in je opkomt dat welke Android-component moet worden gebruikt voor de View? Activity  of Fragment ?

Het antwoord is dat het niet uitmaakt en beide kunnen worden gebruikt. De Viewmoet in staat zijn om de gebruikersinterface (UI) op het apparaat te presenteren en te reageren op de interactie van de gebruiker met de gebruikersinterface. Beide Activity  en Fragment  geef hiervoor de vereiste methoden.

In de voorbeeldapp die wordt gebruikt in dit artikelheb ik hebben Activity voor de laag Viewgebruikt, maar Fragment  kan ook worden gebruikt.

De volledige voorbeeld-app is te vinden in de ‘mvc’-tak van mijn GitHub-repo hier.

Ik heb ook de voor- en nadelen van MVC-architectuur in Android behandeld door middel van een voorbeeld hier.

Voor de geïnteresseerden: ik ben hierwaarin ik de verschillende architecturen vergelijk, namelijk MVC, MVP, MVVM, voor Android app-ontwikkeling via een volledig werkende app.


Antwoord 15, autoriteit 2%

Ik denk dat de meest bruikbare vereenvoudigde uitleg hier is:
http://www.cs.otago.ac. nz/cosc346/labs/COSC346-lab2.2up.pdf

Van al het andere dat ik hier heb gezien en gelezen, maakt het implementeren van al deze dingen het moeilijker en past het niet goed bij andere delen van Android.

Een activiteit laten implementeren door andere luisteraars is al de standaard Android-manier. De meest onschadelijke manier zou zijn om de Java Observer toe te voegen zoals de dia’s beschrijven en de onClick en andere soorten acties te groeperen in functies die nog steeds in de Activiteit zijn.

De Android-manier is dat de activiteit beide doet. Als je ertegen vecht, wordt het niet echt gemakkelijker om uit te breiden of toekomstige codering uit te voeren.

Ik ga akkoord met het tweede bericht. Het is min of meer al geïmplementeerd, alleen niet zoals mensen gewend zijn. Of het nu wel of niet in hetzelfde bestand zit of niet, er is al een scheiding. Het is niet nodig om extra scheidingen te maken om het passend te maken voor andere talen en besturingssystemen.


Antwoord 16, autoriteit 2%

Omdat ik de MVx-ramp op Android beu was, heb ik onlangs een kleine bibliotheek gemaakt die een unidirectionele gegevensstroom biedt en vergelijkbaar is met het concept van MVC: https://github.com/zserge/anvil

Kortom, je hebt een component (activiteit, fragment en weergavegroep). Binnenin definieert u de structuur en stijl van de weergavelaag. Ook definieert u hoe gegevens aan de views moeten worden gebonden. Ten slotte kunt u luisteraars op dezelfde plaats binden.

Zodra uw gegevens zijn gewijzigd, wordt de algemene “render()”-methode aangeroepen en worden uw weergaven slim bijgewerkt met de meest recente gegevens.

Hier is een voorbeeld van het onderdeel waarin alles zit voor de compactheid van de code (uiteraard kunnen model en controller gemakkelijk worden gescheiden). Hier is “count” een model, de methode view() is een view en “v -> count++” is een controller die luistert naar het klikken op de knop en het model bijwerkt.

public MyView extends RenderableView {
  public MyView(Context c) {
      super(c);
  }
  private int count = 0;
  public void view() {
    frameLayout(() -> {              // Define your view hierarchy
      size(FILL, WRAP);
      button(() -> {
          textColor(Color.RED);      // Define view style
          text("Clicked " + count);  // Bind data
          onClick(v -> count++);     // Bind listeners
      });
    });
  }

Met het gescheiden model en de controller zou het er als volgt uitzien:

button(() -> {
   textColor(Color.RED);
   text("Clicked " + mModel.getClickCount());
   onClick(mController::onButtonClicked);
});

Hier bij elke klik op een knop wordt het nummer verhoogd, vervolgens wordt “render()” aangeroepen en wordt de knoptekst bijgewerkt.

De syntaxis wordt prettiger als je Kotlin gebruikt: http://zserge.com/blog /anvil-kotlin.html. Er is ook een alternatieve syntaxis voor Java zonder lambda’s.

De bibliotheek zelf is erg licht van gewicht, heeft geen afhankelijkheden, gebruikt geen reflectie, enz.

(Disclaimer: ik ben de auteur van deze bibliotheek)


Antwoord 17, autoriteit 2%

Volgens de uitlegdat de Xamarin-team legde uit (op de iOS MVC “Ik weet dat het raar lijkt, maar wacht even”):

  • Het model (gegevens- of applicatielogica),
  • De weergave (gebruikersinterface), en
  • De controller (code erachter).

Ik kan dit zeggen:

Het model op Android is gewoon het deelbare object. De weergave is de XML-lay-out en de controller is de (activiteit + het fragment).

*Dit is slechts mijn mening, niet uit een bron of een boek.


Antwoord 18, autoriteit 2%

Er is geen geïmplementeerde MVC-architectuur, maar er bestaat een reeks bibliotheken/voorbeelden om een ​​MVP-architectuur (model-view-presenter) te implementeren.

Controleer deze links:

Google heeft een voorbeeld toegevoegd van een Android-architectuur MVP:


Antwoord 19, autoriteit 2%

Ik heb gezien dat veel mensen zeggen dat MVC al in Android is geïmplementeerd, maar dat is niet waar. Android volgt standaard geen MVC.

Omdat ik het niet doe, zal Google ooit de beperkingen van een MVC-implementatie zoals de iPhone met geweld opleggen, maar het is aan de ontwikkelaars welk patroon of welke techniek ze in hun project willen. In kleine of eenvoudige applicaties is het gebruik van MVC niet vereist, maar naarmate de applicatie groeit en ingewikkeld wordt en in latere jaren wijzigingen van de code nodig zijn, komt er behoefte aan het MVC-patroon in Android.

Het biedt een gemakkelijke manier om code aan te passen en helpt ook bij het verminderen van problemen.
Als je MVC op Android wilt implementeren, volg dan deze onderstaande link en geniet van de MVC-implementatie in je project.

http://www.therealjoshua.com/ 2011/11/android-architecture-part-1-intro/

Maar tegenwoordig denk ik dat MVP samen met Android Architectural Pattern een van de beste opties is die ontwikkelaars zouden moeten gebruiken voor schone en robuuste Android-applicaties.


Antwoord 20

Wanneer we MVC toepassen, MVVMof Presentatiemodelvoor een Android-app, wat we echt willen is een duidelijk gestructureerd project en, belangrijker nog, eenvoudiger voor unit-tests.

Op dit moment heb je zonder een framework van derden meestal veel code (zoals addXXListener(), findViewById(), etc.), die geen zakelijke waarde toevoegt.

Bovendien moet je eenheidstests voor Android uitvoeren in plaats van normale JUnit-tests, die eeuwen in beslag nemen en eenheidstests enigszins onpraktisch maken. Om deze redenen zijn we enkele jaren geleden begonnen met een open source-project, RoboBinding– Een gegevensbindend presentatiemodelraamwerk voor Android platform.

RoboBinding helpt u bij het schrijven van UI-code die gemakkelijker te lezen, testen en onderhouden is. RoboBinding elimineert de noodzaak van onnodige code zoals addXXListener of zo, en verschuift de UI-logica naar Presentation Model, wat een POJO is en kan worden getest via normale JUnit-tests. RoboBinding zelf wordt geleverd met meer dan 300 JUnit-tests om de kwaliteit ervan te garanderen.


Antwoord 21

Naar mijn idee is de manier waarop Android omgaat met het MVC-patroon als volgt:

Je hebt een activiteit die als controller dient. Je hebt een klasse die verantwoordelijk is voor het ophalen van de gegevens – het model, en dan heb je de klasse View die de weergave is.

Als we het hebben over de weergave, denken de meeste mensen alleen aan het visuele gedeelte dat is gedefinieerd in de xml. Laten we niet vergeten dat de View ook een programmagedeelte heeft met zijn constructors, methoden en dergelijke, gedefinieerd in de java-klasse.

Other episodes