サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
d.hatena.ne.jp/Kazzz
何日か前に嵌った件。 コントローラで初期化したJSONの配列をデータとしてng-repeatディレクティブ中で配列の要素をテキストボックスにng-modelでバインドしたいので、以下のように書いた。 js/controllers.js function PhoneListCtrl($scope) { $scope.phones = [ "Nexus one", "Nexus S", "GALAXY Nexus", "Nexus 7", "Nexus 4"]; } bind.html <!doctype html> <html lang="en" ng-app> <head> <meta charset="utf-8"> <title>Phones bind demo</title> <script src="lib/angular/angular.js"></script> <script
拙作のアプリケーション、Bootstrap2ベースでリリースしておりそこから1年も経過していれば気にもならなかっただろうが、開発中にBootstrap3が出てしまったせいで喉に引っかかった小骨のようにずっと気になっていたのだが、この連休が良いチャンスと思い一気にBootstrap3への移行をやってしまうことにした。 移行前のフロントエンドの構成は以下の通り。 ソフトウェア構成(2014/5/1時点) AngularJS v1.2.13 jquery-2.1.0 jquery.numeric.js 1.3.1 jquery-cookie 0.4 ※Twitter Bootstrap v2.3.2 Angular-strap v0.7.4 UI Bootstrap v0.7.0 (TPL有) TODC Bootstrap v2.3.0 Moment.js 2.1.0 Spin.js 1.3.3
アプリケーションをデプロイした後、利用者から「リロードしてもデータが最新にならない」「更新したはずのデータが書き変わらない」というクレームを受けたので調べてみると以下のようなログが出ていた。 データの更新後、$location.path("/path")内部パスを変える処理を行っているのだが、パスを変えた後のGETリクエストが全てHTTP 204で返って来ていることが分かる。(後で調べるとと304の時もあった) 普段、開発とテストに使用しているChromeでは見たことが無いので、UAを調べると案の定IE(IE10、IE11)だった。 調べてみるとIE(少なくとも10と11)はAjaxのリクエストを勝手にキャッシュするようで、このログが表示されている間はサーバに全く問合せに行っていなかった。 この問題(IEだけのようだが)解決するにはHTMLのヘッダーのようにリクエストのヘッダを明示的にキャ
AngularJSでページ遷移を実行する際に、ルーティングを端折ったり、従来のリダイレクトのようについつい低レベルのAPIで $window.location.href="#/foo/hoge?reset"; 等と書いたりすると※、一見上手く動くように見えたりするのだが(実際Chrome等では問題なく動作する)、AngularJSのダイジェストサイクルはWebブラウザ(のレンダリングエンジン)に依存するのかIEでは再帰エラーを起こしたりする。 Chromeでは問題ないのにIEではダイジェストループの再帰でエラーになる様子(IE11のデバッグコンソール) SCRIPT5022: [$rootScope:infdig] 10 $digest() iterations reached. Aborting! AngularJSはメジャーなWebブラウザを一通りサポートしているが、ブラウザのURLを
HTMLを幾つかの部品(ヘッダー、メール、フッター)に分け、それぞれのHTMLの断片をAngularJSのng-includeでインクルードしているとしよう。 main.html <div id="mainContents" class="span8" ng-controller="MainController"> <div> <div ng-include="'partials/mail.html'"/> </div> 〜 partials/mail.html <div class="row"> <form class="well span8 css-form" novalidate name="mailProjectForm" ng-controller="MailFormController"> <p class="lead">メールを作成して送信しますよ</p> <div> 〜 m
Google App Engine(以降GAE)のFull-Text Search(以降FTS)はデータストアでの全文検索を可能にする機能であり、 1. 検索の対象オブジェクトから検索の対象(候補)になる項目(名前、詳細、コメント、タグ等)を索引に登録 2. 検索ワードでインデックスに対して検索を実施 3. ヒットしたインデックスから対象オブジェクトを生成又は取得 という簡単な手順で全文検索を実施することができる。 GAE/FTSはいわゆる「転置インデックス(Inverted index)」を対象のオブジェクトと共に登録しておく方式であり、データとは別に索引用のオブジェクトを登録するコストがかかる代わりに、検索処理自体は軽くできるメリットがある。 コードではこのように索引をデータストアに登録して (面倒なので例外処理は省く) private static final com.google.
既に利用されている方々とほぼ同じ意見だと思うのだが、私がAngularJSを気に入って使っているのは 構造的に書ける MVVMぽい DOMを触らなくて良い ほぼこの3つに集約される。 1.構造的に書ける AngularJSはアプリケーションを書く際のコードを構造がほぼ決まっている。その構成はビューであるHTMLを除くと コントローラ サービス フィルタ プロバイダ ディレクティブ これらの要素に分類されDIにより疎に結合される。基本的には誰が書いてもこれらの要素を配置する必要がある訳で、同じ要素で構成されるということは他の誰かが書いたコードを読むことが比較的容易だということになる。(JavaScriptで最も苦痛なのは他の誰かが書いた、一か所に固まりすぎた又は逆に分散しすぎたコードを読むことである) 2.MVVMぽい 今のGUIプログラミングでMVCを意識するのはもはやテーブルマナーだろう
AngularJSはその規模としてはかなり大きい部類に入ると思うが、そのわりにはリソース(特に日本語)が少ないので学習するのには苦労する。 そんな中私が参考にしているリソースを紹介しておく。 (重複ご容赦) リファレンス 本家。何はなくともまずはここから。 AngularJS ― Superheroic JavaScript MVW Framework angular/angular.js · GitHubリポジトリ AngularJS: API Reference 非公式だがリファレンスの邦訳をされている方がいらっしゃる。とても有難い AngularJS 1.2 日本語リファレンス | js STUDIO @tomof アドオン、拡張用ライブラリィ 一緒に使うと色々捗るもの。ものによっては殆ど必須のものもある。 Bootstrap (CSSのフレームワーク、私は一緒に使っている) Ang
iOSアプリケーションでUITableViewCell中のUIViewを取得するのは難しくない。方法は幾つかあるが、例えばInterfaceBuilderで予めターゲットのビュー(コントール)にタグを打っておけばUITableViewCellのデリゲート中で以下のように取得できる。 - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { //cellにはInterfaceBuilderでcellIdentifier:"cell1"をセットしている NSString* cellIdentifier = @"cell1"; UITableViewCell* cell = [tableView dequeueReusableCellWithId
iOS6からiOS7への移行で困った点の第二弾。 バー系ビューの透過設定のデフォルトとTint(色合い)の違い iOSアプリケーションで重要な役割を占めるバー系のビュー(ナビゲーションバー、ステータスバー、ツールバー等)の背景は透過するのがデフォルトとなった。これはiOS7の基本的なデザインの考え方が透過、又は半透過のレイヤを重ね合わせることを前提にしているからだと思われる。 これも例を見てもらうと分かりやすい。 Xcode5でデフォルトで生成されたナビゲーションコントローラにおける、ナビゲーションバーのプロパティは以下のようになっている。 Navigation Bar/Bar TintとView/Tintに着目して欲しい。 この状態で実行するとiOS6、iOS7ではそれぞれ以下のようになる。 実行結果 (Translucent=YES, Bar Tint=Default, Tint=De
iOSアプリの開発を初めてから一年半というところだが、その間に一度OSのメジャーバージョンアップを体験している。その時はiOS5→iOS6であり、画面サイズも3.5インチから4インチであり互換性に心配したのだが、Xcodeのシミュレータとデザイナ(Interface Builder)で画面サイズの違いをきちんと使い分けることが出来たため、必要なアセット(リソース)を用意すれば良くあとは細かいAPIの違い程度だった。 で、今回はiOS6→iOS7である。また今回もXcode側で違いを吸収してくれるものだと思っていたので、正直あまり心配はしていなかったのだが、いざ既存のプロジェクトを新しい開発環境であるXcode5に移行するに辺り、それほど簡単ではないことが分かって困惑しているところだ。 iOS6以前とiOS7のデザインの違い これは色々な所で語られているので、敢えてここで取り上げなくても良い
先日のエントリでも書いたが、iOS6→iOS7への移行で最も酷いなと感じたのはステータスバーの問題である。 ステータスバーのレイヤの違いと画面に与える影響 iOS7においてはステータスバーはコンテンツとは完全に独立したレイヤとして扱うことになったようで、基本的に透過レイヤであり座標系もビューのルートと共有していない。つまりはiOS6までのアプリケーションをiOS7上で動かすとこのようにステータスバーがビューに覆い被さるように描画されてしまう。 この問題はステータスバーを表示している、つまりフルスクリーンを使う画面以外全ての画面が影響を受けてしまう凶悪なものだ。 ステータスバーをiOS6同様に非透過レイヤとすることで回避できそうなものだが、iO7ではステータスバーを非透過にする事は(今のところ)方法は無いので、これに合わせるしかない。ということは...iOS6まででステータスバーを透過にデザ
前に書いたことがあるが、iOSプログラミングにおいてちょっとしたポップアップ/ダイアログを作るのには結構難儀する。 カスタマイズされたダイアログのベースになるのはUIAlertViewを使うケースが多いのだが、元々このクラス、テキストボックスを増やす位のカスタマイズしか考慮しておらず、通常のUIViewを配置することなど考えていないようで、実際に書いたことがある開発者ならば分かると思うが、継承してちょっと凝ったものを作ろうとするとかなり苦労する。 martinjuhasz/MJPopupViewController martinjuhasz/MJPopupViewController Martin Juhasz氏作のMJPopupViewControllerはUIViewControlerのカテゴリと半透明の背景ビューにより、通常のビューを恰もポップアップ/ダイアログのように表示してくれる
AndroidとiOSは一般的には似たような画面を持ったアプリケーションを開発していると思われがちだが※、実際には両プラットホームでの画面を構成する部品にはかなりの違いがある。 その違いは画面を構成するUIコントロール(View)において顕著であり、一通り汎用的なUI部品を提供するAndroidに対して、iOSは一貫した画面の見栄えや操作性を実現するために提供されており、互いに同じ用途のUIコントロールを使えるとは限らない。 そこで互いの移植においては悩まないために両プラットホームのUIの対照表を作ってみたのが下の表。ただし、全ての用途を対象にすると凄く多くなるので、アプリケーションでなにか情報を入力、選択するために使用するUIコントールに限っている。 UIコントロール対照一覧 UIコントロールAndroidiOS(UIKit) ラベルandroid.widget.TextViewUILa
AngularJSは素晴らしいフレームワークでありJavascriptのイベント処理を意識することはあまりないのだが、それでも皆無ではない。 私がそれを必要としたのは、特定の要素が変更されたことを他で検出したいケースだ。 AngularJSはコンテナとなる要素、例えばdiv要素毎にコントローラを配置できる。コントローラは要素と同じ親子関係を持つが、基本的にはスコープとして他と分離、隔離されており互いに影響を与えない設計となっている。 ※ これ自体は非常にスマートで理にかなった設計なのだが、分離されているが故に他の要素を変更を検知するためには仕掛けが必要になるケースがある。 $scope.$broadcast 接頭に$が付くものはAngularJSが使用する予約された変数だが、そのうち$scopeは最も多用する変数であり、コントローラが定義されたスコープ(要素)に対してAngularJSが必
ng-optionsディレクティブはng-repeat同様に列挙子風の記述するのだが、モデルとのバインドの仕方がちょっと分からなかったので、メモ 例えばコントローラーの$scopeにこのようなJSONモデルがあったとして js/controllers.js function CategoryController($scope) { $scope.categories = [ {name:'スマートフォン', value:'smartPhone'}, {name:'タブレット', value:'tablet'}, {name:'ノートPC', value:'notepc'}, {name:'デスクトップPC', value:'desktop'} ]; $scope.category = $scope.categories[0].value; } HTMLはこんな感じで。 index.html
AngularJSはデータCRUDを主な用途としたHTMLアプリケーションを開発するための優れたフレームワークだが、まだ開発されてから日も浅く足りないものもある。それを補完するための様々なサブプロジェクト群をスートとして提供するのがAngularUIだ。 AngularUI for AngularJS AngularUIは以下のコンポーネント/サイトに分かれており、サイトも別で導入もそれぞれ別に行う。 UI-Utils : 外部ライブラリィへの依存無しに使えるユーティリティ群 UI-Modules : 外部ライブラリィへの依存が必要なAngulaJS標準モジュール UI-Alias : リネームされたディレクティブ(AngularJS独自の属性)と、テンプレート UI-Bootstrap : Twitter Bootstrapチームが書いたAngularJSネィティブUI NG-Grid
E2EテストをWebStormから実行できるようになったので、最後の仕上げとして同karmaを使ったテストをWebStormからデバッグしてみる。 が、これがまた中々分からなかった。 karmaのwebサーバはポート9876で起動されるので、デバッガはそのポートにアタッチするような実行設定を用意すれば良いのは分かるのだが、スクリプトのテストを行うためのスタブ用のHTMLが無いのにどうやって(どのURLを指定して)起動するのか? 答えは、この動画にあった (12:18辺りから) Testacular (now Karma) - JavaScript Test Runner - YouTube デバッグの実行設定で注意する点は以下。 WebStormデバッガが開く際のURLは(デフォルトのポートならば) http://localhost:9876/debug.html プロジェクトのリソースル
昨日のエントリではKarmaを使ったテストの実行について書いたが、それは主にユニットテストの話。 AngularJSによるテストにはもう一つ、E2E(End to End)つまり受け入れテスト用のテストができるようになっている。 AngularJSのTutorialでは、ユニットテスト用のconfig/testacular.conf.jsに対して、E2Eテスト用のtestacular-e2e.conf.jsが用意されている。 testacular-e2e.conf.js basePath = '../'; files = [ ANGULAR_SCENARIO, ANGULAR_SCENARIO_ADAPTER, 'test/e2e/**/*.js' ]; autoWatch = false; browsers = ['Chrome']; singleRun = true; proxies
WPFで書いたアプリケーションで、サーバ側(Javaで書かれている)にURLに含めたクエリパラメタを送信するために、文字列にURLエンコードを施す処理をstringクラスの拡張メソッドに組み込んで使っていたのだが、送信したパラメタがJava側で正しく受け取れないことに気が付いた。 public static string UrlEncode(this string str, Encoding encoding = null) { return HttpUtility.UrlEncode(str, encoding ?? Encoding.UTF8); } エンコーディングは双方共UTF-8であり、問題はないはずだが正しく受け取れない。 C#は面倒なことにURLエンコードのためのAPIが他にいくつかあるのだが、 HttpUtility.UrlPathEncode(str) HttpUtili
この日記に記述されている内容は、個人的な主張や考えであり、私が勤務する企業や属する組織とは全く関係ありません。
このページを最初にブックマークしてみませんか?
『KazzzのJとNのはざまで』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く