Skip to main content

[App] 國道計程收費速算器 v1.1.1


視覺化快選國道里程費用計算。
跟上個壽司比起來,這個App真的幸福太多了...短短不到一週含上架就完成了,如果您操作上發現問題的話,請不吝於告知,我會儘快處理的,謝謝。

佛心評測:
* PunPop :【國道計程收費速算器】算好錢才不會弄錯錢。
* 硬式要學 :計程收費怎算?「國道計程收費速算器 」3 秒算給妳

Universal Version includes iOS and Android






◎ Introduction
查表查累了嗎?
視覺化快選國道里程(ETC)費用計算,自動連續選取設計,方便選取不同國道的相鄰路段。

選取方式為「同一條國道」為主,雖然不同國道沒有辦法一次選取,
但是可以自由設定其他起點!想要國道一直線還是走快速道路都隨您選擇!

您可以選擇點擊兩國道相接的交流道如「新竹系統」、「南港系統」等,程式自動會將兩國道連接起來,
又或者再次點擊「藍色起點方塊」取消起點後,自由選擇自己想要的位置重新設定起點串接計算就可以囉!

包含功能:
  1. 計程車、小型車、大型車與聯結車皆可輕鬆計算!
  2. 路徑完整清單,費用一目了然,包含 eTag 優惠顯示。
  3. 特定交流道南北出入口自動判定。
  4. 不同里程數的多重出入口選擇。
  5. 單向出入口鎖定南北不打結。
  6. 行車方向路段小於 1 公里收費排除。
  7. 當日來回計算,只要選擇「起點」 -> (中間路段) -> 「終點」後同樣的路徑點回 -> (中間路段) ->「起點」即可算出當日來回喔!
  8. 自由路徑選擇,再次點擊藍色方塊可取消起點設定,重新選擇需要分段的地點方塊,即可重新設定起點。
  9. 連假模式可提供連續假期計程費用試算。國三8折區段誤差結果已於 v1.1.1 版修正。
  10. 國道 2, 4, 8 ,10 對國1與國3相接交流道自動選擇,如三重到關西,預計走國2到鶯歌系統轉關西,點選方式為:三重 -> 機場系統 -> 關西 (程式會自動幫您選擇鶯歌系統喔!省下重新設定起點的步驟)


資料計算參照國道高速公路局「國道電子計程收費主題網」中收費試算採對用路人較有利的『牌價法』計算,非以行駛里程乘以通行費率計算,詳情清參閱其網站說明。

◎ How To Use?


◎ 連續選取不同國道的相鄰路段


◎ 詳細的路徑清單費用一目了然


◎ 當日來回選擇超 easy


◎ 喜歡趴趴走也隨你選


Enjoy it!

Comments

  1. 視覺化超棒,不過顏色的意思可否在圖面下方即時顯示意思,起奌,經過,重疊,次起奌,每按一次切換上述的功能

    ReplyDelete
  2. 這個意見改版時會參考,謝謝你建議。

    ReplyDelete

Post a Comment

Popular posts from this blog

PureMVC 我也會 [0]

最近感覺 PureMVC 又熱了起來,也剛好好久沒有更新文章了, 就順便將去年底做的企業內訓 PureMVC 課程部分整理寫出來, 要講 PureMVC 當然要先從啥是 MVC 講起: Model-View-Control 出處: 維基百科 MVC ,大概節錄一段: (控制器Controller)- 負責轉發請求,對請求進行處理。 (檢視View) - 介面設計人員進行圖形介面設計。 (模型Model) - 程式設計師編寫程式應有的功能(實作算法等等)、數據庫專家進行資料管理和數據庫設計(可以實作具體的功能)。 其實到 Flash 的世界來講,Model and Control 都是由 .as 處理,而 View 便是 .fla+.as ,為了要鬆綁之間的關係,Event 機制就相當重要。其實每個人對 MVC 的最佳解釋都不同,真的要多練習才會有所領悟。 簡單來說: Model = 餐廳廚房 data: 西餐類 action:依照點菜單做餐點 action: 做完餐點就是將餐點放在出菜口按下通知鈴等服務生來 Control = 服務生 action: 聽到大門歡迎鈴就要說「歡迎光臨」 action: 看到客人揮揮手要去收點菜單 action: 聽到廚房通知鈴看是哪桌的餐點去送菜 View = 餐廳外場 view: 田園式的西餐廳裝潢 action: 客人進門會有歡迎鈴 action: 客人揮揮手叫服務生過來服務,是哪個服務生都無所謂,重點只要會收點菜就行了。 action: 客人收到餐點準備開動 當餐廳要改成外炒店,這時候只需要將大廚換成會中餐廚師,其出的菜就是中式快炒。 當餐廳外場由田園式外觀重新裝潢成華麗感夜店風,其進門的客層也會有所不同。 重點就是當你換掉一個地方時,對其它的部份不會造成太大的影響或者根本無所謂,這就是 MVC 所講求的境界... 一般來說,小專案有沒有必要使用 MVC 就是由各位自己判斷了,當你習慣將程式切分開來,發現 debug 不是一件痛苦的事情時,這時候有沒有強制使用 MVC 倒不是重點,因為你已經養成良好的撰寫習慣。但是開始接觸大型專案配合 team work 時,在沒有一個共用的核心框架前提下,這個專案開發到最後一定會是一個多手多腳的怪物,共用核心框架的價值就在這邊展現,這

[Swift3] weak 與 unowned 關鍵字

雖然在 Swift 中看起來"很像"是不需要煩惱內存管理的問題,不過實際上它還是遵循著自動引用計數 (ARC) 的規則,當一個物件沒有被其他對象引用時會自動被銷毀,如果三魂七魄沒有完全回位的話,就會有個靈體留在現世的空間裡,最經典的範例如下: 閉包(Closure)引用 classClassA { typealias Complete = ()->() var name : String var onComplete : Complete? init(_ name: String){ self.name = name print("Hello I am \(self.name)") onComplete = { print("\(self.name): onComplete!") // --> 閉包引用 self, 計數 + 1 } } deinit { print("deinit: \(self.name)") } } var a : ClassA? = ClassA("A") // --> 引用計數 + 1 a = nil // 2-1 = 1 還剩下 1 所以沒辦法銷毀 ---output------- Hello I am A 由於這邊的 onComplete 宣告為 Optional, 正確的做法要連同 onComplete 一起刪除才可以被回收,若不是 Optional 則會進入無法回收狀態: var b : ClassA? = ClassA("B") b?.onComplete = nil // --> 還好是 Optional 可以設成 nil 計數 - 1 b = nil // 計數 = 0 所以被回收 ---output------- Hello I am B deinit: B 但是做人不需要煩惱太多,這時候就出動 unowned 關鍵字讓物件可以順利被回收: onComplete = { [unowned self] in print