Habrachtetsまたはこの夏のように

こんにちは



この記事では、何を始める必要があるか、すべてがうまくいくかについての投稿に触発され、数多くのインスピレーションの結果とAndroid OS用アプリケーションの開発経験について話を共有したいと思います。 アイデアの出現から実装までのプロセスを説明しようとします。



昨年の夏、2か月半の完全な自由が与えられ、その半分はプログラムの作成に費やしました。 私は初心者ではありません-私の卒業証書は最初の十分な深刻なプロジェクトでしたが、この特定のアプリケーションは私に名声をもたらすと思います。

その時に私がソースを持っていたもの：

• 時間
• Galaxy Tab
• ADTプラグインを使用したEclipse IDE

のようです。 そしてここにハブラ？



しかし、それで。 あなたの注意-Habrachtets：







すでに述べたように、今年の6月末に、私は2、3か月間、あらゆる種類の雇用から解放されようとしていました。 そして、朝起きて、市場で慎重に提供された3つのニュースアプリケーションのうちの2つをタブレットで開いて、それらを注意深く研究する習慣を作りました。 そして、何、非常に便利です。 湯気を立てるコーヒー、バルコニーからの眺め、サンドイッチ、そしてこれからのホームワイヤレスWi-Fiが私の一日の始まりとなりました。



Habraclientの不在だけが彼のハエを軟膏に追加しました-あなたはOperaを開いて、サイトに行き、スクロールし、調整しなければなりませんでした...それは簡単なことではありませんが、それでも指一本で押すのはそれほど簡単ではありませんが、特に手にコーヒーを1杯入れて考えると。 これらの瞬間のどこかで私は思った。 そして私は決めました。 私がすでに持っていたアプリケーションの似ているサイトのクライアントを書いてみてください。



ソースは何でしたか：

• HabrのWebページに含まれるすべての情報
• サーバーの束である論文の作成経験-クライアント、クライアント（ドラムロール）、はい、はい-Androidアプリケーション
• Eclipseとプラグイン
• Galaxy Tab

タスクで設定されたもの：

• コンポーネントのページの分析：投稿、質問、イベント
• 各要素は、投稿であろうと質問であろうと、サイト上のオリジナルを含むすべてのものを含む必要があります
• お気に入りに追加してデバイスに保存する機能
• オリジナルのスタイルと構造を保持するシンプルなインターフェース
• そして最後に、ハイライトは「未来のために保存」モードです（本質は明確だと思います。少し後で説明します）

ソース素材に4週間を掛けたもの（この2か月の実働日-何らかの理由で海に行きました）は実を結びました-今ではインターネットがあればどこでもHabrrを読むことができます。



さらにいくつかの詳細。

データとその処理

技術的には、アプリケーションは非常に単純です。 私は当然、Habr APIにアクセスできませんでした。 私は振り向かなければならなかった。 だから、段階的に。

habrachterは、ハブのアドレスに要求を行い、 HttpUrlConnection



を使用してHTML



コードをHttpUrlConnection



ます。 この操作は、明らかな理由により、非同期です-インターフェースをブロックするべきではないため、ブロックしません。 アクションのシーケンスは単純です-ボタンを押す、バックグラウンドタスクを開始する、Habrに接続する、コードを受信し、通知（ Broadcast



）を通じて特別なIntent



埋め込まれたString



オブジェクトの形式で関心のあるActivity



に渡す 特別なことは何もありません。



グルメ：ただし、上記のシーケンスにはキャッチがありました。 アプリケーション（および一般的なシステム）内でデータを転送するには、インテントオブジェクトを使用します- Intent



、アラートで送信- Broadcast



だからここに。 投稿の内部コンテンツが数回ロードされたくなかった。 つまり ログによってさえ、アプリケーションがHabrを検出し、ページコードをロードしたことは明らかでしたが、それから...何もありませんでした。 一般的に。 沈黙。 アプリケーションはフリーズしませんでしたが、何も起こりませんでした。 再起動は役に立ちませんでした。 コンテンツは表示されませんでした。 問題はより良い時代まで残され、ほとんど偶然によって説明されました。



実際、すべての新しい投稿と新しい投稿は簡単かつ自然に読み込まれました。 しかし、古いものや多くのコメントを含むものを読むことはもはや不可能でした。 ログの注意深い（！）読み取りは、システムエラーに関する奇妙な行を明らかにしました - !!! BINDER TRANSACTIONに失敗しました!!! 気付かないのは難しいですよね？ だから気づかなかった。 すぐに他の「ゴミ」で詰まった唯一の行。 それが問題でした。 グーグルは、送信に使用されるデータが特定の制限を超えた場合にこれが発生することを示しました。 彼は行のサイズ-600,000文字を測定し始めました。 しかし、100件のコメントすらありませんでした！ 一般に、彼はクリーニング手順を追加し、いくつかのテストを実施し、1行あたり25万文字に等しい制限を見つけました。 これで、クリーニング後でもサイズを超えた場合、行がトリミングされ、すべてのコメントが使用可能になるわけではありません（*叫び*）。

解決するには、少なくとも数段階でデータを転送するのであれば、問題は比較的簡単です。 次のアップデートで解決されると思います。



さらに、サイトのWebページのHTMLコードは、目的のコンポーネントに処理されます。 これを行うには、 Jsoupライブラリを使用します-これは優れた機能で、指定したタグと属性に必要なすべてのデータを取得できます。 1行のタブレットで十分です。

 Document document = Jsoup.parse(html);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、その後、要素の分析。



グルメの場合：単一行処理後に取得されるDocument



クラスのオブジェクトは、必要な内部要素を取得するための2つのオプションを提供します。 「通常の」ゲッターの助けを借りた最初の：

 //         Elements contentElements = document.getElementsByAttributeValueContaining("class","hentry");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目は、より便利な一般的なselect()



メソッドを使用しselect()

 //  : document.select(".page-navigation .info-text [class*=live] ");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、2番目のオプションの方がはるかに便利で、コードの量を減らすことができます。 1行は、「page-navigation」および「info-text」に等しいclass属性を持ち、「live」という単語を含む要素を検索します。 ただし、パフォーマンスに大きなメリットはありませんでした。



必要なタグと属性ではない「キャッチ」は手動で実行されました。 彼は各ページを1ページずつ取り、私が必要な要素とそうでない要素を目で見ました。 開発者に感謝します-すべてが明確で理解しやすいものでした。 彼はHabrへの主な言及で同じことをしました。



HTMLの処理後、対応するタイプの別のオブジェクトが作成されます。これは、ポスト、質問、またはイベントであり、その後、key = idで対応するテーブルに書き込まれます。 テーブルは静的になり、シングルトンクラスであるDataManager



を介してアプリケーション全体からアクセス可能になります。 java.ioパッケージとContext.getDir（）を使用してメモリに保存されます。



グルメの場合：前の行を読んだAndroid開発者は、「私も...」のように、非常に不平を言って自分自身に考えていると思います。 事実、この場合はjava.ioを使用するべきではありません（これは既に理解しています）が、当然、より良いデータベースです。 Javaでは、オブジェクトは参照によって渡されるため、常に更新する必要がありますが、当然のことながら、それを些細なこととして忘れてしまう可能性があるため、読み取りおよび書き込みのエラーに正確に関連する大量のエラーを見つけました。 もちろん、チェックと更新で失われる速度は、実際には喜びをもたらさず、アプリケーションに速度を追加します。この場合の減少は線形であり、記憶される要素の数に依存します。 私は悔い改めました。 それが速くなったという事実ではなく、確かに簡単にならなかったわけではありません。

一般的に、やり直されます。 100％



投稿のメインテキスト（およびその他の資料）の表示には、若干の問題がありました。 多くのアプリケーションは、この目的のためにWebView



を使用します。Webページの特別なビューは、ネットワークから素材をロードできる非常に強力なツールであり、既存のものを表示します。 私にとって、その「欠点」は力でした。 たとえば、注釈はドロップダウンリストアイテムとして実装されますWebView



を使用すると、より多くのコンピューティングリソースが必要になります。 したがって、選択はTextView



で行われ、 Html.fromHtml(…)



メソッドからHtml.fromHtml(…)



オブジェクトを受け取りました。 これは非常に効果的な方法で、 TagHandler



を使用して目的のタグの表示TagHandler



カスタマイズし（たとえば、「コード」が私のお気に入りです）、 ImageGetter



から画像をアップロードできます。



グルメ：写真とImageGetter



について デフォルトでは、バックグラウンドでロードすることはできません-インターフェイスはブロックされました。 これは簡単かつ簡単に解決されます-バックグラウンドタスク、キャッシュディレクトリへの読み込み、最後にTextView



更新。

何らかの理由で、問題がないわけではありません。 habrastorageではなく、主に外部リソースからの一部の写真は、1つを介してロードされます。 これまでの理由はつかめませんでした。 私はそれに取り組んでいます。

パン

編集モードでは、関心のある素材を指定して、コンテンツをダウンロードできます。 プログラムはすべてをメモリに記録し、後で、たとえば地下鉄で仕事をする途中でそれらを読むことができるようになります。

すべてのリスト全体、すべてのテープを一度に削除、お気に入り、またはいくつかの点を選択して削除することができます。

トラフィックにお金をかけたくなく、投稿のアノテーションに興味深いリンクが表示されている場合、長押しすると、利用可能なすべてのリンクのリストが表示されます。 同じことが回答とコメントのリンクにも当てはまります。

必要に応じて、投稿へのリンクをメールに送信することができます。 私は原則としてそれを必要としません-アカウントを持っている人は彼らが後で好きな投稿にコメントするためにそれを必要とするかもしれません。 将来的には、アルファ版で予定をカレンダーに追加します。

ビデオディスプレイについては、通常のリンクに置き換えています。 私が想像できない唯一のものはポッドキャストです。 正直なところ、私もまだ試していません。 それでもWebView



に戻る必要がある場合があります。

そして、もちろん、「非常に」モバイルネットワーク用の写真なしのダウンロードがあります。

インターフェース

プログラムのメインビューは、最初のスクリーンショットからわかるように、Habrの3つの主要で最も興味深い（私にとっては自分で書いた）セクションを繰り返すタブです。 開発プロセスの終わりに向かって、アイデアはスライド効果を使用することでした-スライド指ジェスチャーを使用してセクション間を切り替えます。 しかし、圧倒的なオリジナルにマッチしたいという欲求。 さらに、主な外観とその時までにすでに非常に複雑であったため、変更にはまともな時間が必要です。

プログラムで使用される色、および主要な要素の場所-日付、著者名、テーマもHabrから取得されます。 写真とアイコン（メニューにあるものを除く- それらはsdkからはまりました ）彼は自分でペイントしました。 そして、はい...私はデザイナーではありません（*悲しいことにため息*）。 しかし、私はすでにここにあるものを試しました。



グルメの場合：それでも、詳細が豊富なリストアイテムは使用しないでください。 「まあ、それを使用することはできません」という境界線を越えていないにもかかわらず、それはきちんとブレーキをかけます。 私はそれを使用します。 この問題の解決策は、たとえば、デバイスの画面に表示される要素をキャッシュ、ロード、および削除する特別なアダプターです。 たとえばこれ。



次-文字数が減り、スクリーンショットが増えます：

性能

技術的な機能（3GなしのGalaxy Tab、モデルP1010）を考慮して、私はWi-Fiのみを使用しました。 ホーム回線は8 Mbpsです。 いくつかのカフェでは、主観的に少ない。 違いは感じませんでした

主な問題は、消費されるトラフィックの量です。 答えは、通常のブラウザーからHabrにアクセスするのと同じくらいです。

同様に重要な質問は、すべてが迅速に機能することです。 答えは十分に速いです。 既に述べたように、新しい投稿、質問、イベントについては、測定に応じて、最大2〜3秒で処理が迅速に行われます。 多くのコメントがあり、素材でさえ膨大なものである場合-もっとあるかもしれません。 測定の記録-10秒。 そうですね 防衛において、私はそれが本当に一度だったと言うでしょう。 平均して-5秒未満。

数値はテキストの表示に有効であり、画像は非同期に読み込まれ、読み込み後に表示されるため、読み取りへの影響は考慮されませんでした。

リストのスクロール速度ListView



は別に言及する価値があります。 遅くなりますが、耐えられます。 不要なように、最大​​70個の要素のリストを操作しました。

結論

プログラムを書くプロセスは素晴らしいです。 実際、私は書くのがとても好きで、おそらく実際にアプリケーションを使用するよりも多かったでしょう。 それでも、プログラマーは、彼らが何と言っても創造的な人々です。 数行を書いて結果を見るのは本当に幸福です。

私はフリーランサーの「理論的な」役割で自分自身を試しました。 そして、私はあなたに言います、それは湧き出ていません。 自宅では、コンピューターとバックグラウンドを作成するテレビが1日中ほぼ1日（私はすでにすべての広告を学びました）。 結局のところ、少なくとも何らかのコミュニケーションが同じオフィスで行われます。 また、生きています。 すべてが働いているので、昼食は1つです。 そして、もしあなたが興味深い問題に出くわすなら、それは週末に行かせないかもしれません。 映画の中でも、一行の文字数に問題があると自分自身で考えました。 そこにあるもの-私は彼女の父と友人に説明しました！ インテント、ブロードキャストについて。 そして、私は冶金学者です、彼女は生物学者です...

うまくいけば、大学で学んだ知識を実践することができました。 実用的かつ理論的。 そして、もちろん、新しいものを入手してください。 そして最も重要なのは、彼らの欠点のいくつかについて学ぶことです。 たとえば、「私はそれを機能させる」などの便利なメソッドを書いてから、すべてを忘れてコードを記述します。 私は悔い改めました、プロセスの一般的な組織は足を引きずっていました。

主なもの

私が自分で理解した主なこと。 どんなプロジェクトでも（著者でなくても）成長し、さらに改善するためには、常にインスピレーションを受ける必要があります。 あらゆるものがインスピレーションの源になります-金銭的、道徳的、競争力のある見通し、仕事への平凡なニーズなど。 プロジェクトがタスクを遂行し始め、作成者とユーザーの両方を満足させると、開発は停止します。 Khabrachtetsの場合、私は現時点で著者であり、唯一のユーザーです。 しかし、その開発を停止させたくありません。 それが私がそれについてあなたに言った理由です。

だから、床があります。