squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
iOS とAndroid の違い クロスプラットフォームのアプリデザインで特に気をつけるべき点｜marin
私が一番最初にAndroid アプリをデザインしたのが2016年の初夏頃で、その頃はまだiOS・Android とデザインが違うのが主流でしたが、2021年現在のアプリはiOS もAndroid もプラットフォームごとの細かな違いはあれどほぼ同じデザインが主流となっています。 これは2016年の10月にAndroid APIがBottomNavigationView に対応してからじわじわ浸透していった変化だと考えているのですが、その辺の歴史の話は省略します。プラットフォームは違えどスマートフォンアプリである以上デザインは同じ方が楽なので、共通化されていったのは自然な流れだと思います。実際両者が全然違うUI・デザインだと大変ですしね……。 とはいえ、プラットフォームが違うので全て同じというわけにもいきません。iOS にはHuman Interface Guidelines、Android
現代のモバイルゲーム開発者が向き合うべき ディスプレイ事情と、その対応方法
はじめに 現代では多くの人々がスマートフォンやタブレットを所持し、ゲームを楽しんでいることと思います。 モバイル向けのゲーム市場は大きく、世界では今も多くの開発者たちが iOS / Android 向けの商用ゲームを作っています。 さて、モバイルゲームの開発には、多くの開発者を悩ませるちょっと困った事情があります。 それは ディスプレイが非常に多くの多様性を持っている ことです。 正方形に近い形のタブレットもあれば細長い端末もあり、カメラがディスプレイの中に割り込んでいたり、 OS が専有する領域があったりと様々です。物理的な大きさもバラバラですね。 そのくせモバイル端末はタッチパネルで、ディスプレイに触れる UI になっているのです。 ゲーム開発を生業とする多くのエンジニア / アーティスト / ゲームデザイナーは、 これまでに何度も頭を抱えてきたことでしょう。 本稿では、2019 年現
「AndroidはiOSと同じデザインで！」と言われたときの対応案 - Qiita
はじめに 「AndroidはiOSと同じデザインで！」と言われてどう実装しようか悩んでる方向けの記事です。 Androidアプリを作るなら当然マテリアルデザインガイドラインに合わせて1から画面設計するのが最高なんですが、そうはいかないことが経験上多いので対応案をざっくりまとめました。 諸注意 これは「iOSとAndroidのUI対応一覧」ではありません。 iOSとAndroidで同じような見た目のUI部品でも作られた経緯や目的は違うので、比較して置き換えるようなことは基本的にできないと思います。 とはいえなんの指標もないと辛いので、ここでは「iOSのこのUIをAndroidで代用できるのはこれかもね」くらいのニュアンスで列挙しています。 必ずしもどのアプリにも言えるようなことではないので、あくまでたたき台と思ってください。 「なぜAndroidらしくする必要があるのか」についてはこ
Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
長らく Y.A.Mの雑記帳というブログでAndroidの技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事でAndroid アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち
Bye, Bye Burger!
I exactly remember what I was doing when the news broke on March 15 — we were knee deep in the concept phase for moving towards a visible tab navigation and away from a burger menu in our Android Job Search App, when Google announced that a new bottom navigation will be added to the Android Material Design Guidelines. The news spread like wildfire through the Android community, including heated de
ここ最近読んだ技術書籍感想文。 - なるようになるかも
雑多に読んでます。 リンクは書籍の公式サイトです。 黒帯エンジニアが教えるプロの技術 Android開発の教科書 SBクリエイティブ:黒帯エンジニアが教えるプロの技術 Android開発の教科書 （ヤフー黒帯シリーズ） 幅広いトピックを扱っているのだけれど、それゆえにどこかで読んだ本の内容を簡略化しているだけの章もあったり、開発以外のトピックの割合が多かったり、Andorid 開発の高度な技術トピックを期待すると中途半端かもしれないという感想でした。 同時期により初心者向けと思われる「基本からしっかり身につくAndroidアプリ開発入門 Android Studio 2.x対応」という本も出版されていたので、こちらのトピックでよかったんじゃない？という内容もちらほら。 また、アプリのグロース関連の章については、Firebase の登場で大きく変わった部分が多く、タイミングの悪い感じです。
自分が知っているAndroidライフサイクルのツラミとベストプラクティスのすべて - Qiita
何が辛いのかとそのツラミを減らす方法について説明してみます（今すぐ導入したら解決！みたいなのはまだちょっと出せてないです）。 TL;DR→ライフサイクル理解してるぜ！という人はベストプラクティスからどうぞ・・！ 前提1: Androidのコンポーネントとプロセス Androidの主なコンポーネントはActivity, Service, Content Provider, Broadcast Receiverです。これらはアプリをまたがると原則別のプロセスになります。 また、あまり知られていないことですが、AndroidManifest.xmlに記述することで1つのアプリ内でも別のプロセスとして起動することができます。逆に、特別な設定をすれば同じプロセス内で2つのアプリを実行することもできます（普通しない）。 https://developer.android.com/guide/compo
モバイルナビゲーションの基本パターン：入門編
モバイルのナビゲーションは発見やアクセスが容易で、スペースを取らないものである必要がある。ナビゲーションを表示することと、表示せずにハンバーガーメニューの中に入れることには、それぞれ一長一短があるので、モバイルのナビゲーションでジレンマに陥ったときの好ましいソリューションはサイトのタイプによって異なってくる。 Basic Patterns for Mobile Navigation: A Primer by Raluca Budiu on November 15, 2015 日本語版2016年1月14日公開 ナビゲーションが検索の補完になるのは以下の理由からである： ユーザー自身が何を検索したらよいのかがわかってない場合もあり、検索領域の区分けがどうなっているかの見当をつける手助けが必要なことがあるから。 適切な検索キーワードを考えだし、それを入力するには、ナビゲーションリンクを再認して、
その Dialog は本当に必要ですか？ - Qiita
ダイアログは、ユーザとの対話の中でも特に「確認」や「注意」を促すために用いられる UI コンポーネントの一つです。二択あるいは三択の項目を配置して、YES/NO や OK/Cancel などのインタラクションを用意することで、ユーザとの対話をすることが出来ます。あるいは、単に現在の状態を表示（読込中など）し、その他の各種操作をブロックすることで、待つ必要が有ることを明示することも出来ます。 一方で、ダイアログはその表示が画面の前面に大きく表示され、時にダイアログ以外へのインタラクションを禁じる場合もあることから、使いどころを間違うと非常に鬱陶しく見えるものでもあります。また、ダイアログのキャンセル操作が出来ない場合において、いつまでもダイアログが出続けてしまうとユーザの負担は大きくなります。 この記事では、ダイアログを使用している場面において、その他の表現方法や実装の工夫を使うことができる
ドロワーというナビゲーションの再考 | UXデザイン会社Standardのブログ
以前Facebookのアプリケーションで採用されたことを皮切りに、ここ数年で多くのアプリケーションで使われることになったドロワーというナビゲーションについての考察です。 最近ネット上でも話題になっており、安易なナビゲーションへの採用が見直されているされているインターフェイスでもあります。しかしドロワーの必要性について疑うことは良いのですが、表面的にただドロワーを使ってはいけないという情報に左右されていては、安易なドロワーはなくなったとしても、次に安易なタブなどが量産されるということが予測できます。 UIに関わるデザイナーとしては、なぜドロワーが適していないのかということと同時に、どのような状況下であればドロワーが適しているのかは考え続ける必要があるでしょう。 ドロワーの歴史 まず名前の由来としては、たしか2013年にAndroidでナビゲーションドロワーのためのフレームワークが公開されたこ
モバイルアプリのObserverパターン - cockscomblog?
ReactiveCocoa勉強会関西にてObserverパターンについてお話ししましたので、以下にその内容をまとめます。 Observerパターンは、GoFの23のデザインパターンのうちの一つで、モデルが状態の変化をしビューに通知するパターンです。GUIアプリケーションの開発で多用されます。もちろんスマートフォンアプリの開発においても大変役に立つので、いくつかの例を挙げて見ていきます。 Objective-CのKey-Value Observing static void * Context = &Context; - (void)anything { [object addObserver:self forKeyPath:NSStringFromSelector(@selector(property)) options:NSKeyValueObservingOptionNew conte
ListViewのデータのbindはこうする2014 - Rejasupoem
基本の割に初心者にとって使うのにハードルが高いview、ListView。 ネット調べると色んなパターンで書かれた例が出てくると思います。 何も知らずにAndroid 1.6とかの時代に書かれたような出どころが不明なサンプルコードをコピペしてうまくいかなくて心が折れるみたいなことを防ぐために、インターネットに出回っているサンプルコードをパターン化して列挙しました。パターン1が一番良くなくて、パターン3あるいはパターン4にするといいと思います。 インターネットで調べててAndroid 1.6とか2系の葬式UIが出てきたら、それは昔に書かれたものでそっと閉じたほうがいいです。 Adapterとは AdapterはviewとDataSourceの橋渡しをするものです。 private void setupListView(List<User> userList) { UserAdapter ad
Material Designの目指すところとAndroid側の変更点 - クックパッド開発者ブログ
モバイルファースト室の @rejasupotaro です。 今年のGoogle I/OではAndroid One、Android L、Material Design、Android Ware、Android Auto、Android TV、Google Cloud Platform、Google Fitなどの発表がありました。弊社からは私と @sys1yagi と @__gfx__ が参加したので、何回かに分けてGoogle I/Oの発表の内容を紹介します。 今回のテーマはMaterial Designです。内容は公式ドキュメントやセッション動画の要約や参考リンクからの引用を含みますが、筆者の考察や主観も含まれます。 Material Designとは Material Designとは、Googleが発表したビジュアル、モーション、インタラクションのプラットフォームやデバイス間の包括的な
AndroidのダメなUX、UIパターン - あぷすた - iPhoneとWebとプログラミングと
Androidアプリを開発する上でこれはダメなUX、UIをGoogleのエンジニアが動画で詳しく紹介してくれます。 iPhoneアプリ開発にも通ずるところがあるので必見です。 要点をまとめておきます。 読み込み中のダイアログを頻繁に出さない 何度も出るとうざいし、読み込みをキャンセルできないと端末を叩き付けたくなります。 解決策としては、アクションバーの下にプログレスバーを出したり、コンテンツの表示部分だけにロード中のマークなどを出すようにする。 ボタンが小さすぎる 縦、横48dp以上が望ましいです。 ダイアログの「はい」「いいえ」ボタンの位置を標準に合わせてね フィードバックがない ボタンや選択できるエリアをタッチしたら何らかのフィードバックを。 選択部分の色を変える。pressとfocusedの状態を用意するとなお良いです。音もありかな。 UIデザインはこだわりすぎない やりすぎず、あ
Design Principles of Android Wear (Japanese Translation) - 安藤日記
------------------------------------------------------------ Android Wear のデザイン原則（日本語訳） ------------------------------------------------------------ Design Principles of Android Wear（原文） http://developer.android.com/wear/design/index.html Android Wear デバイスは、ネットの世界に接続されたり、現実世界に存在したりできるように、ちょうど適切な時にだけ適切な情報を提供してくれます。 ここに Android Wear プラットフォームにおける、素晴らしいユーザーエクスペリエンスを設計するためのガイドラインを示します。Android Wear を設計す
やさしい設計 〜 Android 編 - Qiita
アプリを作っていてありがちなこと Android には、画面を構成するための Activity というコンポーネントがあり、概ね MVC フレームワークの Controller に相当する機能を持っています。 MVC といえば、肥大化する Controller というのがよくある問題として挙げられますが、Activity も例に漏れず、往々にして肥大化しがちです。 また、Model も、その責務を詰め込んでいくと肥大化しやすいレイヤと言えます。 この投稿では、Controller や Model の肥大化を極力防ぐためのレイヤわけを、Android アプリ向けに書いていきます。 Activity を綺麗に保つ Activity は、Controller として、様々な UI から受けるイベントを受けて、適切にハンドリングする役割を持っています。 OptionsMenu や ContextM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
Android Pattern Cookbook で見るトレンドの変遷
