Jordan Meyer and Mathew Dryhurst founded Spawning AI to create tools that help artists exert more control over how their works are used online. Their latest project, called Source.Plus, is…
Kotlin/Native Multiplatform プロジェクトで Android/iOS 向けの共通ライブラリを作るAndroidiOSKotlinKotlinNative Kotlin/Native の Multiplatform プロジェクト (MPP) を使って、Android/iOS 両方に対応したライブラリを作成します。 Kotlin/Native MPP ライブラリプロジェクトは、Android アプリと iOS アプリとでなるべく実装を共通化を目指して設計します。 本記事のサンプルプロジェクトは irgaly/kotlin-multiplatform へ設置しています。 公式のドキュメントは Multiplatform Project: iOS and Android が近いと思います。 Kotlin/Native を Android/iOS アプリ開発に導入していくモ
Flutter を使う機会があったので、所管をざっくりと。 個人的に思うFlutterを使う際に留意すべき点 Flutterのレンダリングは Skia ベースの独自エンジンで動いている Android的に言えば、どんな画面もView1枚である Plugin実装を読むと、 TextureId を取得してカスタムレンダリングしているものも多い マルチプラットフォーム対応 でありながら、 よく使われる WebView とのかみ合わせが悪い WebViewの上にFlutterのViewを置くことが難しい Pluginをforkして頑張るか? これが 何 を示すかは、人それぞれである レンダリングが OpenGLベースとは限らない ので、iOS/Android両対応と言いつつ気軽に「おっしゃーごりっとOpenGLで書くかー」みたいなことはできない iOSはDeprecatedである Metal Na
『メルカリ』 アプリの画面描画を高速化する技術、バックエンド・iOS・Androidの基本設計 多くのユーザーに愛されるフリマアプリ『メルカリ』ですが、そのスムーズな画面描画はどのような技術で生み出されているのでしょうか。同アプリの高速表示の秘密を、バックエンド、iOS、Androidの3方向からメルカリ社のエンジニア4人に聞きました。 バックエンドの高速化を支える技術 【Tips1】 画像のファイルサイズを最適化し、アプリ全体の通信量を抑える 【Tips2】データセンター間通信のレイテンシを抑える 【Tips3】アプリのありとあらゆる挙動を常にモニタリングする iOSアプリの高速化を支える技術 【Tips4】Objective-CからSwiftへの移行 & アーキテクチャの刷新 【Tips5】『UIStackView』を活用し、UIの描画をより滑らかにする Androidアプリの高速化を
Stetho便利ですよね〜。 最近Stethoを置き換えるfacebook/Sonarというライブラリが登場しました。 メトリクスツールのSonarとかDAWのCakewalk SONARとかとかぶってて名前紛らわしいっすね〜 facebook/Sonarでできること StethoはAndroid向けのライブラリであったのに対し、SonarはAndroidとiOSの両方の環境をサポートしています。 また独立したElectronアプリを提供していて、Chrome Dev Toolsをポチポチする必要がなくなりました。やったね。 SonarにはBuilt-inのプラグインがいくつかあります。とりあえず現状あるやつを紹介しときます。 Logcat Logs · Sonar SonarのElectronアプリを起動するととりあえずLogcatが見れます。アプリ側で特に対応とか入れなくても適当につな
Flutter を実際にリリースしているプロダクトに採用してみて半年ほど経ったので、その経緯と Flutter についての感想を記しておきます。 The English version is on Medium! Flutter についてFlutter は、クロスプラットフォームでモバイルアプリを開発するための開発フレームワークです。 特徴- 言語は Dart - フルスタックのUI framework (Material and iOS) - Reactive (inspired by React) - Material and iOS - GPU を利用して UI を描画するところまで全て (Skia) - オープンソース on GitHub - developed by Google and community - ネイティブのARMコードにコンパイル - 開発用プラグイン - In
Nuco Advent Calendar 7日目の記事です。 Design | Android Developers Human Interface Guidelines ちなみに上記の両記事を既にお読みの方は本記事を読む必要はありません。 ブラウザの戻るボタンをクリックしてください。 スマホアプリのデザイン 恐らくほとんどの人はAndroid、iOSのどちらか一方しか所持していないですよね? お近くに自分と異なるOSを使っている人がいたら、是非アプリのUIを見比べてみましょう。 思っていたより違うんじゃないでしょうか? 特に有名なアプリはほぼデザインが異なるはずです。 メニューバーはiOSは画面下部、Androidは画面上部にあるのではないでしょうか? (もちろんそうでないアプリもあると思いますが。) あるある話なのかはわかりませんが、スマホアプリの開発を行うときにデザインが一種類しかな
あなたの会社のドメインには、ハイフンが含まれていますか? ドメイン名にハイフンを含めるのはSEO的に良くないとか、外人さんからはカッコ悪いと言われるらしい(逆に日本人はハイフンを入れたがるらしい)のですが、実は私の所属している組織のドメインには、残念なことにハイフンが含まれています。 だから何だという話ですが、これがTitanium MobileでiPhone/Android両対応のアプリを開発しようとしたときに、ちょっと面倒臭いことになりました。 App Idのハイフン問題 問題となったのはApp Idです。 何かしらアプリを作ろうとしてTitanium Mobileのプロジェクトを作成しようとした場合、初めにApp Idと呼ばれるアプリを識別するためのIDを付けます。 このApp Idは一般的に、ドメインを逆から並べたもの+アプリケーションを表す文字列という組み合わせにすることが慣例と
アプリリリースあるある ・クライアント「アプリリリースってどうやるの?名義はうちで出したいから作業全部やって」 ・受託請負企業「分かりました。つきましてはアカウントのID/PWを教えていただけますか?」 ↑ やり方として、上記は絶対よくない。 iOSとAndroidアプリであればGoogleアカウントとAppleIDを教えることになるが、口座情報も見えるしスマホからログインすれば不正にアプリ買いまくったり、iTunesでお買い物し放題、自社が関わってるアプリ以外にもアクセスできるので公開中アプリを全部停止できる。 「そんなことしないし、クライアントからも信頼されているので大丈夫」とかもよくない。 仮に自分が個人でクライアント一人でも、そのアカウントに何かしらの不正行為やアプリを間違って削除した場合などにも自分が疑われる。それがクライアント本人が意図的にやったとしても、自分の身の潔白を晴らす
前回はてぶのお気に入りフィードを読むHBFavというアプリのReactNative版RNHBFavというアプリを作っているという話を書いたが、とりあえずAppStoreへ申請するところまで終わった。 razokulover.hateblo.jp 申請がどのくらいで通るかはまだわからないが、たぶん1週間はかかる気がする。 少し時間が空きそうだし、ここらで今回ReactNativeで開発〜リリース申請する中で感じたことやこうした方が良かったみたいなものをメモしておこうと思う。 垂直分割/水平分割のディレクトリ構成 ディレクトリ構成はプロジェクトごとにみなそれぞれ自分なりの構成を持っているようだけど、例えばreduxを利用するアプリだと以下のような作りになると思う。 index.ios.js index.android.js src |__actions |__hoge.js |__reduce
アプリの譲渡・移行は実施が稀で情報が少ないので、誰かの役に立てばと書き残しておきます。 一番大切なのは、公式ドキュメントを熟読することです。 が、わりと誤りや不明点もあるので、問い合わせにかかる時間も含めて余裕を持ちましょう。 また、厳密な予定を組むのは不可能と心得て、関係者の合意も取りましょう。 移行の公式ドキュメント iOS 日本語版:https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide_Jpn/Chapters/TransferringAndDeletingApps.html 日本語版2:https://developer.apple.com/library/content/documentation/LanguagesUt
⚠ ものすごく雑に調べた内容をまとめているだけなので、間違ってるかも。 TL;DR Web サイトのパスワード管理と同じように、アプリにおいてもパスワードマネージャから自動的にテキストフィールドに入力する仕組みができた。 Android O はマネージャアプリを選択して、参照および保存することができる。 iOS 11 は Safari や iCloud キーチェーンに保存されている情報を参照のみすることができる。 Autofill の登場 従来、アプリケーションがログイン機能を持つ場合には、よくあるログインフォームへ ID と Password を打ち込みますが、それらの情報はアプリ内部で閉じているのが当たり前でした。 サービスやアプリごとに異なる高い強度のパスワードを使い分けたい場合、パスワード管理アプリを使うのが一般的でした。 iOS 11 / Android O では共に Passw
スマホのアプリを開発する上で端末を識別するのに何が使用できるのか調べたのでまとめておきます。 各識別子 Android/iOS共通 ・MACアドレス ネットワーク機器に一意に割り当てられるアドレス。 通常変更はできないが、脱獄などしている場合はできる模様。 ネットワークアダプタが搭載されてない場合や無効になっている場合は取得できない。 ・IMEI(International Mobile Equioment Identity、国際移動体装置識別番号) 携帯電話など通信端末に付与される番号。15桁の数字。 通常変更はできるものではないが、もし変更すると違法となる。 端末を一意に識別できる。 ・MEID(Mobile Equipment Identifier) IMEIと同じで携帯電話に付与される番号。15桁の数字。 フォーマットもIMEIと同じだがコチラは16進数になっている。 ・ICCID
4月13日に開かれたpotatotips勉強会#39に参加してきました。 メモったものと、取った写真、上がってるスライドをまとめましたが、一部理解できず、メモをとれてないセクションもございますので、 他のブログ(http://colorbox.hateblo.jp/entry/2017/04/15/003950 ,http://sanpeisbllog.blogspot.jp/2017/04/potatotips-39-iosandroidtips2017413.html) で参考ください。 個人的には、懇親会でお話した馬鹿にされるPHPの実は隠れたすごい所が面白かったです。 1.Swiftでプレゼンしたら何が起こるか 喋る内容を書いてるものを読み上げるだけでは、聴衆はつまらなく感じる。 口からでてくるのと同じ情報を文字でスライドに乗せてもいいことなどない。 Steve jobs プレゼン
libGDX的にも推奨していそうなIntel Multi-OS Engineについて。 https://github.com/libgdx/libgdx/wiki/Setting-up-your-Development-Environment-(Eclipse,-Intellij-IDEA,-NetBeans) Intel Multi-OS Engineを使えばJava or Kotlinでクロスプラットフォームのアプリが作成可能とのこと。 前回のMobile Open JDK9の話に続き、調査してみようと思います。 AndroidもiOSにも対応、Mobile OpenJDK 9について Intel Multi-OS Engineとは Intel Multi-OS Engineはあの「インテル入ってる」でおなじみ?な Intelが開発しているクロスプラットフォーム用のライブラリです。 O
はじめに 2016/12/01 に行われた Rollout.io MeetUp に参加してきたので、そこで聞いた話をベースに Rollout をご紹介いたします。 Rollout とは Rollout は iOS 向けのアプリケーションに審査なしでパッチを当てるためのサービスです。 いろんな方が経験していると思うのですが、アプリをリリースしたものの、重大なバグを見つけてしまった場合、再度アプリを審査に出して反映を待つ必要があります。しかもストアに反映されたとしても、ユーザーはアプリを再度落とし直さないとその修正は反映されません。 Rollout を用いると、Web のインターフェースから JavaScript でパッチを作成することで、審査なしですぐにバグの修正や機能の解放を行えます。これによって、通常は再度審査をはさむ必要があるバグ修正であっても、アプリのユーザーはアプリを落とし直す必要
背景 Webからアプリに遷移させたくてFirebaseのDynamic Linksを使って実装をしてみました。 やりたかった事は、WEB側でアプリのインストール判定をして、アプリに飛ばす or ストアに飛ばすといった事でした。 自前で実装するよりも大分楽だったので、使ってみて良かった点と躓いた点を書きたいと思います。他の方が使うときの参考になれば良いなぁと思います。 Dynamic Linksの良いところ 簡単に設定することができる Dynamic Linksの生成は、Firebaseのコンソール画面から聞かれることをポチポチと入力をするだけです。 また、iOSとAndroidの両OSを同時に設定することも出来るため、リンクの管理も楽です。 OSを気にする必要がない Dynamic Linksを使う前は、OSの判定やOSのバージョンによって処理を分けるといったことをやっていましたが、Dyn
Strategy Analyticsの最新の調査によると、2016年第3四半期の世界スマートフォン出荷台数は3億7500万台となり、「Android」OSが88%のシェアを占めた。同四半期は、スマートフォン出荷台数の前年比増加率でも過去最高を記録した。「Androidが伸びた一方で、主な競合プラットフォームはすべてシェアを落とした」とStrategy AnalyticsのLinda Sui氏はプレスリリースに記した。 「Appleの『iOS』はAndroidに押され、(市場)シェアが12%に減少した」という。中国とアフリカで販売が「振るわなかった」ことが要因だという。「BlackBerry」とMicrosoftの「Windows Phone」 は「ほぼ姿を消した」という。 Androidの優勢は「覆しようがない」ように見えるが、スマートフォン市場では数えきれないほどのメーカーが製品を開発す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く