14 Punkte von velopert 2021-12-22 | 11 Kommentare | Auf WhatsApp teilen

Ein Bericht über die Erfahrungen, die Ridibooks bei der Umstellung von einer nativen App auf React Native gemacht hat.

  1. Warum React Native gewählt wurde
  • Bisher wurden Inhalte im Web entdeckt und gekauft, während die App als Viewer genutzt wurde. Dann fiel die Entscheidung, auch in der App Funktionen für Entdeckung und Bezahlung einzuführen. Um schnell auf Veränderungen reagieren und die Ziele innerhalb des vorgegebenen Zeitraums erreichen zu können, wurde beschlossen, eine Technologie mit Cross-Platform-Entwicklung einzusetzen.

  • Während Flutter und React Native zur Auswahl standen, fiel die Entscheidung auf React Native, weil die Community etwas stabiler und aktiver war.

  1. Native-basiert vs. React-Native-basiert
  • Es wurde überlegt, ob React Native auf die native App aufgesetzt werden sollte oder umgekehrt native Komponenten auf React Native.

  • Wenn React Native auf die native Basis gesetzt wird, unterscheiden sich die Endpoints je nach Screen, und das Management des App-Lifecycles wird komplexer.

  • Wenn native Komponenten auf React Native aufgesetzt werden, muss der bestehende Native-Code zunächst einmal so angepasst werden, dass er mit React Native kompatibel ist. Künftig muss dann ohnehin vollständig neu in React Native geschrieben werden.

  • Da sowieso geplant war, die meisten Funktionen nach und nach vollständig auf React Native umzustellen, fiel die Entscheidung auf den Weg, native Komponenten auf React Native aufzusetzen.

  1. Wiederverwendung nativer Screens
  • Um innerhalb des vorgegebenen Zeitraums schnell auf Veränderungen reagieren zu können, wurde entschieden, neue Screens in React Native zu entwickeln und bestehende Screens weiterhin nativ zu belassen. Diese nativen Screens sollen schrittweise auf React Native umgestellt werden.
  1. Wiederverwendung von Native-Code
  • Lässt sich die Essenz des nativen Know-hows, das Ridibooks in 13 Jahren Wartung und Weiterentwicklung aufgebaut hat, in React Native übertragen? In der bestehenden nativen App wurden Swift und Kotlin verwendet, daher musste geprüft werden, ob sich diese unverändert in React Native nutzen lassen.

  • Durch den Aufbau einer Bridge konnte die bisherige Arbeitsweise weiterverwendet werden.

  1. Schwierigkeiten im Einführungsprozess
  • Bundle-Größe und Speicherverbrauch nahmen zu.

  • Die Bundle-Größe lag im erwarteten Rahmen, der Speicherverbrauch war jedoch verheerend. Entsprechend musste viel Wert auf Optimierung gelegt werden.

  • Third-Party-Libraries sind schwer zu vertrauen.

  • Weder Native noch Frontend dürfen vernachlässigt werden. Native-Entwickler müssen Frontend-Entwicklung verstehen lernen, Frontend-Entwickler Native-Entwicklung. Der Austausch zwischen beiden Seiten ist der Schlüssel zum Erfolg.

  1. Darum ist React Native gut
  • Hohe Produktivität

  • Eine gute Plattform für Zusammenarbeit

Dank React Native konnte die Produkt-Roadmap innerhalb des vorgegebenen Zeitraums umgesetzt werden, und es entstand eine Umgebung mit hoher Produktivität, die schnelle Reaktionen auf Veränderungen ermöglicht. Künftig soll der native Bereich schrittweise ernsthaft auf React Native umgestellt werden. Der Viewer wird jedoch weiter gepflegt, da dort 13 Jahre angesammeltes Know-how steckt, um weiterhin die bestmögliche User Experience zu bieten.

11 Kommentare

 
ugotme 2021-12-24

Ich weiß nicht, ob Sie schon einmal mit Google Trends nach Keywords gesucht haben, aber das RN-Ökosystem ist praktisch am Absterben. Im Gegensatz dazu wächst Flutter explosionsartig. Zur Einordnung: Ich bin Native-Entwickler.

 
kernel0 2021-12-23

Aus Sicht der Nutzer scheint die Desktop-App eine schlechtere Performance zu haben als die vorige Version. Früher hat man beim Seitenwechsel keine Verzögerung gespürt, aber in letzter Zeit ruckelt sie ständig.

 
lux1024 2021-12-23

Ich wünschte, es gäbe in der Desktop-Version eine Hervorhebungsfunktion ... Hm, vielleicht geht das wegen irgendwelcher Urheberrechtsprobleme nicht.

 
functor 2021-12-23

Ich wünschte, man würde sich bitte nicht nur um Mobile-Apps kümmern, sondern auch um Desktop-Apps … schluchz

 
lifthrasiir 2021-12-23

Aus der Perspektive von jemandem, der die Ridibooks-Desktop-App lange genutzt hat, finde ich diese Entscheidung etwas bedauerlich, weil sie offenbar ausschließlich auf Mobile ausgerichtet ist. Und nicht nur ich sehe das so: Wer eine Desktop-App nutzt, leidet ausnahmslos unter den anhaltenden Bugs ... (noch schlimmer als die alte Qt-basierte App)

 
kernel0 2021-12-23

Ich habe aus meinem Umfeld wirklich sehr viele Klagen über Probleme mit Desktop-Apps gehört..

 
nicewook 2021-12-23

Ich entwickle zwar selbst nicht direkt, aber als ich in den Communities, mit denen ich zu tun habe, all das Lob für Flutter gesehen habe und unseren App-Entwickler im Unternehmen darauf angesprochen habe, meinte er, dass er React mehr schätzt. Er sagte, die Verbreitung und auch der Arbeitsmarkt beim Recruiting seien besser. Mich würde interessieren, was andere darüber denken.

 
deokim 2021-12-23

Da sich Native in enormem Tempo weiterentwickelt, wird es entscheidend sein, ob RN mit diesem Tempo Schritt halten kann.

 
nicewook 2021-12-23

Wie sieht es im Vergleich dazu relativ mit Flutter aus?

 
deokim 2021-12-23

Bei Android dürfte das ebenso in Ordnung sein, aber ich bin mir nicht sicher, ob man mit iOS Schritt halten kann.

Ich finde, man darf die Kosten der durch die Vereinheitlichung entstehenden Entropie nicht unterschätzen.

 
ruinnel 2021-12-22

Mit React Native vor 2–3 Jahren entwickelt und veröffentlicht ...

Persönlich fand ich, dass es mehr Nachteile als Vorteile hat ...

  • Nachdem Airbnb aufgegeben und sich zurückgezogen hatte, las ich diesen Beitrag (und damit fiel sozusagen auch eine tragende Säule der Produktionslinie für 3rd-Party-Bibliotheken weg ...)

https://m.blog.naver.com/PostView.naver/…

Ich hatte das Interesse daran weitgehend verloren ... aber die Popularität ist offenbar nach wie vor ungebrochen.