スマホアプリのUIデザインとプログラム作成の分離

スマホアプリ開発について。
どうもUIデザインとプログラム作成を物理的にも別々のチームで実施しなければならいようで、「UIデザインの成果物とプログラム作成の成果物」をなんとか分離できないものかと画策しています。

まぁ世間のアプリ開発しているチームの大半はデザイン担当とプログラム作成担当は隣のデスクで分離なんていらないのかも知れませんが…。

まず、AndroidについてはXMLにレイアウトが集約されており、ActivityクラスからXMLの名前をしていし、そこからXML上に設定された各部品のidを指定する事ができるので、こちらはUIデザイン担当はXMLの作成とidの指定をすれば良いであろう、という見解になりました。

問題はiOSについてで、どうやらStoryboardを何も考えずに使うと、ViewとControllerクラスの宣言がStoryboard上でくっついているので「後からコーディングでViewとControllerを紐付ける」という操作が出来ない様子。

実際、プログラム上でself.storyboard instantiateViewControllerWithIdentifierを使っても返ってくるのはControllerなのでviewだけ引っこ抜く事が出来ません。（ここでのselfはカスタムVewController）
で、一旦tempControllerという変数に入れて、self.view = tempController.viewとか無理矢理やってみたけど、だめだった。

色々さまよった結果、どうやらStoryboardを使いながらカスタムViewControllerを使うなら、Storyboard上で各画面（シーン）にカスタムViewController紐づける必要がある、というやり方しか見つけられなかった。それではUIデザイン担当がカスタムViewControllerのクラス名を知ってもらう必要が出てくるので、もう少しUIデザイン側がプログラムを知らなくても良いようにしたいなと。

で、Storyboard以前の仕組みであるNibファイルを使うやり方だと、Nibファイル側では具体的なControllerクラスの名前を知らなくても、Controllerクラス側でNibファイルと自身のviewを紐づける事ができるので、デザイン担当はviewやcellなどのパーツを作り上げ、プログラマ側はController内で必要なviewを取り込み、それぞれのパーツのイベントハンドラーもviewDidLoadあたりのプログラム上で登録すればよい様子。

ちなみに、Nibのfile's ownerはUIViewControllerにしないと動かない、と思っていたら、カスタムViewControllerの中でloadViewメソッドをオーバーライドして、その中でloadNibNameを使えばできるみたい。
最初はinitWithNibNameのなかでself setViewをしていたのだが、それではviewDidLoadが呼ばれないので、こちらにしてみた。

以下、抜粋
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
    //このメソッドはいじらない
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {

    }
    return self;
}

//これオーバーライド
- (void)loadView{
    UIView *tempview = [[[NSBundle mainBundle] loadNibNamed:@"First" owner:self options:nil]objectAtIndex:0];
    [self setView:tempview];
}

- (void)viewDidLoad
{
    [super viewDidLoad];

    //ここは普通に必要な紐付け。IBでoutlet使う代わり。
    textField = (UITextField *)[self.view viewWithTag:1];
    button = (UIButton *)[self.view viewWithTag:2];
    buttonNext = (UIButton *)[self.view viewWithTag:3];

    //ここは必要なアクションを紐付け。パーツによってはdelegate使う。と思う。
    [button addTarget:self action:@selector(clickButton:) forControlEvents:UIControlEventTouchUpInside];
    [buttonNext addTarget:self action:@selector(clickButtonNext:) forControlEvents:UIControlEventTouchUpInside];
    
}

//以下略

この辺むずかしいなー


コメント

コメントを投稿

このブログの人気の投稿

COCOMO（工数と工期）

COCOMO自体はプログラムステップから工数を出す見積もり手法だが、COCOMOには工数から工期を算出する計算式があるので、そいつについて。 式は 工期（月）＝α×（工数（人月）の３乗根） だそうな。 なお、このの工数と工期はプロジェクト全体（要件定義からシステムテストまで）が入るので注意。 この式のαについては「日本情報システムユーザ協会（JUAS）」が収集・計測したところ、「2.7」が妥当らしい。 本来、αの部分は「プロジェクトのメンバの能力による適当な係数」と「正規分布を想定した時間経過ごとの要員割り当て」をもとに割り出という手順になっている。 （要員割り当てはαだけではなく式全体に影響がある、と思う） とはいえ、JUASでは実際のプロジェクトをいくつも収集したというのだから、「2.7」は日本のプロジェクトには使ってもよいと思う。 αを2.7としたときの各人月に対する工期は以下のとおり。 1人月　2.7ヶ月 2人月　約3.4ヵ月 5人月　約4.6ヶ月 10人月　約5.8ヶ月 20人月　約7.3ヶ月 50人月　約9.9ヶ月 100人月　約12.5ヶ月 うーむ、工程が要件定義からシステムテストまで入ってると・・・。 10人月以下あたりはちょっと長い印象。 20人月以上になるとこれくらいで適当かなぁという印象。 思うに10人月以下の場合は一人が担当する範囲が広い（プログラム設計者が実装もして、単体テストもして、結合テストもしてetc）な場合が多い、というか実際自分のところではそうなので、感覚と違うのだと思われる。 要員が少なければ各工程ごとの要員割り当てが正規分布どころか、一直線になるんだからこの式に当てはめるて違和感がでるのは、納得感あり。 うーん、大きな工数になることがない限り使う機会が少ない、かな？ ■参考 ThinkIT 日本情報システムユーザ協会
続きを読む

rails3でHABTMが非推奨になってる

rails3でhas_and_belongs_to_manyを使ったActiveRecordを作ったらワーニングが出た。 DEPRECATION WARNING: Having additional attributes on the join table of a has_and_belongs_to_many association is deprecated and will be removed in Rails 3.1. Please use a has_many :through association instead.  rails3.1で消されちゃうよ、だと？ うーん、そんな運命なのであれば使うのはやめよう。 で、対応としてはhas_many :throughを使えと。。。 ということで、こんなイメージの、 Hoges←(HABTM)→Moges HABTMでつないでいた多対多の関係であった２つのmodelをhas_many+throughにしてみる。 変更前 class Hoges < ActiveRecord::Base  has_and_belongs_to_many :moges  end class Moges < ActiveRecord::Base has_and_belongs_to_many :hoges end 変更後 class Hoges < ActiveRecord::Base has_many :hoges_moges has_many :moges, :through => :hoges_moges end class Moges < ActiveRecord::Base has_many :hoges_moges has_many :hoges, :through => :hoges_moges end has_and_belongs_to_manyを使うと自動的に中間テーブル？名を作ってSQLに組み込んでくれるって本に書いてあるけど、has_many使うと自動じゃなくなるのですか。そうですか。 自動じゃなくなるので、中間テーブルのmodelが必要になりました。HABTMでは存在しなかった中間テーブルのmode...
続きを読む

ユースケースポイント法（UCP法）

見積もりにおける手法の１つ。 有名なFP法はデータ項目数（DBのテーブルやファイルの項目数）と入出力の数を手がかりにシステムの規模を見積もるが、UCPはUMLでいうクラス図を元に規模を見積もる方法。 分析クラス図までを作れれば、UCP法で見積もりしやすいだろう。 分析クラス図をベースにしたポイントを「未補正UCP」とし、さらに技術的な複雑度、環境的な複雑度をもとにした係数をかけることで「補正後UCP」ができあがる。 あとはFP法と同じように「１ポイントは何時間（または人月）かければ消化できるか」＝生産性係数をかけることで工数の見積もりにすることができる。 UMLを主に開発するプロジェクトでは非常に重宝されそうなこの手法だが、問題点を感じないわけではない。 この手法で感じる問題点は、FPと同じように「生産性係数をいくつにするんじゃい？」という点なのだが、UCP法を考えたGeri Schneiderさんによると普通のプロジェクトならば生産性係数は２０時間らしい。 （つまり１UCPの機能あるいはシステムであれば２０時間で作れるであろう、と。） しかしながらこのUCP法はまだ日が浅いためか、Geriさんの考えるプロジェクトが私の周りと一致しずらいのか、２０時間で本当に大丈夫か？という不安がいつもある・・・。 （事実、２０時間で工数に変換すると「大丈夫かなぁ・・・」という工数が出てくる） また、技術要因はさることながら、環境要因が曲者と思う。 なぜならば、環境要因は「採用するプロセスの習熟度」「モチベーションの有無」「プログラミング言語の難しさ」などなど、非機能要件的な要素を先に係数として含めてしまう仕組みになっており、これをどう扱うかが実際に使おうとすると非常に悩ましい。 とはいえ、個人的に分析クラス図は頭のなかで思い浮かびやすいUMLであり、これからもお世話になるはずなので、まずはUCP法の生産性係数はいくつが望ましいのか、周りからデータ収集を地道にがんばるしかないか。 ■参考 ■オブジェクト倶楽部 http://www.objectclub.jp/ ■ITpro http://itpro.nikkeibp.co.jp/article/COLUMN/20060811/245759/
続きを読む