1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Auf Github: Telekom und SAP…

Schön doppelt abrechnen mit 2 Source Code Basen

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: WalterSobchak 31.05.20 - 23:53

    Warum man nicht aus einer Codebasis entwickelt hat?
    Braucht man ja nicht, wenn man eh Teams rumsitzen hat, die schon immer nur für *EINE* Plattform nicht kostensparend entwickelt haben.
    Genau wie man sich das eben bei SAP und Tcom vorstellt.

  2. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: katze_sonne 01.06.20 - 01:18

    Also die meisten User, die ich kenne, bevorzugen native Apps.

    Und mit "eine Plattform" meinst du vermutlich nicht, die Logik in eine gemeinsame C++-Lib zu kapseln, sondern deinem anderen Beitrag nach zu Schlussfolgern, irgendsoeinen JavaScript/HTML-Schmu.

  3. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: divStar 01.06.20 - 01:46

    Die guten nicht-nativen Apps kann man von nativen nicht unterscheiden. Außerdem kann man auch plattformspezifisch Schmu entwickeln.

  4. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: HeroFeat 01.06.20 - 03:22

    Ich bin nicht wirklich in der App Materie drin, aber das wären so meine Gedanken:

    Der Trick bei guten "nicht-nativen Apps" ist es meines Wissens alles was mit der Benutzeroberfläche zu tun hat "nativ" zu schreiben. Also nur die Logik wiederzuverwenden. Aber ob das bei der Corona-Warn-App so gemacht wird oder sinnvoll wäre (einfach weil da nicht mehr viel übrig bleibt), keine Ahnung. Aber wenn man sich mal kurz überlegt, dann gibt es 3 Komponenten die so eine App haben muss:

    - Benutzeroberfläche
    - Logik/Bedienung der Bluetooth API
    - Serverkommunikation

    Die Benutzeroberfläche könnte man wiederverwenden. Will man aber wenn die App sich gut bedienen lassen soll nicht.
    Die Bedienung der Bluetooth API ist sicherlich plattformspezifisch.
    Die Serverkommunikation könnte man vermutlich einheitlich machen. Aber die dafür nötige Abstimmung lohnt sich jetzt auch nicht mehr.

    Und da die App OpenSource sein soll und man sich offen geben möchte ist es unklug auf irgendein App Framework zu setzten welches kostenpflichtige Lizenzen erfordert, ...

  5. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: retrobanger 01.06.20 - 09:48

    Man kann mit React Native etwa eine gemeinsame Code-Basis erhalten, die sich nativ verhält, ja. Dennoch reduziert ein solches Framework eine Anwendung immer auf den kleinsten, gemeinsamen Nenner aller Plattformen. Das mag bei so Billig-Web-Agenturen (daher kenne ich das) oft funktionieren, weil man dort nur ein paar Listen und Detailansichten hat. Bei einem Projekt wie der Corona-Warn-App sollte man sich etwaige fesseln nicht schon von Beginn an anlegen. Der Teil, den man da einsparen kann, ist unerheblich. Dann musst du dir die BT-Schnittstelle als Modul "reinreichen" lassen, d.H. am Ende schreibst du doch wieder nativen Code pro Plattform, aber in einem Projekt. Bei solchen Frameworks profitieren wir als Entwickler nur davon, dass sich jemand anderes die Mühe gemacht hat, die Komponenten Adapter-mäßig für jede Plattform zu schreiben.

    Am Ende schreibst du dir eigene Controls oder Klassen dann doch wieder Plattformspezifisch, nur um sie in deinem Plattformunabhängigen-Projekt zu verwenden. Das kann sogar Sinn machen, aber nicht bei einem Projekt wie diesem. Ich bin mit sicher, dass der Weg, zwei native Apps zu programmieren, deutlich Aufwand spart.

  6. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Blindie 01.06.20 - 09:51

    Die Frage ist auch, kann man mit nicht nativen Apps überhaupt auf die Schnittstellen zugreifen?

  7. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: retrobanger 01.06.20 - 10:01

    Du kannst dir im Zweifel immer ein Modul / ein Plugin (wie auch immer man es auf er jeweiligen Plattform nennt) entwickeln, aber plattformunabhängig ist es dann nicht mehr - man muss dies dann für jede Plattform tun. Man pflegt dann trotzdem zwei Baustellen.

  8. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Slartie 01.06.20 - 10:17

    Die Menge an Business-Logik, die bei dieser App anfällt, ist lächerlich gering. Diese Apps sind in erster Linie UI-Frontends für die beiden APIs des Corona-Warn-Servers und der Exposure-Tracking-Systeme von Google und Apple. Letztere sind nativ und es ist unausweichlich, dass man plattformspezifischen Code schreibt, um sie anzusprechen. Ein ansprechendes UI ist ebenfalls immer noch am besten durch Nutzung der nativen UI-Frameworks der Plattformen zu realisieren - ja, ich kenne Flutter und Co., ja, man kann damit okay-ishe UIs bauen, aber: nein, die Ergebnisse damit sind äußerst selten wirklich qualitativ mit einer von fähiger Hand gebauten nativen App vergleichbar. Dazu kommt: ein Großteil der Business-Logik dieser Apps ist der Part, der im Hintergrund Listen von Keys runterlädt und mit lokal gespeicherten vergleicht. Da die APIs für Hintergrundtasks zwischen Apple und Google sich unterscheiden und es hier auf möglichst gute Integration ankommt, um maximale Effizienz und minimalem Energieverbrauch zu erreichen, kann man auch hier vermutlich wenig Code wirklich zwischen den Plattformen teilen.

    Einzig die CWA-Server-API könnte man potenziell ganz gut über eine gemeinsame codebase anbinden. Aber die ist nun auch nicht so aufwendig anzubinden, dass sich das wirklich lohnte, und da man bedingt durch die Exposure-Tracking-APIs ohnehin zwingend plattformspezifische Teile hat, würde ich als Verantwortlicher auch ganz klar die Entscheidung treffen, hier mit vollkommen getrennten Codebases zu arbeiten.

    Das ist auch rein organisatorisch einfacher, da ich dann zwei unabhängige Teams auf die Aufgabe ansetzen kann, die null Reibungsverluste haben. Geschwindigkeit und Agilität bei der initialen Fertigstellung und späteren Weiterentwicklung ist in diesem Fall eh wichtiger als alles andere, auch wichtiger als die Kosten, und unter den Umständen ist minimale Kopplung einfach durch nichts zu ersetzen (vgl. auch den Microservice-Ansatz, der den exakt gleichen Gedanken verfolgt).



    1 mal bearbeitet, zuletzt am 01.06.20 10:21 durch Slartie.

  9. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Peter V. 01.06.20 - 12:59

    WalterSobchak schrieb:
    --------------------------------------------------------------------------------
    > Warum man nicht aus einer Codebasis entwickelt hat?
    > Braucht man ja nicht, wenn man eh Teams rumsitzen hat, die schon immer nur
    > für *EINE* Plattform nicht kostensparend entwickelt haben.
    > Genau wie man sich das eben bei SAP und Tcom vorstellt.
    Stimmt irgendwelche Frameworks und 100 Pakete pflegen, statt eine vernünftige native Umsetzung.

  10. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Trockenobst 02.06.20 - 02:13

    WalterSobchak schrieb:
    --------------------------------------------------------------------------------
    > Warum man nicht aus einer Codebasis entwickelt hat?

    Ich bastle schon länger mit Kotlin/Native an dieser Mentalität, backend sauber, Frontend ist dann Kotlin/Android und SwiftUI wahrscheinlich IOS.

    Das Problem hier ist, dass das Backend superclean sein muss und du absolute Profis auf beiden Seiten brauchst damit der gemeinsame Code auch nutzbar ist. Nicht jeder arbeitet bei Visa und hat 100.000¤ Jahresgehalt Seniors im 20er Pack rumsitzen.

    Kotlin ist in dem Fall auch eine Spezialthematik, übergreifende Frameworks und Tools haben alle ihre tiefen Probleme, entweder ist es Performance oder die notwendige tiefe Beschäftigung damit damit man es wirklich verwenden kann.

    Facebook kann sich bei Milliarden im Monat leisten, alle Leute React Native machen zu lassen bis es jeder verstanden hat. Bei Flutter/Google ist es das selbe. Außerhalb der Gelddruckmaschinen ist es viel schwieriger in solche Systeme einzusteigen und effektiv zu sein.

    Da ist es manchmal besser ein sauberes Backend zu haben und zwei Teams zu fahren, oder wie bei der letzten Firma, die hatten dreieinhalb Teams: Android, Windows, Mac/IOS, Linux. Die nutzen extremes Codegenerieren und können so das Modell hinter den Anwendungen bei fast 100% gleich lassen, aber es bleiben dann doch noch über 50% Code für jede Plattform übrig.

  11. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Trollversteher 02.06.20 - 15:10

    >Die guten nicht-nativen Apps kann man von nativen nicht unterscheiden.

    Kann man sehr wohl in hjeder Hinsicht. Zumal afaik, aus Sicherheitsgruenden nicht alle Smartphone APIs auch in der Browser API zur Verfuegung.

    >Außerdem kann man auch plattformspezifisch Schmu entwickeln.

    Das Risiko ist imho bei Javascript gefriggel deutlich hoeher ;-)

  12. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: WalterSobchak 02.06.20 - 15:44

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Die guten nicht-nativen Apps kann man von nativen nicht unterscheiden.
    >
    > Kann man sehr wohl in hjeder Hinsicht. Zumal afaik, aus Sicherheitsgruenden
    > nicht alle Smartphone APIs auch in der Browser API zur Verfuegung.

    Jemand hat React Native nicht verstanden.


    > >Außerdem kann man auch plattformspezifisch Schmu entwickeln.
    >
    > Das Risiko ist imho bei Javascript gefriggel deutlich hoeher ;-)

    Ja, sag das mal Apple deren AppStore app son Java HTML Geraffel ist.

  13. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: budweiser 02.06.20 - 16:25

    Ja, das sagen alle die mit sowas hantieren. Eine wirklich perfekte aber dennoch plattformunabhängige App habe ich noch nie gesehen. Nenn doch mal eine bekannte.

    Ansonsten fällt es i.d.R. schon nach kurzer Zeit auf dass man es hier mit einem Web-Schrott zu tun hat.

  14. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Deff-Zero 03.06.20 - 00:16

    WalterSobchak schrieb:
    --------------------------------------------------------------------------------
    > Warum man nicht aus einer Codebasis entwickelt hat?

    Also, da die App auch mit meinen Steuern bezahlt wurde: mir kommt es da auf 2 Mark-Fünfzig nicht an. Dafür will ich aber echte native Apps und nicht so einen React oder anderen Javascript-Schund.

  15. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Trollversteher 03.06.20 - 07:50

    >Jemand hat React Native nicht verstanden.

    Doch, hab ich. Aber afaik ist man auch bei react native beim Zugriff auf die Hardware des Geraetes meistens auf externe Bibliotheken angewiesen, die wiederum nativen, geraetespezifischen Code enthalten. Gibt es denn schon eine solche Library fuer die neue Tracing-API?

  16. Re: Schön doppelt abrechnen mit 2 Source Code Basen

    Autor: Hantilles 03.06.20 - 12:13

    Die App scheint bisher noch gar nicht bezahlt, bzw. überhaupt beauftragt worden zu sein. Momentan gehen diese Unternehmen wohl noch ziemlich mit eigener Vorleistung ins Risiko.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. slashwhy GmbH & Co. KG, Osnabrück
  2. Continental AG, Hannover
  3. Bundesinstitut für Risikobewertung, Berlin
  4. Westernacher Solutions GmbH, Berlin, Heidelberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-44%) 27,99€
  2. 46,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de