ビールが美味しい季節ですね！ 最近飲みすぎて嫁に叱られて、飲み会自粛中のデザイナー・ マエダ です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、デザインについて私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「DLS の導入について」です。発表資料は記事の最後をご覧ください。 DLS（デザイン言語システム）とは DLS とは DesignLanguageSystem の略で、すごい単純にいえばデザインガイドラインみたいに UI に一貫性をもたせるため、配色やレイアウト、タイポグラフィやマージンなどのルールを策定するもの です。 私が主に担当しているオンライン診療アプリ「 CLINICS 」は、iOS、Android、Web と 3 つのプラットフォームで運用しているのですが、入社した当初はプラットフォーム毎に違った UI やルールで開発しており、サービスとして一貫性のあるサービス体験を提供できるとは言えない状況でした。また新たに機能を追加する際、それぞれ違なるデザインをしなければならず、デザイン作業においても負荷がかかっていました。 DLS が必要な理由 CLINICS ではプラットフォームごとに異なる UI を提供していたため、一貫したサービス品質をユーザーに提供できていないこと、開発者ごとに UI に対して認識にズレが生じていたことが課題でした。それに伴い開発速度も決して速いとは言えず、どうにか一定の品質を担保しつつ開発スピードも改善できないかと悩んでいたところ、Airbnb の開発者ブログで Airbnb Design System という記事を見かけました。 これまでのデザインガイドラインは単にカラーやマージンの定義を取り決めるだけだったのですが、 Airbnb ではデザイン言語として定義し、他の言語と同じようにチームと共有し、エンジニア・デザイナー同士で理解できる設計を作り上げている といった内容でした。 ※参考 medium.com 私がデザイナーとしてサービスデザインに携わる重要な役割のひとつとして、単にデザインをするだけでなく デザインを通して UI 設計の制約をつくり、継続的に運用しやすいプロダクトに仕上げること があると思っています。 DLS を起点として、各プラットフォームの開発者が共通の認識でシステム開発が行えれば、これまで以上にスピーディが開発が行え、一貫性のある体験をユーザーに提供できるプロダクトにできるはずだと考え、CLINICS 独自の DLS を開発することにしました。 CLINICS の DLS の一部 DLS を導入してどうなったか CLINICS では、Android、iOS、web で担当するエンジニアが異なるのですが、DLS を設計しシステムの詳細を共有することで、UI に対しての共通認識が生まれ、一貫した品質を担保できるようになりました。さらにこれまでエンジニアだけでデザインを考えて悩んでいた時間を、コンポーネント設計で組み立てたデザインを DLS で定義したことで、UI に悩むことなく機能ロジックに重点を置いた開発に専念できるようになったのではないかと思います。 デザイン言語でサービス設計の基礎を築けたことで、開発だけに追われていた状況から、より良いサービスを作るためにはどんな UX をユーザーに提供すべきかという声がエンジニアからも頻繁に声が上がりはじめたことも良かった点です。 エンジニア陣が UI について熱い議論を交わしている様子 TechLunch では、こうした内容について実際に作ったコンポーネント設計なども見せながらお話しました。発表資料はこちら。 speakerdeck.com まとめ DLS 導入以前は、エンジニアが開発に追われていたということもあり、プラットフォーム毎に議論ができていなかったエンジニアがお互いの担当プラットフォームを意識したコミュニケーションがとれるようになったことは予想外に良かった点です（別に仲が悪かったとかそういうことではなく w）。 さらに DLS で UI の基盤をつくったことで、デザイナーが手を動かさずともコンポーネントの組み合わせを話し合うだけで、エンジニア完結で一貫した品質で機能実装できるようになりました。これにより私も次の施策やプロジェクトに専念できるようになり、効率的に仕事ができるようになりました。 まだデザインルールに一貫性がないプロジェクトを担当しているデザイナーやエンジニアは、ぜひ DLS の導入を検討してみてはいかがでしょうか。 単にデザイン品質だけでなく、チームコミュニケーションも改善されるとおもいます。 より詳しく話を聞きたいかたは、気軽に「 話を聞きに行きたい 」をクリックしてみてください。ビールを飲みながらデザイン談義をしましょう！（嫁に怒られない程度に w） メドレー開発本部について、もっと詳しく知りたい方はこちらからどうぞ。 www.medley.jp www.wantedly.com

ビールが美味しい季節ですね！ 最近飲みすぎて嫁に叱られて、飲み会自粛中のデザイナー・ マエダ です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、デザインについて私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「DLS の導入について」です。発表資料は記事の最後をご覧ください。 DLS（デザイン言語システム）とは DLS とは DesignLanguageSystem の略で、すごい単純にいえばデザインガイドラインみたいに UI に一貫性をもたせるため、配色やレイアウト、タイポグラフィやマージンなどのルールを策定するもの です。 私が主に担当しているオンライン診療アプリ「 CLINICS 」は、iOS、Android、Web と 3 つのプラットフォームで運用しているのですが、入社した当初はプラットフォーム毎に違った UI やルールで開発しており、サービスとして一貫性のあるサービス体験を提供できるとは言えない状況でした。また新たに機能を追加する際、それぞれ違なるデザインをしなければならず、デザイン作業においても負荷がかかっていました。 DLS が必要な理由 CLINICS ではプラットフォームごとに異なる UI を提供していたため、一貫したサービス品質をユーザーに提供できていないこと、開発者ごとに UI に対して認識にズレが生じていたことが課題でした。それに伴い開発速度も決して速いとは言えず、どうにか一定の品質を担保しつつ開発スピードも改善できないかと悩んでいたところ、Airbnb の開発者ブログで Airbnb Design System という記事を見かけました。 これまでのデザインガイドラインは単にカラーやマージンの定義を取り決めるだけだったのですが、 Airbnb ではデザイン言語として定義し、他の言語と同じようにチームと共有し、エンジニア・デザイナー同士で理解できる設計を作り上げている といった内容でした。 ※参考 medium.com 私がデザイナーとしてサービスデザインに携わる重要な役割のひとつとして、単にデザインをするだけでなく デザインを通して UI 設計の制約をつくり、継続的に運用しやすいプロダクトに仕上げること があると思っています。 DLS を起点として、各プラットフォームの開発者が共通の認識でシステム開発が行えれば、これまで以上にスピーディが開発が行え、一貫性のある体験をユーザーに提供できるプロダクトにできるはずだと考え、CLINICS 独自の DLS を開発することにしました。 CLINICS の DLS の一部 DLS を導入してどうなったか CLINICS では、Android、iOS、web で担当するエンジニアが異なるのですが、DLS を設計しシステムの詳細を共有することで、UI に対しての共通認識が生まれ、一貫した品質を担保できるようになりました。さらにこれまでエンジニアだけでデザインを考えて悩んでいた時間を、コンポーネント設計で組み立てたデザインを DLS で定義したことで、UI に悩むことなく機能ロジックに重点を置いた開発に専念できるようになったのではないかと思います。 デザイン言語でサービス設計の基礎を築けたことで、開発だけに追われていた状況から、より良いサービスを作るためにはどんな UX をユーザーに提供すべきかという声がエンジニアからも頻繁に声が上がりはじめたことも良かった点です。 エンジニア陣が UI について熱い議論を交わしている様子 TechLunch では、こうした内容について実際に作ったコンポーネント設計なども見せながらお話しました。発表資料はこちら。 speakerdeck.com まとめ DLS 導入以前は、エンジニアが開発に追われていたということもあり、プラットフォーム毎に議論ができていなかったエンジニアがお互いの担当プラットフォームを意識したコミュニケーションがとれるようになったことは予想外に良かった点です（別に仲が悪かったとかそういうことではなく w）。 さらに DLS で UI の基盤をつくったことで、デザイナーが手を動かさずともコンポーネントの組み合わせを話し合うだけで、エンジニア完結で一貫した品質で機能実装できるようになりました。これにより私も次の施策やプロジェクトに専念できるようになり、効率的に仕事ができるようになりました。 まだデザインルールに一貫性がないプロジェクトを担当しているデザイナーやエンジニアは、ぜひ DLS の導入を検討してみてはいかがでしょうか。 単にデザイン品質だけでなく、チームコミュニケーションも改善されるとおもいます。 より詳しく話を聞きたいかたは、気軽に「 話を聞きに行きたい 」をクリックしてみてください。ビールを飲みながらデザイン談義をしましょう！（嫁に怒られない程度に w） メドレー開発本部について、もっと詳しく知りたい方はこちらからどうぞ。 www.medley.jp www.wantedly.com

ビールが美味しい季節ですね！ 最近飲みすぎて嫁に叱られて、飲み会自粛中のデザイナー・ マエダ です。 メドレーでは TechLunch という社内勉強会を実施しているのですが、デザインについて私も発表する機会をいただきましたので、その内容を紹介させていただきます。テーマは「DLS の導入について」です。発表資料は記事の最後をご覧ください。 DLS（デザイン言語システム）とは DLS とは DesignLanguageSystem の略で、すごい単純にいえばデザインガイドラインみたいに UI に一貫性をもたせるため、配色やレイアウト、タイポグラフィやマージンなどのルールを策定するもの です。 私が主に担当しているオンライン診療アプリ「 CLINICS 」は、iOS、Android、Web と 3 つのプラットフォームで運用しているのですが、入社した当初はプラットフォーム毎に違った UI やルールで開発しており、サービスとして一貫性のあるサービス体験を提供できるとは言えない状況でした。また新たに機能を追加する際、それぞれ違なるデザインをしなければならず、デザイン作業においても負荷がかかっていました。 DLS が必要な理由 CLINICS ではプラットフォームごとに異なる UI を提供していたため、一貫したサービス品質をユーザーに提供できていないこと、開発者ごとに UI に対して認識にズレが生じていたことが課題でした。それに伴い開発速度も決して速いとは言えず、どうにか一定の品質を担保しつつ開発スピードも改善できないかと悩んでいたところ、Airbnb の開発者ブログで Airbnb Design System という記事を見かけました。 これまでのデザインガイドラインは単にカラーやマージンの定義を取り決めるだけだったのですが、 Airbnb ではデザイン言語として定義し、他の言語と同じようにチームと共有し、エンジニア・デザイナー同士で理解できる設計を作り上げている といった内容でした。 ※参考 medium.com 私がデザイナーとしてサービスデザインに携わる重要な役割のひとつとして、単にデザインをするだけでなく デザインを通して UI 設計の制約をつくり、継続的に運用しやすいプロダクトに仕上げること があると思っています。 DLS を起点として、各プラットフォームの開発者が共通の認識でシステム開発が行えれば、これまで以上にスピーディが開発が行え、一貫性のある体験をユーザーに提供できるプロダクトにできるはずだと考え、CLINICS 独自の DLS を開発することにしました。 CLINICS の DLS の一部 DLS を導入してどうなったか CLINICS では、Android、iOS、web で担当するエンジニアが異なるのですが、DLS を設計しシステムの詳細を共有することで、UI に対しての共通認識が生まれ、一貫した品質を担保できるようになりました。さらにこれまでエンジニアだけでデザインを考えて悩んでいた時間を、コンポーネント設計で組み立てたデザインを DLS で定義したことで、UI に悩むことなく機能ロジックに重点を置いた開発に専念できるようになったのではないかと思います。 デザイン言語でサービス設計の基礎を築けたことで、開発だけに追われていた状況から、より良いサービスを作るためにはどんな UX をユーザーに提供すべきかという声がエンジニアからも頻繁に声が上がりはじめたことも良かった点です。 エンジニア陣が UI について熱い議論を交わしている様子 TechLunch では、こうした内容について実際に作ったコンポーネント設計なども見せながらお話しました。発表資料はこちら。 speakerdeck.com まとめ DLS 導入以前は、エンジニアが開発に追われていたということもあり、プラットフォーム毎に議論ができていなかったエンジニアがお互いの担当プラットフォームを意識したコミュニケーションがとれるようになったことは予想外に良かった点です（別に仲が悪かったとかそういうことではなく w）。 さらに DLS で UI の基盤をつくったことで、デザイナーが手を動かさずともコンポーネントの組み合わせを話し合うだけで、エンジニア完結で一貫した品質で機能実装できるようになりました。これにより私も次の施策やプロジェクトに専念できるようになり、効率的に仕事ができるようになりました。 まだデザインルールに一貫性がないプロジェクトを担当しているデザイナーやエンジニアは、ぜひ DLS の導入を検討してみてはいかがでしょうか。 単にデザイン品質だけでなく、チームコミュニケーションも改善されるとおもいます。 より詳しく話を聞きたいかたは、気軽に「 話を聞きに行きたい 」をクリックしてみてください。ビールを飲みながらデザイン談義をしましょう！（嫁に怒られない程度に w） メドレー開発本部について、もっと詳しく知りたい方はこちらからどうぞ。 www.medley.jp www.wantedly.com

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 https://www.medley.jp/jobs/ https://www.medley.jp/team/creator-story.html

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

今回の内容について みなさん、こんにちは。開発本部でオンライン診療アプリ「 CLINICS 」の開発を担当している 平木 です。 弊社では、インフラ・サーバ・フロントで役割を区切らず、全ての開発メンバーが必要に応じてスキルを広げながら開発に取り組んでいます。 自分も入社前はフロントエンド専門のエンジニアでしたが、入社後はそれに加えて Rails を使ったサーバサイドの開発や、Swift を使った iOS アプリ開発、 そして、現在メインにやっている Android 開発と一通りのプラットフォームや言語を使って開発するようになっています。 エンジニアが自身のスキルを広げる場合、自分の経験や知識を応用して、新しいプラットフォームを理解していくということが多いと思います。 元フロントエンジニアの経験を持っている自分が Android 開発に関わってみて やりやすかった部分 や つらかった部分 などを書いていこうと思います。同じような立場でこれから開発しようと思う方には少しお役に立てるかもしれません。 やりやすかった部分 Android Studio のありがたさ いきなり IDE の話になっていますが。やはり Android Studio のオールインワン感がとても便利です。Web フロントエンドの開発だと IDE といえば WebStorm など使ったことがありましたが、ライブラリを含めた補完周りなどはやっぱり Java などでの開発した方が IDE は力を発揮しやすいんではないかと思いました。 とりあえずほとんど設定をいじらなくても、補完やドキュメントの参照ができるのはラクです。また JS などで変数に変換してもあんまり便利さが湧きませんが、 Java の場合だと勝手に対応した型もつけてくれたりと至れり尽くせりだと思いました。 ゲッターセッターなども手作業でやると単純作業になりますが、⌘N で勝手に展開してくれますし、Java での開発の冗長な部分をあまり感じないで開発できるのが凄いです。 エミュレータなども自分が使い始めたときは既に起動も高速な感じでしたし、エミュレータの管理なども Android Studio 内で完結するのであまり迷ったりすることがないです。また初心者に優しいなと思ったのが、Activity など作るのにテンプレートがちゃんと用意されてるのであまりファイル構成が分かってない初めの頃でもちゃんと画面を作ることができるところです。 ビルドシステムが分かりやすい ご存知 Gradle ですが、通常の使い方してる分には(あまり Gradle でがんばらなければ)、WebPack とかよりも書きやすいよねと思います。もちろん目的が違いますが。 フロントエンド開発でよく陥りがちな「設定ファイルなんだかプログラムなのか分からないくらい作られた」というような設定ファイルにはなりにくいんじゃないかと感じています。 build.gradle で設定した環境変数などもソースからさっと使うことができますし、良く考えられてるなーと思いました。 公式のライブラリであれば、 build.gradle で lint としてライブラリの更新があることが分かるのも親切です。サードパーティのライブラリもこれがされてるととても嬉しいんですが、 Analyze -> Run Inspection by Name -> Newer Library Versions Available で見てくれるんでガマンしてます。 View 部分の作り方がフロントエンドに似ているので取っつきやすい これは HTML / CSS を書いていた人間からすると大変に敷居が低いと思いました。 使うパーツは最初はどんなものがあるのか分からないのでドキュメント引いたり、 Design タブからパーツを選択したりして View を作ってましたが、HTML を組む感覚でガンガンと作っていけました。 基本的には HTML タグのなかで style 属性付けていくみたいな感じです。 margin とか padding とかも同じですし、 textAlign なんかもあるので初期のころは本当に助かりました。 もちろん AppBarLayout とか Toolbar とか Theme など Android 独自の概念はありますがそういった差分的なものは知識として覚えていけば良いだけなので、フロントエンドに慣れていると大変に View 作るのがラクだと感じます。 iOS の StoryBoard は未だにつらい。 ググったときに古めの情報を参考にしても問題が解決できる後方互換性の高さ ここ数年フロントエンドの技術的な流れが早すぎるというのは一般的に良く言われていますが、良い意味で Android は古い情報もちゃんと使えるというのはとても助かりました。 一番古いので 2011 年くらいの情報だったら使えました。(もちろん廃止されてる…というのも多いのですが) 初めのうちは フロントエンドだとこうやるけど Android ではどうするんだろう というような疑問が多いと思うのですが、特に View に関わるような問題などは古い記述でも問題なく使える後方互換性の高さのおかげで「ググったように書いたのに、今は使えない…」というストレスからかなり開放されます。 つらかった部分 ライブラリや画像を気軽に入れにくい これついては、フロントエンドの JS などでも別に気軽にさくさくとライブラリを入れていたわけではないですが、いざ入れようとすると Android(というよりもネイティブアプリ全般か)の場合全て APK の容量増加という自体に直結するので中々気をつかいます。 さすがにゲームでもないのに容量重いアプリにするとそもそもダウンロードしてもらえるかどうかも怪しくなります。パッケージする画像なども多用するような仕様にしないようにしています。 あと最初のころにビルドできずに困るわ…と思って必死に対応を調べた 64K 参照制限 も一回設定してしまえば何てことはないんですが、割と初見殺しだと思います。 また実際にプロダクション用にビルドするとなるとフロントエンドでもおなじみのソースの難読化をするのですがその際にライブラリのなかで難読化しちゃいけないなどの指定をしないと余裕で動かなくなります。 ということで各ライブラリを使うときには ProGuard の設定をしないといけないのですが、これも気軽にライブラリ使おうと中々ならない理由でした。 バッググラウンドプロパティ関連の貧弱さ 良い点のところで HTML / CSS と View の作りが似ているので幸せと書いたんですが、1 つだけ許せないことがありまして、それが バックグラウンドプロパティ関連のプロパティの貧弱さ というものです。 どういうことかというと…例えばこんな感じのラベル作るとします。 HTML / CSS だったら楽勝だと思います。 < span class = "radius" > 診察待ち </ span > .radius { border-radius : 12px ; padding : 4px 12px ; background-color : #89c8ba ; color : #ffffff ; } しかし Android の場合は < TextView android:id = "@+id/upcoming_list_status" android:textSize = "14sp" android:layout_width = "100dp" android:layout_height = "wrap_content" android:textAlignment = "center" android:background = "@drawable/label_status_upcoming" android:textColor = "#FFFFFF" android:text = "診察待ち" /> とテキスト作ったうえで、 background の指定先のベクターアセットを作ってやらないといけません。 このアセットが padding や background-color など指定されているというものになります。 <? xml version = "1.0" encoding = "utf-8" ?> < selector xmlns:android = "https://schemas.android.com/apk/res/android" > < item > < shape android:shape = "rectangle" > < stroke android:width = "1dp" android:color = "@color/label_status_upcoming" /> < corners android:bottomLeftRadius = "12dp" android:bottomRightRadius = "12dp" android:topLeftRadius = "12dp" android:topRightRadius = "12dp" /> < solid android:color = "@color/label_status_upcoming" /> < padding android:left = "12dp" android:right = "12dp" android:top = "2dp" android:bottom = "2dp" /> </ shape > </ item > </ selector > とても面倒です。 リストがつらい 配列になっているデータを取り出してリストとして表示するという状況、良くあると思います。 フロントエンドなら <ul/> で囲んだなかの <li/> にデータを forEach() やら map() やら使って作っていくのが常道ですが、Android は手順が多いので面倒です。 このようなお知らせのリストを作るのに… public class NotificationItemHelper { private String message ; private String link ; private String patientName ; public NotificationItemHelper ( String message , String link , String patientName ) { this . message = message; this . link = link; this . patientName = patientName; } public String getMessage () { return message; } public String getLink () { return link; } public String getPatientName () { return patientName; } } リストに表示するためのクラスを作ってあげて、 public class NotificationListAdapter extends ArrayAdapter < NotificationItemHelper > { private int layoutResource ; public NotificationListAdapter ( Context context , int resource , List < NotificationItemHelper > objects ) { super (context, resource, objects); this . layoutResource = resource; } @ NonNull @ Override public View getView ( int position , View convertView , ViewGroup parent ) { View view = convertView; if (view == null ) { LayoutInflater layoutInflater = LayoutInflater . from ( getContext ()); view = layoutInflater . inflate (layoutResource, null ); } NotificationItemHelper notificationItemHelper = getItem (position); if (notificationItemHelper != null ) { TextView message = (TextView) view . findViewById ( R . id . notification_list_message ); TextView patientName = (TextView) view . findViewById ( R . id . notification_list_patient_name ); if (message != null ) { message . setText ( notificationItemHelper . getMessage ()); } if (patientName != null ) { patientName . setText ( notificationItemHelper . getPatientName ()); } } return view; } } それを View に表示させるための Adapter というものを作り、 <? xml version = "1.0" encoding = "utf-8" ?> < LinearLayout xmlns:android = "https://schemas.android.com/apk/res/android" android:id = "@+id/upcoming_list" android:layout_width = "match_parent" android:layout_height = "match_parent" android:paddingStart = "@dimen/spacing_small" android:paddingEnd = "@dimen/spacing_small" android:orientation = "horizontal" > < LinearLayout android:layout_width = "0dp" android:layout_height = "wrap_content" android:layout_weight = "1" android:paddingTop = "@dimen/spacing_small" android:paddingBottom = "@dimen/spacing_small" android:orientation = "vertical" > < TextView android:id = "@+id/notification_list_message" style = "@style/TextBoldStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" /> < TextView android:id = "@+id/notification_list_patient_name" style = "@style/TextNormalStyle" android:layout_width = "match_parent" android:layout_height = "wrap_content" android:layout_marginBottom = "@dimen/spacing_xsmall" android:textColor = "@color/text_color_secondary" /> </ LinearLayout > < ImageView android:layout_width = "wrap_content" android:layout_height = "wrap_content" android:layout_gravity = "end|center_vertical" android:src = "@drawable/ic_keyboard_arrow_right_black_24dp" /> </ LinearLayout > 実際のリストの内容を xml で作ってあげて、 < ListView android:id = "@+id/notification_list" android:layout_width = "match_parent" android:layout_height = "match_parent" /> リストのラッパーを指定して List < NotificationItemHelper > notificationItemList = new ArrayList <>(); ListView notificationListView = findViewById ( R . id . notification_list ); List < NotificationResponse > notifications = notificationsResponse . getNotificationResponses (); for ( Notification notification : notifications) { NotificationItemHelper item = new NotificationItemHelper ( notification . getMessage (), notification . getLink (), notification . getPatientName ()); notificationItemList . add (item); } NotificationListAdapter notificationListAdapter = new NotificationListAdapter ( this , R . layout . notification_layout , notificationItemList); notificationListView . setAdapter (notificationListAdapter); ここまでやってようやくリストが表示されます。未だに面倒だなーと思います。 最後に 色々と細かい例を上げましたが、いかがでしょうか。 今回は書いてませんが、ライブラリも JS とは考え方違って面白いなあと思うものがあります。特に View パーツを簡単に選んだり、イベントを書くことができる ButterKnife やバリデーションライブラリの Android Saripaar のように Java のアノテーションを付けるだけで簡単に使える部分などは Java に触れてこなかった身としては新鮮でした。 全体的な印象としてはプラットフォーム特有のクセなどはもちろんありますが、フロントエンドエンジニアでもかなり取り組みやすいのではないかと感じています。何より Android 実機で自分が作ったものが動いてるのを見るとブラウザで自分が作ったサイトが動いているというのとは一味違った達成感があります。 もちろん開発していく内に、たとえば JS にはないスレッドの概念が立ち塞がったり Android 特有のライフサイクルに悩まされたりもしますが、公式のドキュメントも充実していますし、Stack Overflow など見て解決することがかなり多いです。 これを読んで Android 開発やってみようと思っていただけたら良いなと思います。 もっといろいろ知りたいという方は「 話を聞いてみたい 」ボタンを押してもらえれば！ お知らせ メドレーでは医療業界に存在する課題に IT を駆使して取り組んでいきたいデザイナー・エンジニアを募集中です。 皆さまからのご応募お待ちしております。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の 宮内 です。 先日、社内勉強会「TechLunch」にて WebPushAPI についての発表を行いましたので、その紹介をさせていただきたいと思います。 WebPushAPI とは？ 一般的にプロダクトにおいて、 スマートフォン アプリのような「プッシュ通知」を導入しようと思った場合、いままでは専用のアプリケーションを開発する必要がありました。 しかし、プッシュ通知に関する API が W3C で標準化が進み(まだドラフト状態とはいえ)、 Google Chrome のバージョン 42、 Mozilla Firefox のバージョン 44 に、WebPushAPI が導入され、元来ある Web アプリケーションに簡単にプッシュ通知を取り込むことが可能になりました。 詳しくは ウェブアプリへのプッシュ通知の追加 、 Using the Push API や、 WEB+DB PRESS Vol.97 などを読むとより理解が深まるので興味ある方はぜひ読んでみてください。 TechLunch でやったこと TechLunch では、自分が実際に実装した WebPushAPI のサンプルコードを元に、動作を示しながら挙動を開発本部の全員で追っていきました。 speakerdeck.com 具体的な手順などもスライドにありますが、公開したものだけだとちょっと分かりにくいかもですね。ごめんなさい。 もっと詳しく聞きたいなって人がいたら、気軽に ここらへん にある「話を聞きに行きたい」ボタンを押下してみてください。 お知らせ メドレーでは、医師たちがつくるオンライン医療事典「 MEDLEY 」、オンライン診療アプリ「 CLINICS 」、医療介護の求人サイト「 ジョブメドレー 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。 www.medley.jp www.medley.jp

開発本部の楊です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しております。うるさい 5 歳のこどもと一緒に遊ぶのが大好きです。 ジョブメドレーの求人機関向け管理画面は React.js を利用し開発しています。 他プロダクトを担当するメンバのなかには React.js について詳しくない人もいる為、TechLunch（開発本部内で定期的に開催している社内技術勉強会）で React.js 入門について話しました。 React.js とは UI を構築するためのライブラリ Facebook 社が開発しているライブラリでコミュニティも活発で安心して使える 多くの コンポーネント が提供されており開発が捗る（参照： https://github.com/brillout/awesome-react-components） などなど、様々な特徴があります。 TechLunch での発表内容 React.js は UI を構築するためのライブラリなのでデータフローを管理する仕組みは提供していません。 開発の際にはデータフロー管理のために、Flux/Immutable.js などの考え方や技術要素を必要とします。 今回の TechLunch の発表では Flux/Immutable.js についても簡単に触れつつ発表しました。 目次はこちら。 React.js Flux Immutable.js 詳細はこちらをご覧ください。 まとめ 全ては Component、シンプルに保つことを意識する 小さく Component を作り、組み立てることにより UI を構築する Flux と併用しデータフローを意識する Immutable.js 便利 最後に React.js は比較的新しい技術で、仮想 DOM の使用によりブラウザの レンダリング が早いなどの利点が多々あります。 必要に応じて新しめの技術も取り入れながら、ジョブメドレーをよりよいプロダクトにしていきたいと思っています。 お知らせ メドレーでは、ジョブメドレーだけでなく、医師たちがつくるオンライン医療事典「 MEDLEY 」やオンライン診療アプリ「 CLINICS 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」などのプロダクトも提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 今後ともメドレーを、よろしくお願いいたします！ www.medley.jp www.medley.jp