2015-01-24

[Swift] StoryBoardを使わずにViewのOpen/Closeを行う

githubはここ
https://github.com/longicorn/Not_Use_StoryBoard_View_OpenClose_Swift

Swift Docsを見つつという感じですが、今回はタブを作らず単独Viewからの画面遷移を行っています。

Viewを開く側はこれだけです。
openではなく、presentViewControllerなんですね。
TitaniumだとViewをopen/closeを行うのですが、こちらはあくまでも画面遷移なんですね。

        //ViewController
        let childViewController: UIViewController = ChildViewController()
        self.presentViewController(childViewController, animated: false, completion: nil)
nil)

        //ChildViewController
        self.dismissViewControllerAnimated(false, completion: nil)

修正:2015-02-02
閉じるときはdismissViewControllerAnimatedが正しいので修正しました

2015-01-24

Android 5.0.2 in NEXUS 2013

今日起きてAndroidを触ったら5.0.2が来ていたので速攻でアップデートしたのでメモ。

NEXUS 2013は初期状態でAndroid 4.3でした。
これは結構サクサク動いてストレスもなかったのですが、ここから4.4にアプデしたのが運の尽き。
アプリの切り替え時にフリーズ、再起動をするようになりこの現象が5.0.1まで続いていました。
ただどうも自分の環境だとPC(OSは関係なし?)にUSB接続するとどうもこの現象が出ないようで、実質PCがある環境のみですが使えるので我慢出来ています。

ところが、5.0.2にアップデートしてまだ少しですが現状問題なく、サクサク動いています。
ただ、ググると5.0.2は致命的に遅いという報告もありよくわかりませんが。

追記:再起動現象が発生しました。
ただ、軽いのは事実です。再起動はハードが壊れているとかの問題かもですね

http://juggly.cn/archives/136609.html
ここによると、怪しいのはGCかfstrim。
ただ、4.4の時はGCは変わっていなかったし、よくわからないですね。
そもそもPCにUSB接続をすると問題が出なくなり、単なる充電でUSB接続だと発生するのもよくわからない。
土日に少し使ってみて問題出なかったら嬉しいなぁ。

2015-01-17

[Swift] StoryBoardを使わずにタブを作る

Xcode、StoryBoardがいまいち自分に合わず、なんとかStoryBoardを使わずにプログラムが作れ始めてきたのでメモです。
パーツのちょっとした使い方ならば、Swift Docs で良いのですがもっと実際に作るとなると分からない事だ
らけです。

githubに小さいサンプルを置いていきます。幾つか詰まるところで切り出せたらまたgithubに作っていこう。
https://github.com/longicorn/Not_Use_StoryBoard_Tab_Swift

スクリーンショット

出戻りのためにgitを使おう

StoryBoardを使う使わないに限らずにどうもGUIを使う環境だと裏で色々操作をするので、少し操作して動けばgitで保存を行ったほうが良さそうです。
これをしないとすぐに開発に行き詰まります。StoryBoardを使うと特に色々おかしくなるので。
自分みたいに古いタイプの開発者にはGUIには慣れないです。

Tabで表示するView

基本的にViewはこの形を元にして、色々なパーツをコードで書いて追加していく事になるようです。
カスタマイズしづらいので、UITableViewControllerは使わずにUITableViewを使う方向が良さそうです。
https://github.com/longicorn/Not_Use_StoryBoard_Tab_Swift/blob/master/Not_Use_StoryBoard_Tab_Swift/FirstViewController.swift

import Foundation
import UIKit

class FirstViewController:UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
    }
}

Tab

Tabは特にカスタマイズもないので、UITabBarControllerを使用しても問題ないようですね。
https://github.com/longicorn/Not_Use_StoryBoard_Tab_Swift/blob/master/Not_Use_StoryBoard_Tab_Swift/TabBarController.swift

Titaniumでもタブを作ってから、タブにViewをセットするという流れですし、コードは違いますが流れはかなり似ていてすんなり理解出来ました。

Tabを開く

AppDelegateが実質Cのmain関数のような最初に呼ばれる部分のようで、ここでTabを作成してやれば良いようです。
https://github.com/longicorn/Not_Use_StoryBoard_Tab_Swift/blob/master/Not_Use_StoryBoard_Tab_Swift/AppDelegate.swift

特に難しくは感じませんが、どういったクラスやメソッドがあるのかがさっぱり分からないのが一番しんどいです。
Titaniumだと英語ですが本家を見れば分かりやすく見れたのですが、swiftはどうすべきなんでしょうか。

2015-01-08

Yosemiteでトラックパッドを認識しない

新年早々の記事でなんだけど、トラブルメモです。

会社ではスペースの問題などでMac Book Pro + 外部モニタ + トラックパッド(自前)で作業をしています。
新年明けてちょうど良いのでYosemiteに上げたのですが、トラックパッドが急に認識しなくなりました。

トラックパッドの説明書を見ると電池確認しろといっているが、LEDは問題なし。
Bluetoothで一旦認識されているトラックパッドを削除して、検出しても反応しない。
再起動してから、検出を何回しても反応なし。

結局、Bluetoothをoff->onにするとすっと認識しました。
年末年始は自宅で新調したMacを触っていましたが、Yosemiteの細かい問題はありますが、なんか海外で問題になっている記事ほどではないなぁと思っていたら罠があった。
YosemiteでiOS開発サポートが上がっているのでYosemiteに上げましたが、そうでない人はもう少しアップデート来るまで待ったほうが良いかもしれない。

2014-12-31

今年の振り返り

今年の振り返りもしておこう
今年は去年末から予想はしていたけど9月頃まではデスマーチで久しぶりに死ぬかと思った。休みがほとんど無いし。
その後もなんだかんだと忙しく精神的にも体力的にも回復はしてないし、給料は安いし、色々しんどい。
ただTitaniumを触りまくったので言語的にはJS使えるようになったし、ネイティブも少し触りつつもiPhoneアプリのリリースとかも分かったし、面白い部分も一応はあったのが収穫か。

ということで、プライベートでの開発はほぼ無理だったので、来年こそはプライベート開発を頑張る。

2014-12-31

vimの管理pluginをpathogenからNeoBundleに変えた

年末で時間がやっと取れたので前から気になっていたvim環境を作りなおした。

気になっていたのは、このあたり

pathogenなのでいい加減に古い
会社Macだと補完系で特に異常に重い
最近かったMacでvimが落ちたのが決定的

ということでこのあたりを見つつ、ついでに整理してみた
http://qiita.com/muran001/items/3080c4816b7c2e65e40b
http://cpplover.blogspot.jp/2013/12/neobundlevim.html

補完系プラグインはneocomplcache
Tabプラグインで長年使っているminibufexpl
Uniteはさすがに必須。
あとは細かいのをいくつか。

ともかく、あまり色々追加はしてなくて、むしろ削除の方向へ。
YankRingとか色々有名ドコロも一時は入れていたけど結局使わないし。
結局シンプルが一番だよね。

2014-12-01

Titanium mobileを1年ほど触ってきた感想

さて、仕事の関係でここ1年ほどTitanium mobileを触ってきました。
すでにリリースもされて何回かのアップデートもしています。
アプリの内容はどうでもいいので、ここではおいておきます。それにこのBlogはあくまでもプライベートだし。

Titaniumを選択した理由

時期的な理由と社内の状況で。
iOSとAndroidを視野に入れて、なおかつ開発者が自分ひとりで無茶な開発内容なので、仕方なくといったところ。
別にTitanium自体に思うところはないけど、そんなところ。

ちなみに最近はTitanium moduleの関係や他プロジェクトとかの関係もあって、Objective-CとSwiftはすでに触っています。

感想

ぱっと感想を。
Androidの実機テスト大変とか開発環境に関係なく共通の話はしませんのであしからず。

良いなあと感じた部分

簡単なツール系アプリを作るのであれば、さほど文句はないです。

Objective-C、Swift、Java何を選んでもネイティブ開発に比べたらやっぱり楽。
JavaScriptなのでライブラリも多いし、いざとなればmduleを作ればネイティブ言語も使える。
iOS、Androidも1つのコードで対応できるし、Alloyを使えばMVC2で開発できてデザイナも入りやすい。

デザイナが入りやすいのは今回非常に助かりました。
別プロジェクトでSwiftも触っているのですが、Titaniumと両方を触った感想を聞くとSwiftではまだ自由にデザインが出来ないらしい。
Alloyだと色々制限もあるしWebとも感覚が違う部分はあるけど、まだTitaniumの方がなんとかなるとのこと。
デザインは自分にはさっぱりわかりませんが...

あとはテストが楽。
組み込み時代にも思っていたけど、こういうアプリとかだとテストが本当に辛いのです。
でもTiShadowを使うと実機を使ったテストコードも書けます。
ちなみに、最近はappiumとかもあるのですが基本E2E。自前で作ったライブラリのユニットテストコードまで考えるとまだまだネイティブだと無理な気がします。
最近やっとJenkinsさん環境も作り始めていて一応CIも回せるようになってきました。CI大事だよね。

本家ドキュメントが豊富。
これ見ておけば大体なんとかなります。英語だけどね

結構気になる部分

そんな感じで、はじめは良いことばかりと思っていたけど、ある程度の規模になると結構めんどくさいことも多々出て来ました。

まず、ネイティブではないのでしかたないけどやっぱり処理が重い。まあ将来的にJSコンパイラが入るらしいけどね。
あとJSとは言え下側はネイティブ言語が絡むので下手なことをするとメモリリークが発生する。
はじめはJSだからここまで重いのかと勘違いしていたくらい。これ結局メモリを意識できな人が触ると怖い気がする。

次にmodule。moduleを作れるのは良いけど、言語が複数使うことになるのでそれって微妙。
moduleまで意識すると、Titaniumを使いこなせる人ってどこまでいるんだろうか。
あと、Swiftが出たのにmoduleはObjective-Cでテンプレートが作成されるのもちょっとつらい。
頑張ればSwiftに直せそうな気もするけど暇がないのでやってません。できるんですかね?
さらにmodulのビルドにPython(しかも2.7系)が必要って辛い。

この時点でツール含めるとJS、Objective-C、Python、Alloy + XML + TSS(CSSっぽいの) or Alloy + Jade(xmlの代わり) + TSS + CoffeeScript(JSの代わり)ぐらいは使いそう。
これは結構ダルいです。自分はまだなんとかなってますが、言語経験が少ない人には辛いかと。
触ったことないけど今ならRubyMotionのほうが良い気がする。こっちだとコンパイルするし、Rubyだし。

SDKのバージョンアップが結構つらい。
何が辛いかというとWebAPIを使ってサーバとやりとりするタイプの場合のテストが辛い。
単純に開発するだけなら別に気にしなくても良いんだけど、過去のバージョンのままでアップデートしない人がいるのでWebAPIとの関係でテストが非常にしんどい。
これはマジでしんどいです。

さらには日本人エンジニアが苦手な英語。ドキュメントとかエラーを調べるくらいなのでなんとかなるのですが、英語ドキュメントが一番多い。
なれないとこれは結構辛い。ただ最近は日本語のblogとかも出て来ているので意外と何とかなってますが。

将来的に怖いのは、Titaniumをやめてネイティブに移行するばあい。
Titaniumの動作を再現させる必要があるので、開発が大変そう。これをやったアプリはいくつかあるらしいですが、これを言われたらまた地獄の日々なんだろうなぁ。

これから初めて開発する場合の選択肢

開発対象にiOS、Androidが入っている場合はどうしたものでしょうね。

開発するアプリにもよりますが、個人開発者ならありだとは思います。

ただ企業ならよく検討したほうが良いかと。
RubyMotionとかも含めてこういうツールの良い所は、同じ処理を異なる言語を使って複数書かなくても良い部分。
でも、どちらかを外注に出すという方法もありますし、よく考えたほうが良いですね。

ただどちらにせよしんどいのは確か。外注を使えば管理能力が結構必要。自前でネイティブを選べばAndroidのめんどくさい部分も含めて頑張る必要がある。
Titaniumなら限界がどうしても出てきて、カオスになりそう。
もう少し良い開発環境が出てこないかなぁ