Page 4 of 11

Previous page

iOS UIViewController lifecycle

UIViewController のライフサイクルについて

http://blog.77jp.net/iphone%E9%96%8B%E7%99%BA-uiviewcontroller-%E3%83%A9%E3%82%A4%E3%83%95%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB-viewdidload-viewwillappear-viewdidappear-viewwilldisappear-viewdiddisappear-ios-%E9%80%86 http://blog.livedoor.jp/sasata299/archives/52029262.html

アプリがバックグラウンドへ移動した場合や、他のアプリ、 他の機能にて当Viewがメモリから削除された場合は、再度 viewDidLoad が実行されます。

init(インスタンス作成時に呼び出したイニシャライザ)   ↓ viewDidLoad  ・View が初めて呼び出される時に1回だけ呼ばれます。  ・アプリ起動後に初めて当Viewが表示された場合に1度だけ呼ばれます。   ↓ viewWillAppear  ・View が表示される直前に呼ばれるメソッド  ・タブ等の切り替え等により、画面に表示されるたびに呼び出されます。  ・タブが切り替わるたびに何度でも呼ばれます。   ↓ viewDidAppear  ・View の表示が完了後に呼び出されるメッソド  ・タブ等の切り替え等により、画面に表示されるたびに呼び出されます。  ・タブが切り替わるたびに何度でも呼ばれます。   ↓ viewWillDisappear  ・View が他のView (画面から消える) 直前に呼び出されるメッソド  ・View が他のView (画面から消える) 直前に呼び出されるメッソド  ・タブが切り替わるたびに何度でも呼ばれます。   ↓ viewDidDisappear  ・View が他のView (画面から消えた) 非表示後に呼び出されるメッソド  ・View が他のView (画面から消える) 直前に呼び出されるメッソド  ・タブが切り替わるたびに何度でも呼ばれます。


起動したとき

  • ViewController viewDidLoad
  • ViewController viewWillAppear
  • ViewController viewDidAppear

Nextボタンをタップして遷移したとき

  • NextViewController viewDidLoad
  • ViewController viewWillDisappear
  • NextViewController viewWillAppear
  • ViewController viewDidDisappear
  • NextViewController viewDidAppear

戻ったとき

  • NextViewController viewWillDisappear
  • ViewController viewWillAppear
  • NextViewController viewDidDisappear
  • ViewController viewDidAppear

Published at June 09, 2014.

Android app

ひっさびさに Android した。普段慣れ親しまないので、やるたびに記憶が無くて本当に厳しい。 今日は Android Studio を使ってみた。特に理由はない。使ってみたかったから。

UI を適当にあれして。テキストとかボタン貼っつけて、 textsize とかと同じ並びで、onClick とか書けるのって、結構初心者にもとっつきやすいよなあとか 考えながら、とりあえず適当に何か見つけたサンプルでカウンタみたいなやつを作ってみた。

https://github.com/284km/Counter

Android なー。まあまあ作っていて楽しい。でも深く踏み入っていくと辛い世界なのかなあ。 評判きく限りではそんな感じみたいだけれど。 まあ、自分が作っていて楽しいうちは別に全然よいと思うので、 もう少しまともな Android 力くらい身につけたいものです。


Published at June 02, 2014.


TOEIC

2014/05/23 12:18:28

TOEIC に関しておすすめの勉強法について書いてみる。

  • まず1回受ける。ことをおすすめする。

  • そして、勉強を始める。 順番は厳密に定めないが、早い内に TOEIC について知っておくのがよいと思う。 いわゆる TOEIC 対策的なやつ。問題の解き方とか、傾向と勉強法みたいなやつを。

  • 文法は大丈夫か? 中学英語の文法までで、基本的には十分だと思う。 分からない場合には問題見ても何が書かれているか理解できないと思うので運試しにしかならないだろう。 ということで中学英語程度の文法は必須と思う。

  • 単語 これはかなり重要で、中学英語までだと全然足りない。 よくある売れてる単語の本とか1冊あっていいと思う。熟練者でなければ。 模試しながら知らない単語だらけだと、都度調べるのも時間がかなりかかるので、 単語全然わからんなーという感じであったら、単語帳とにらめっこの期間を設ける方が効率良さそう。

  • ここまでがあると戦うための道具がそろっているのではないか。 あとは公式問題集みたいなやつで模試してみるとよいと思う。 自分がどれくらいか。とか、何が駄目だとかが不正解によってはっきり分かる。 まずは、間違えた問題について何故間違えたか、何が正しかったか。みたいなところを はっきりさせていく作業をこなすことになるだろう。 その中で少しづつ身につくものがあることを、実感できるだろうし繰り返すことにより 点数にあらわれてくるはずだ。

つづきはまた書く。


Published at May 23, 2014.

Bestpractice Javascript

  • 2014/05/22 16:55:30

今断言できるとかいうあれじゃない。bestpractice というカテゴリを作って、 今後継続して育てていこうという考えがずっと前からあった。 と言ってもなかなかよし書こうというタイミングが来なくてずっとそのままになっていた。 そんなものなのかもしれない。

javascript についてはちょっとここらへんで一旦まとめるのも良いかもしれないと思って書いてみる。 クライアントサイドのフレームワークのはなしだ。

今使っているのは Backbone.js

対抗馬として Angular.js がいる。 しかし難しそうというイメージで (少しだけ見たけれどまともには使っていない)、 あと、よく言われている行儀が悪いというのは自分も同意見。

そういったあたりを踏まえて、現状は Backbone という選択をしている。

とはいえ、必要とするのは主にバインディング。 モデルを変更すればビューが自動的に反映されれば基本的にはOK. 大規模なものを作る機会はそうそうないから。現時点においては。 そうすると、Angular というのはよい選択でもある。 それでもやはり今 Angular にいかない理由として自分の js 力というのもあるかな。 js 力がもう少し高まるまでは、なるべく行儀の良い方法に沿っておくべきな気がしている。 そういう理由もある。

そのほか、Vue.js に着目している。mizchi さんが最近 Vue.js に足りない部分を補っていて 行く末にかなり着目している。筋のよい js 使いによる、筋の良い実装みたいなところの行く先 はどんななのか。という感じ。

とりあえず今の時点ではここまで書いておくことにする。また追記をする予定。


Published at May 22, 2014.

English 20130521

今日は昨日に引き続きスキルポイントを英語に振った。 ゆっくり読めば大体分かる。早く読むことが出来ない。耳に関しては明らかに悪い。しゃべることは置いといてる。 日本語で同等の文章であればさらっと数十秒で済むもの。そうだよ、新書とか大体30分程度でひととおり読むことができるわけだ日本語ならば。 それと同程度を目指したい。同程度はだいぶ難しそうなイメージだけれど、それくらい早く読めるようにしたい。たくさん読むしかないのかな基本的には。 まあ引き続き励みます。


Published at May 21, 2014.

Ruby Guarding with arrays

  • nil のときエラーになる

    params[:pictures].each do |picture| foobar end

  • ちょいださい

    (params[:pictures] || []).each do |picture| end

  • こういうのある

    Array(params[:pictures]).each do |picture| end

というメモ。


Published at May 16, 2014.

Delete branch on Github

github 上に間違ったブランチを push してしまって消したいとき。

local なら、 git branch -D branchname でいい。

github に push 済みのブランチについては

git push origin :branchname

とする。


Published at May 15, 2014.

Multi Account Omni Auth

記録として一応残すのだけれど、 結局 twitter oauth だと mail address が返らないため、そのまま devise の流儀にあてはめることはできなかったりで hack が必要。 だからこの記事は思い出す様に残す。あてにはしないこと。

追加する gem はこんな感じ。omniauth- 各種は使うものだけでいい。

gem 'devise'
gem 'omniauth'
gem 'omniauth-hatena'
gem 'omniauth-github'
gem 'omniauth-twitter'
gem 'figaro'

bundle install したら、

rails g install:figaro

すると config/application.yml が作られて .gitignore にも

# Ignore application configuration
/config/application.yml

が足される。config/application.yml にはこんな感じで書く。

TWITTER_CONSUMER_KEY: "xxx"
TWITTER_CONSUMER_SECRET: "yyy"
GITHUB_CONSUMER_KEY: "zzz"
GITHUB_CONSUMER_SECRET: "aaa"
  • config/initializers/omniauth.rb に設定を書く。

    Rails.application.config.middleware.use OmniAuth::Builder do # provider :hatena, # ENV['HATENA_CONSUMER_KEY'], # ENV['HATENA_CONSUMER_SECRET'], # { # scope: "write_public,read_public,write_private,read_private" # }

    provider :twitter,
    ENV['TWITTER_CONSUMER_KEY'],
    ENV['TWITTER_CONSUMER_SECRET']
    

    # provider :github, # ENV['GITHUB_CONSUMER_KEY'], # ENV['GITHUB_CONSUMER_SECRET'] end

  • Model を作る

    rails g devise:install rails g devise user rails g model auth uid:string provider:string name:string user:references

メールを使う場合はとりあえず config/environments/development.rb に以下を書いた。

config.action_mailer.default_url_options = { :host => 'localhost:3000' }

config/environments/production.rb はそれなりに。

# Email
config.action_mailer.delivery_method = :smtp
config.action_mailer.perform_deliveries = true
config.action_mailer.default_url_options = { :host => config.app_domain }
config.action_mailer.smtp_settings = {
  address: 'smtp.gmail.com', 
  port: '587',
  enable_starttls_auto: true,
  user_name: '',
  password: '',
  authentication => :plain,
  domain => 'somedomain.com'
}

app/model/user.rb をちょっと修正

class User < ActiveRecord::Base
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable
  has_many :auths
end
  • Controller

    rails g controller home index rails g controller auth create destroy


Published at May 14, 2014.

clearfix using compass

compass を触っていた。なんとなくしか知らなかった css, less, scss(sass) 辺りの違いから入って、compass の公式ページをひと通り見て、結局 rails で使ってしまうのが総合的に見て楽そう (asset pipline) だなあという感触だった。

そういうわけで、少しだけ css 界について知ることが出来た。

自分は sass, compass を選択した。

gem 'sass-rails'
gem 'compass-rails'

だ。ベースとなる sass ファイルの頭で

@import "compass/utilities"
@import "compass/css3"
@import "compass/reset"

している。compass の簡単な例として clearfix のものが以下。 たとえば

  • html

    #wrapper #main #side

  • sass

    #wrapper padding: 10px background: #aaa

    #main float: left width: 60% height: 200px background: #5ce

    #side float: right width: 36% height: 200px background: #5ce

これは wrapper の背景から main, side がはみ出している例。 commpass でこう include すると

#wrapper
  padding: 10px
  background: #aaa
  @include clearfix

こんな css になっている。

#wrapper
  padding: 10px
  background: #aaa
  overflow: hidden
  *zoom: 1

こういったものを良い感じに用意してくれている css フレームワークなのだった。 なるべくマシなデザインで、素早く開発する夢を見ている。小さく一歩前進した。

  • 2014/05/13 08:01:01

ちょっと追記。こう、下に footer みたいなのを置けると、margin-topプロパティを自動的に浮動化されたボックスの高さまで調整するような振る舞いをするらしく、問題は起こらない。ということとかも知ったのであった。

#wrapper
  #main
  #side
  .clear

.clear
  clear: both
  height: 60px
  background: #e58

Published at May 13, 2014.

Next page