Android または iOS アプリケーションは以前にドメイン名 A にリクエストを送信しましたが、現在はドメイン名 B を変更する必要があります。Android を再パッケージするより良い解決策はありますか?

再パッケージ化した場合、ユーザーは必ずしもアプリを更新するとは限らないため、この解決策はあまり良いとは言えません

もちろん、Android アプリケーションが要求するドメイン名は設計の最初から可変にするのが最善ですが、この問題をどう解決するか?つまり、コードをダウンロードしてローカル コードを上書きできますか? これはセキュリティ上の問題ですか?

返信内容:

再パッケージ化した場合、ユーザーは必ずしもアプリを更新するとは限らないため、この解決策はあまり良いとは言えません

もちろん、Android アプリケーションが要求するドメイン名は設計の最初から可変にするのが最善ですが、この問題をどう解決するか?つまり、コードをダウンロードしてローカル コードを上書きできますか? これはセキュリティ上の問題ですか?

インターフェースを書いた人に、ドメイン名 A からドメイン名 B にリクエストを送信して、データを返してもらうことができます。はは、聞きたいのですが、再パッケージするのは面倒ですか?モバイル開発を理解していない

アプリ起動時に1回だけバックグラウンドデータをリクエストできます。ラベルを設定します。1 の場合は A アドレスをロードし、0 の場合は B アドレスをロードします。

これは、すでにオンライン申請を行っている場合に発生します。したがって、基本的に解決策は 1 つだけです。バックエンド開発者に懸命に作業してもらい、ポイント A に送信されたすべてのリクエストをポイント B にリダイレクトし、応答データを返すことです。 注: これらのデータの形式に不必要な変更を加えないことが最善です。そうしないと、フォールト トレランスが十分でない場合、クラッシュが発生します。

もちろん、アプリケーション自体にもこの問題を解決する方法がありますが、事前にアーキテクチャを設計する必要があります。たとえば、iOS と Android の両方に、ホット リペアのための実装テクノロジがいくつかあります。あなたのAPPがすでにそのような構造を持っている場合、開発したパッチをサーバー側に配置し、APPにポイントBデータをリクエストさせると、APPはこれらのパッチを自動的にダウンロードしてAPP自体に適用します。その後、APP は自動的にポイント B データを要求できます。

2 つの状況を比較検討すると、ポイント B が開発されていることがわかります。したがって、最初のオプションが最も簡単で速いです。

1. サーバーの観点から: サーバー上の学生に nginx を設定してもらいます。
2. アプリの観点から: 個人的には、ドメイン名の変更は頻繁に行うべきではないと思います。そしてアプリ側で保存するか、ドメイン名を取得するための口実を用意します

サーバー側で解決した方が省力化できそうです

再パッケージ化とパッケージ化は数分で完了します。必要なのはユーザーによる更新だけです