稍微去了一下日月潭

員工旅遊,跟同事去住日月潭玩,住雲品,大膽猜測是因為訂不到涵碧樓的關係。
雲品跟涵碧樓一樣貴,要不是有旅遊補助我才不會去呢!

全部的照片

與紙箱王的賈伯斯合照


從飯店看出去的樣子 

 晚餐的buffet吃到飽,真的很好吃





從飯店check out以後去開電動汽車,越做越好了,爬坡的時候也很有力,完全感覺不出來是電動的。


不過這種事還是玩玩就好,繞日月潭一圈大概一小時,我還有走下來逛逛,大概開了一個半小時,簡直就是去日月潭練車的嘛。

Google 行動開發高峰論壇 2013 &Android Taipei 9月份聚會

上個禮拜接連去了這兩場活動,一些紀錄如下。剛好辦在同一天,請了天特休,整天在外面跑來跑去,其實有點累,影片上傳兩次才成功。

雖然我是寫iOS的,但是Android也是mobile的一份子,許多設計理念都是相通的,一天聽下來,聽了許多Android有但是iOS沒有的東西(像是upstream 的notification);相對的,在這次WWDC iOS7更新裡面也有很多功能是iOS有而Android沒有的。(這可以舉的可多了)

以下摘自當天寫的note

不管寫iOS還是Android 大家都是用MAC喔 >.@

此風不可長


overview
jelly + ICS = 63%
現在支援 alpah + beta test,還可以設定要 adoption多少percent user

google play service,其實就是個APK
第一個功能:google map API v2

location APIs
geofencing:設一個geo 的fence,離開時吐notification給app
activity regnition:看是在開車走路還是腳踏車(絕對不是只有判斷速度這麼膚淺的招式)

notification,new upstream notification,手機回傳給server

支援game的cloud save

clip時觸發區域可以不用是方形的了

Android 4.3
BLE low energy api support
multiple user 使用者權限管理
OpenGL ES 3.0
media enhance(自己看spec)
UI automation test


Android UI design pattern
reference:
1.google.com/io
2.Android design in action

簡單介紹一些design pattern
新招:action bar
還不會用的快去學

navigation可用這些
  • spinner
  • fixed tabs
  • scrollable tabs
  • navigation drawer (啊不就是隱藏側邊欄)

navigation drawer 打開來的時候action bar 不應該有任何移動

developer.android.com/design/patterns

密 unofficial design patterns
1.fading action bar
scroller 的時候action bar 變透明
ex google music

2.swipe to refresh
ex:gmail

3.action drawer
右邊跳出來

4.cards

responsive design :Android的痛

if use "android:layout make-present"
phone->pad ,app會跑版,多出很多空白
請作一個layout給平板
要用fragment!!!

起碼要有3套layout:手機,7" 10"
android studio有一些default template
ex:Master/detail flow

SlidingPanelLayout: open source ,download gogogo

新作的 Holo scheme,OEM不可以改動

settings flow menu

Your branding + Holo = Your app
Holo scheme 會不會影響branding的樣子
  • information design:畫面上的design
  • interaction design
  • visual design: 品牌設計 UI設計
在interaction design的時候要作大部分android都習慣的方式
ex :back button要有用,所有非遊戲app應該都要有action bar

visual design的時後可以作自己的特色or 跟Holo一致

Example:
  • good: 在phone和pad都做optization
  • fence
  • expedia 
  • what's app 原本沒有follow design guideline,follow之後download數增加了
  • TED

How to get "not" featured

kyunghwan Min (Korean)

great store listening,include 
1.information icon
2.titles
3.screen shots:No device image
4.description
5.feature graphics:No device image again!

#1 worst Newspaper app
1.No feature graphic
2.Icon round corner above 15% 長得很像apple store上面的app
please no more than 5%

3.use apple's share button in android app
4.label back button
please hardware back button
5.when click back button:ask "do you want to exit?"
when there is no back view,after click back button ,just go to home screen directly

another example:
1.a functionless action overflow key
2.non-android products in description
寫了一堆在App Store得獎的description,寫說可以跟iphone sync

3.most coommom mistake
用了iphone或ipad in feature graphics

Google Play Publishing Best Practices:

會遇到的各種問題(跟寫程式無關的)

resources:
1.android development support help center(最近要改版了)
2.Merchant payment support Help Center
3.Technical&API level support 
有教學影片,討論區
4.play user support help center

developer console,是developer應該不陌生
chat support channel
real time human service,晚上code不會寫可以打這個,當作練英文也可以

有讀過 content policy請舉手:只有5%
違反時會怎樣,知道的請舉手:幾乎沒有!!(啊不就是下架停權)

每天有?個submission(包括new app和update)

我們不像a公司要審很久,Android一下就過了喔!(a = apple)

有看過app policy help resources請舉手(只有一位)

Most common type of violation
1.keywords Spam
2.IP,用別人的branding Ex:google ++、g00gle search
3.sexual contents
4.AD:把自己偽裝成system alert、part of application 
5.引誘user rate app and reward user

payment一定要用google wallent
不可以偷偷蒐集user data
不可以導到非google play的store下載apk

Google cloud platform




GCM,Google play Services & Location APIs 

不管是寫iOS還是Android,只要是寫mobile的都應該看一下這篇



===
晚上去這個月的Android Taipei
一個Android app都沒寫過,我是衝著柏齊去的,順便參觀一下EZtable,不虧是近幾年衝很快的startup,從工作環境就可以感覺到他們的企圖心。


我好像把他拍得有點淫蕩

標語蠻震撼的,要看每個人是怎麼定義coding時間的。
我扣掉開會回email想架構還有看別人code的時間以後,自己coding應該是不到五小時啦


 很團結的cardinal blue,穿一樣的衣服一起出來就很有氣勢
上面的「野心」也不錯,如果是大陸公司的話也許會貼「狼性」

柏齊在前面分享Android自動化測試

雖然我是在活動前兩小時才報名的,也有我的名牌,實在是有點感動。
這也給接下來要辦的公司一點小壓力,出場地出食物竟然還有名牌!

我在接案公司的日子



在cocoaheads Tapiei 七月份分享的投影片,趁這幾天中秋連假,把一些小地方修一修。當然有些隱晦的字句都把他拿掉了。

這篇大概是在五月初的時候就差不多做好了,差不多半年過去了。
好久,剛剛我還以為這篇是我上輩子寫的。

我一直都有作紀錄、寫日記的習慣,一開始我只是想把在前一家公司接案時期學到的遇到的整理一下,不知不覺就這麼多了,不管哪家公司都一樣,一陣子過去了一定會大轉變,可能是轉型、可能是擴張、可能是被併購、也可能是跟別人合作。不管怎樣,半年已經是個夠長的時間,長到什麼事都有可能發生,我也不再是個小屁孩了(雖然心態上還是)。


開發者應該如何面對iOS 7?

標題用問號結束,是因為幾乎每天都聽到有不同的解法。下面來作個整理,比較一下看到現在apple官方、開發商、開發者對於iOS7出現做的各種應對。



apple對於iOS 7的說明,在iphone 5 的64bit架構出來後又更新了一次,不管是開發者還是UI/UX/UED,都可以找到需要看的文件

對於一個開發者基本要看的是 Xcode 5 release noteiOS 7 diff,雖然我看完了,但很多地方看不懂,還在重看當中。

根據三個月前的iOS 7 beta1,首先看到的是UI大改,所以首先需要解決的問題是客製化UI在iOS 7上面會亂掉的問題,只要是Xcode 4 build出來在iOS 6上面跑得好好的UI,基本上在iOS7上面都不會有什麼問題,大部分的app可以用這招先檔一陣子。但是同一份code在Xcode 5上面build出來以後,看到的大多是慘不忍睹,像是navigation歪掉,tableView Cell改變。我的建議是,先用Xcode4 把iOS7上面有問題的地方修好,出個iOS7的版本,先稱一陣,這段時間趕快用Xcode 5 把有問題的地方都修一修。這樣是為了怕未來上傳 app的時候需要支援120x120的icon,但是120x120的icon一定要Xcode5才能加,等到我們所有上架的app都必須用Xcode5以上才能上架,到時候再解已經來不及了。

在同一個app內針對iOS 7有什麼問題的地方作微幅修正,這是最簡單的作法,也是最省錢的作法,相信大部分台廠老闆都會選擇這招!比較有心的團隊會在iOS 7還在beta版的時候就開始修改,我待的團隊在iOS 7 beta 5的時候開始投入,解了10多個UI上的問題,全部都是客製化UI才跑來的問題XD。接案公司或者app製造機,一定都是等客戶靠北以後才會改。

我在上個月一篇放棄iOS6 直攻iOS7? 裡寫說我看到的其他人作法,有很多是盡早使用扁平化設計,這樣等轉換到iOS 7時,使用者在使用app跟離開app後看到的是一致性的設計語言,這也提高了app在手機內的存活率。先在iOS 6的app裡面作防範,這並沒有解決app在iOS 7會跑版的問題,所以、大概有這幾種選擇!

incredible solution for support iOS 567

  • 我們最先遇到的問題就是view的原點從status bar下面變成最左上角了,根據這篇使用 Interface Builder 設計 iOS7 Layout 並與 iOS6/iOS5 相容,我們看出來可以用autolayout來輕鬆解決原點跑掉的問題,但是仔細看看這篇文章就會發現只是作一個簡單的View就這麼麻煩了,像是大變動的tableView跟datePicker要怎麼辦!
  • 所以我比較喜歡這種,作兩隻app,然後順便加新功能!當然舊app也要正常運作,iOS 5 6作一支,iOS6 7以上用另外一支,最著名的例子當然就是Reeder 2,我猜他們在iOS 7 beta 之前就已經投入開發了,看到iOS7以後毅然捨棄support iOS 5。不過這招會牽扯到商業策略的問題,不是開發者可以單獨決定的,除非原本的app在iOS 7上面bug實在是多到爆炸,否則正常公司是不會使用的。

來自官方的幫助

apple不是笨蛋,也知道開發者都很懶惰,不可能使用者18號升級,開發者就馬上提交新版本,所以幫了兩個忙。

一是可以下載舊版app以往當我們的裝置是iOS 5但是app最低支援版本是iOS 6的時候,點 了下載 AppStore會說不可以下載。現在只要app之前有支援iOS 5的版本,就會讓你下載該app支援iOS 5的最後一個版本。相關文章可以看這裡這裡

圖來自pcmag

第二是加速app審核速度,這兩天在討論版裡面,都可以看到很多開發者朋友體驗到尊爵不凡的review速度,兩天一天甚至15小時一小時通過review的都有




說好的coding conventions

一人開發團隊是不用訂什麼coding style的,但是當程式越寫越大,越大越複雜的時候,一致性的語法就很重要了。

最近這幾個月都在做project的merge,原本維護的案子是一個與世隔絕的專案,現在要用其他專案當作base,使用同一批檔案來搭建出一樣的app。簡單來說就是大量的refactor,能用繼承的地方就用繼承,如果某些功能A專案裡要有B專案理沒有,那就用override的方式。兩邊一樣名字的function作不一樣的事。參考了base project的coding conventions來改寫,三個月過去了,只完成了UI部分,data model還有很多地方沒有完成。

這幾個月的經驗,我才搞懂很多之前自以為是的觀念,像是繼承、self、delegate、block、catagory、run time debug,這些零零碎碎的東西。也再一次體驗到好的design pattern讓你上天堂,不好的struct讓你想殺人。關於怎麼把程式寫得像是語言這點很多書裡都有講,我這裡想表達的是coding conventions。

列幾篇關於coding conventions&coding style的文章:

Coding Guidelines for Cocoa
官方的不看可以摔鍵盤了

Google Objective-C Style Guide
google也來參一腳,跟apple的很像

NYTimes Objective-C 編程風格指南
NYTime團隊自己的定義,很多細節

几点 iOS 开发技巧
這不是coding commention,而是refactor module架構時要注意的事,看完這篇有種「對、我就是這樣做的」感動!