NagramXFの構造とTelegramフォークが生き続ける理由

Android用公式Telegramクライアントのソースコードを見たことがある人なら、きっと少し困惑した記憶があるはずだ。巨大なコードベース TMessagesProj、JavaとC++の混在、カスタムViewsとホームグロウンなインターフェース描画の山。 architectural complexityにもかかわらず、Telegramクライアントを中心にフォークのエコシステムが成長し続けている。開発者たちは常にアプリを自分のニーズに合わせて改変しようとしている：隠れた既読レシートを追加する人もいれば、广告を削除したり新しいテーマを追加したりする人もいれば、NDKを使用したり、通知をカスタマイズしたりする人もいれば、完全に異なるクライアントに生まれ変わらせる人もいている。

最近、GitHubでNagramXFリポジトリを見つけた。人気のNagram Xクライアントのフォークで、作者は単一ブランチに限定せず、複数の有名プロジェクトの機能を内部にバンドルすることを決めた：AyuGram、exteraGram、Cherrygram、OctoGram。

このプロジェクトが何なのか、内部構造はどうなっているのか、ソースコードから独自のAPKをビルドする方法を見ていこう。

最佳サードパーティクライアント機能のフランクenstein

Android用代替Telegramクライアントの歴史は、ビルディングキットのようなものだ。まずNekogramのフォークが登場し、次にNagram、そしてNagram Xとなり、今はNagramXFに辿り着いた。プロジェクト作者のKeeperorownerの目標はシンプルだった：Nagram Xの基本的な安定性を保ちながら、他のクローズドおよびオープンなフォークから便利な改善を移植すること。

ビルドに含まれたのは以下のものだ：

• AyuGramからの機能：編集および削除されたメッセージの履歴をデバイスに直接保存、「入力中」ステータスの柔軟な設定、会話の隠れた既読レシート。
• exteraGramとCherrygramからのカスタマイズ機能：微調整されたフォント、アイコンスタイル、カスタムチャットディバイダー、作者なしの拡張メッセージ転送メニュー。
• OctoGramからのマイナーUI調整：クイックリンクコピー、簡略化されたプロフィール表示、リスト内のアニメーション最適化。

興味深い詳細として：リポジトリの説明で、作者は正直に、一部の機能はクローズドビルドのリバースエンジニアリングによって取得されたことを警告している。コードには様々なパッチの元の作者への参照が残されており、この種のオープンソースフォークにとってはむしろ珍しいことだ。

hoodと構造の詳細

リポジトリは結構大きく、サブモジュールなしで約800メガバイトだ。内部にはクラシックなプロジェクト TMessagesProj があるが、 modulesとヘルパーに注目すべき変更がある。

パッケージ tw.nekomimi.nekogram.helpers の中を覗くと、Nekogramからの血統がすぐに分かる。例えば、リモートのメタデータとクライアント設定の管理は、クラス BaseRemoteHelper に結びついており、特殊なのサービスチャンネルからパラメータを読み取る。

フォークのアーキテクチャは3つの柱に基づいている：

1. 定期的に公式リポジトリの上流からプルされる基本Telegram Androidコード DrKLO/Telegram。
2. イベント傍受レイヤー：サーバーが削除または編集のコマンドを送信する前に、受信メッセージをローカルのSQLiteデータベースにキャッシュ（AyuGramの機能がどのように動作するか）。
3. UIパッチ：標準Telegram Activitiesとコントローラの上にオーバーレイし、設定メニューにトグルを追加。

プロジェクトをローカルでビルドする方法

Telegramフォークのビルドは常に別のクエストだったが、NagramXFにはかなり straightforwardなガイドがある。コードを読み込みたい場合や、独自のキーでクリーンなビルドを作成したい場合は、Android Studio、Telegram開発者コンソールからの数個のキー、そして約15分の空き時間が必要だ。

まず、すべてのサブモジュール вместе с リポジトリをクローンする：

git clone --recursive --shallow-submodules https://github.com/Keeperorowner/NagramXF.git NagramXF

最初のクローン時に --recursive フラグを忘れた場合は、手動でサブモジュールをプルできる：

git submodule update --init --recursive --depth=1

次に、my.telegram.orgにアクセスしてログインし、新しいアプリケーションを作成して TELEGRAM_APP_ID と TELEGRAM_APP_HASH を取得する。これらなしでは、クライアントはTelegramサーバーで認証できない。

プロジェクトルートに local.properties ファイルを作成し、受領した認証情報を追加する：

TELEGRAM_APP_ID=1234567
TELEGRAM_APP_HASH=0123456789abcdef0123456789abcdef

通常の使用向けのリリースAPKをビルドする場合は、キーストアパラメータも追加する必要がある：

KEYSTORE_PASS=your_keystore_password
ALIAS_NAME=your_alias_name
ALIAS_PASS=your_alias_password

次に、コード内で数個のパラメータを設定する必要がある：

• TMessagesProj/src/main/AndroidManifest.xml でGoogle Maps APIキーを指定（位置情報共有を正しく動作させたい場合）。
• BaseRemoteHelper.java ファイルでメタデータチャンネルIDを指定。
• Google FCM経由でプッシュ通知が必要な場合は、 google-services.json を TMessagesProj/ にドロップ。

その後、プロジェクトはAndroid Studioで開かれ、標準の assembleRelease または assembleDebug タスクでビルドできる。

誰にとって有用か

NagramXFのようなクライアントは、2つのシナリオで興味深い。

1つはAndroid開発者にとってだ。メッセージ傍受者、ローカルストレージ、Telegramの巨大なレガシーモノリスへのパッチが実際にはどのように実装されているかを見たいなら、NagramXFはこれを明確に demonstratedしている。カスタムメニューの実装、ネットワークイベントのオーバーライド、NDKの使用などを覗くことができる。

もう1つは、基本的なTelegramバージョンに設定が制限されすぎていると感じる人にとってだ。NagramXFは、以前はAyuGramとexteraGramの間で選択する必要があった機能を組み合わせている。すべてが1 곳에集められている。

もちろん、リスクも考慮する必要がある：クローズドパッチを持つサードパーティクライアントの使用は、フォーク作者への信頼を必要とする。しかし、カスタマイズ可能なクライアントとオープンなビルドプロセスが必要な場合、NagramXFは興味深いexperimentのように見える。