React-Native 開発における落とし穴の記録

モバイル開発の観点から見ると、iOS と Android の両方に独自の UI 機能があるため、react-nativeの一連のコードを書くことは普遍的に使用できるという主張は嘘です. 実際の開発では、多くのコントロールが含まれていることがわかります. iOS と Android. Android で表示される効果が異なるか、一部の属性が iOS をサポートしていても Android をサポートしていません。react-native は、初期の頃は iOS のみをサポートし、その後 Android をサポートしたため、これまでは、react-native は Android プラットフォームよりも使いやすい iOS プラットフォームをサポートしていました。

UI方面

1. textinputunderlineColorAndroid='transparent'コンポーネントは、デフォルトで入力ボックスに行を追加します.これは醜いです.実際の開発では、プロパティを設定し、Android システムの下でデフォルトの行を削除する必要があります.
2. iOS と Android プラットフォームの特性により、iOS では同じコンポーネントで設計された UI 効果を実現できますが、Android では効果が得られない場合があります. この場合、 import {コンポーネントの元の名前をエイリアスとして使用する必要があります. } 'Component source'から、同じ名前のサードパーティコンポーネントを導入し、さまざまなプラットフォームの UI 効果を表示します。
3. react-native は iOS の影効果をサポートしていますが、Android はサポートしていません. この場合、それをサポートするサードパーティのコンポーネントを見つけるか、写真を切り取る方法を使用してサポートすることしかできません.
4.すりガラス効果を実現するために、インターネットで多くの情報を検索しましたが、すべてがreact-native-blurライブラリを推奨していますが、このライブラリは iOS にも非常によく対応していますが、Android にはあまり適していません。iOS 側はコンポーネントのネストをサポートしており、画像の参照を設定せずにすりガラス効果を実現でき、すりガラスの下のビューを動的に表示できます (カルーセル画像など); Android はサポートしていません。メソッドは使用できず、画像の参照を設定する必要があります。つまり、静的画像でのすりガラス効果のみをサポートします。
5. キーボードオクルージョンの処理は、iOS と Android でトリガーされるイベントが異なるため、プラットフォームごとに個別の処理が必要です。
6. 現在のコンポーネントの状態を更新する際に、setstate()を使用して更新すると、本来表示されるはずのToastプロンプトが表示されないため、Toast 表示メソッドのコールバックで状態を更新する必要があります。

メソッドサポートの違い

実際の開発過程では、iOS で有効な方法もあるが、Android プラットフォームでは実行結果が異なる場合があります.この場合は、両端をサポートする別の方法を見つけるか、別の方法を別の方法で使用してください。プラットフォーム、方法。

1.startWith()文字列のプレフィックスを判断すると、実際の開発では、iOS プラットフォームでの実行結果は正しいが、Android の動作結果は正しくないことがわかり、データを印刷して、データが正しいことがわかります。startWith()ということで、androidのhttpリンク判定がうまくいかないことがわかりました.indexOf()文字列を含むこのメソッドを使ってみると、両端での実行結果が正しいです。
2. スペースの削除については、実際の開発では、ユーザーが口座番号とパスワードを入力する際に入力されたスペースを削除する必要があります。実際の操作中に、Android プラットフォームでは、ユーザーが入力を停止している限り、連続してスペースをいくつ入力しても、正規表現を使用して文字列内のスペースをフィルター処理することが有効になり、スペースを削除する効果; iOS プラットフォームは A スペースのみを削除できます。複数のスペースを続けて入力すると、中間にドットが表示され、正規表現は余分なスペースに対して機能しません。これは iOS を直撃しました。

redux フレームワークの落とし穴

redux フレームワークは、状態判断の形式を使用してビジネスロジックを処理します。実際の開発プロジェクトでは、ビジネスロジックの判断の状態が同じ状況にならないようにする必要があります。そうしないと、超自然的なバグが発生します。ログイン＆登録のプロセスを開発していた時は、別のページだったので状態の判定は同じでした（登録時の入力認証コードとパスワード忘れ時の入力認証コードは同じジャンプロジックです）。redux のAppStateステートはグローバルで、この行を忘れるように登録されているため、プッシュページを使用します。パスワードを忘れたとき、パスワードボックスのページに入るために2回押しました. 長い間検索した後、印刷されたページにジャンプしてこの穴から登りました.

このバグの原因は、redux のグローバルな状態メカニズムを理解していないことと、スタックにプッシュされたページの状態判定方法をシールドしていなかったことです。、登録ページのジャンプパスワードボックスの状態が満たされている、またジャンプします。

要約する

開発に反応ネイティブを使用する場合、いつでもピットに遭遇する準備ができている必要があり、常にピットを埋める準備ができている必要があります。反応ネイティブ開発への道のりは非常に長く、この山の後にはまだ山があります。