線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:4248
推到 Plurk!
推到 Facebook!

DELPHI FOR IOS 好像有新版推出, 連收好多封廣告..(請勿再回覆)

 
ANDY8C
資深會員


發表:114
回覆:582
積分:299
註冊:2006-10-29

發送簡訊給我
#1 引用回覆 回覆 發表時間:2013-02-26 11:23:31 IP:210.66.xxx.xxx 未訂閱
 最近收到 DELPHI for IOS 的通知
好像有新的產品推出,促銷不斷,....唉

這一次....
不知只是拿未來的產品高談闊論,還是真的有東西可以用

說實在的
幾乎隔1,2年都要花錢買一次,光支這產品有用嗎 ??

實際上
案子做得出來才是王道.....所以,很缺教育訓練

重點是買軟體還是會用軟體 ???
但可惜的是書也沒人寫了,課程也沒開......

光買產品有用嗎?

不是唱衰....
這麼簡單的道理,原廠不知想到沒....



------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.
編輯記錄
ANDY8C 重新編輯於 2013-03-04 11:22:24, 註解 無‧
qcom
版主


發表:79
回覆:114
積分:43
註冊:2011-05-12

發送簡訊給我
#2 引用回覆 回覆 發表時間:2013-02-26 18:40:18 IP:61.219.xxx.xxx 訂閱
EMBT 今年全力放在推出 mobile 產品(iOS & Android) 上, Delphi for iOS是第一個附iOS native compiler的產品且已在最後測試階段, 尤其是iOS 與 Windows 的軟硬體規範以及deploy 方式不盡相同, 我們也正在同步測試並規劃推出中文參考書與訓練課程, 希望能在產品推出時協助用戶可快速上手進入iOS的開發領域.
編輯記錄
qcom 重新編輯於 2013-02-26 03:45:12, 註解 無‧
qcom 重新編輯於 2013-02-26 03:45:54, 註解 無‧
P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#3 引用回覆 回覆 發表時間:2013-02-26 21:22:06 IP:114.44.xxx.xxx 未訂閱
推出速度不夠快, IOS下滑, Android 越來越多廠商支援及使用,反觀IOS的系統, 越來越顯"卡卡", 太嚴格的門檻, 令人卻步,  讓我十分憂心, 是否 Delphi 要再重演一次 IOS 的悲劇
而 我下載 IOS測試, 連一行程式也沒寫到, 編譯就出狀況, 求助無門, 卡了3個月還是停留在原步, 上回發了一篇被警告,
趕緊刪除內容, 以免觸法, 我想, 這就是 ANDY8C 所憂心的, 也是我所憂心的事情
===================引 用 qcom 文 章===================
EMBT 今年全力放在推出 mobile 產品(iOS & Android) 上, Delphi for iOS是第一個附iOS native compiler的產品且已在最後測試階段, 尤其是iOS 與 Windows 的軟硬體規範以及deploy 方式不盡相同, 我們也正在同步測試並規劃推出中文參考書與訓練課程, 希望能在產品推出時協助用戶可快速上手進入iOS的開發領域.
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#4 引用回覆 回覆 發表時間:2013-02-28 08:50:44 IP:111.240.xxx.xxx 訂閱
沒試用過Delphi for IOS
但我曾經用過 monotouch ,猜想大概都是發展路線類似的框架
幾點意見僅供參考
1.Android Dalvik或 Cocoa 都算是很簡單的OS API,
一般有經驗的程式師都可輕易學會,那還有沒有必
要再包裝抽象一層?將來OS API更新是不是也要依賴
開發工具商包裝?
2.程序式的語言大同小異
學語言很快 學習平台API的知識才比較耗時費力
看了工具廠商Demo可能會認為用了什麼框架就可以跳過這段學習
那通常是工具廠商給的錯覺

3.非主流 可能常常需要翻譯網路上的範例程式
4.FireMonkey 感覺是通用性的框架 但IOS和 Android各式元件操作邏輯
天生就不太一樣 能否依平台調整細微的元件屬性令人存疑?
我就很不喜歡像導航pxgo那總不依平台UI特性調整的app
5.一直看到的廣告 常常強調 "native"這個字
到底什麼模式才算是native?指的是把程式編成byte code,
直接送到CPU執行?
6.現階段建議採用"主流"的開發工具 依各位資深程度保證很快上手
即使日後時機成熟轉換成Delphi 學習投資絕不會白費 反而更加游刃有餘
7.可能會有"回不去了"的情況

8.祝有志開發APP的人一開始就選對邊 新年恭喜發大財


===================引 用 P.D. 文 章===================
推出速度不夠快, IOS下滑, Android 越來越多廠商支援及使用,反觀IOS的系統, 越來越顯"卡卡", 太嚴格的門檻, 令人卻步, 讓我十分憂心, 是否 Delphi 要再重演一次 IOS 的悲劇
而 我下載 IOS測試, 連一行程式也沒寫到, 編譯就出狀況, 求助無門, 卡了3個月還是停留在原步, 上回發了一篇被警告,
趕緊刪除內容, 以免觸法, 我想, 這就是 ANDY8C 所憂心的, 也是我所憂心的事情
===================引 用 qcom 文 章===================
EMBT 今年全力放在推出 mobile 產品(iOS & Android) 上, Delphi for iOS是第一個附iOS native compiler的產品且已在最後測試階段, 尤其是iOS 與 Windows 的軟硬體規範以及deploy 方式不盡相同, 我們也正在同步測試並規劃推出中文參考書與訓練課程, 希望能在產品推出時協助用戶可快速上手進入iOS的開發領域.
Highlander
初階會員


發表:0
回覆:40
積分:43
註冊:2008-10-08

發送簡訊給我
#5 引用回覆 回覆 發表時間:2013-02-28 18:50:15 IP:180.177.xxx.xxx 訂閱
>

>2.程序式的語言大同小異 學語言很快 學習平台API的知識才比較耗時費力 看了工具廠商Demo可能會認為用了什麼框架就可以跳過這段學習 那通常是工具廠商給的錯覺

就是因為API太多, 太廣, 太雜才需要Framework, 這也是你說的 "學習平台API的知識才比較耗時費力". 工具廠商如果提供好的Framework的話可以大幅加快學習和生產的速度. MFC. OWL, VCL等都是如此, 並不是錯覺. 你說的Cocoa也是Framework, 它減少了大家開發iOS的痛苦.

>3.非主流 可能常常需要翻譯網路上的範例程式

這是問題之一, 不過當初Borland推出Delphi時MS也說Delphi是非主流, 但用的人多了就成了主流, 各種範例到處都是. 再說Delphi for iOS用Delphi語言是Delphi程式師都會的, 不是問題, 學習起來也遠比Object-C好學, Delphi的參考文件也不會比Object-C少.

>5.一直看到的廣告 常常強調 "native"這個字 直接送到CPU執行?

手機App可用原生或是Web開發啊, 強調 "native"這個字就是指App是直接執行, 不需要Browser輔助. 不過你說的Byte Code應該指Android吧, iOS的Object-C是直接compile成machine code執行, 不是byte code. Delphi for iOS也是直接compile成machine code執行, 同Object-C一樣. 未來的Delphi for iOS尚不知.

>即使日後時機成熟轉換成Delphi 學習投資絕不會白費 反而更加游刃有餘

是嗎? 就是因為用XCode開發太慢, 太痛苦. 所以參加了Delphi for iOS的beta, 從beta 6之後Delphi for iOS的開發效率和生產力比XCode高太多了, 我們許多App用Delphi for iOS開發比用XCode快了數倍之多, 現有的Delphi Codes還可再利用. 我同時使用XCode和Delphi for iOS, 我只能說只要Embarcadero最終推出穩定的Delphi for iOS, 我們一定轉到Delphi for iOS, 到時XCode在我們這會成非主流, Delphi for iOS會成主流. 更別說Delphi for Android出來後, 我想我只需要一個Team就可以用時做Windows, iOS和Android的開發, 再也不需要養3個Teams了. 養3個teams真是又累!又xxoo.

===================引 用 leveon 文 章===================
沒試用過Delphi for IOS
但我曾經用過 monotouch ,猜想大概都是發展路線類似的框架
幾點意見僅供參考
1.Android Dalvik或 Cocoa 都算是很簡單的OS API,
一般有經驗的程式師都可輕易學會,那還有沒有必
要再包裝抽象一層?將來OS API更新是不是也要依賴
開發工具商包裝?
2.程序式的語言大同小異
學語言很快 學習平台API的知識才比較耗時費力
看了工具廠商Demo可能會認為用了什麼框架就可以跳過這段學習
那通常是工具廠商給的錯覺

3.非主流 可能常常需要翻譯網路上的範例程式
4.FireMonkey 感覺是通用性的框架 但IOS和 Android各式元件操作邏輯
天生就不太一樣 能否依平台調整細微的元件屬性令人存疑?
我就很不喜歡像導航pxgo那總不依平台UI特性調整的app
5.一直看到的廣告 常常強調 "native"這個字
到底什麼模式才算是native?指的是把程式編成byte code,
直接送到CPU執行?
6.現階段建議採用"主流"的開發工具 依各位資深程度保證很快上手
即使日後時機成熟轉換成Delphi 學習投資絕不會白費 反而更加游刃有餘
7.可能會有"回不去了"的情況

8.祝有志開發APP的人一開始就選對邊 新年恭喜發大財


===================引 用 P.D. 文 章===================
推出速度不夠快, IOS下滑, Android 越來越多廠商支援及使用,反觀IOS的系統, 越來越顯"卡卡", 太嚴格的門檻, 令人卻步, 讓我十分憂心, 是否 Delphi 要再重演一次 IOS 的悲劇
而 我下載 IOS測試, 連一行程式也沒寫到, 編譯就出狀況, 求助無門, 卡了3個月還是停留在原步, 上回發了一篇被警告,
趕緊刪除內容, 以免觸法, 我想, 這就是 ANDY8C 所憂心的, 也是我所憂心的事情
===================引 用 qcom 文 章===================
EMBT 今年全力放在推出 mobile 產品(iOS & Android) 上, Delphi for iOS是第一個附iOS native compiler的產品且已在最後測試階段, 尤其是iOS 與 Windows 的軟硬體規範以及deploy 方式不盡相同, 我們也正在同步測試並規劃推出中文參考書與訓練課程, 希望能在產品推出時協助用戶可快速上手進入iOS的開發領域.
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#6 引用回覆 回覆 發表時間:2013-03-01 01:01:21 IP:111.240.xxx.xxx 訂閱
依照您的說法 您想要的產品早就出現  不需要再空耗時間等待前途不明的工具了
趕快進行 "3個Team" 的整合吧

http://xamarin.com/

===================引 用 Highlander 文 章===================
我只能說只要Embarcadero最終推出穩定的Delphi for iOS, 我們一定轉到Delphi for iOS, 到時XCode在我們這會成非主流, Delphi for iOS會成主流. 更別說Delphi for Android出來後, 我想我只需要一個Team就可以用時做Windows, iOS和Android的開發, 再也不需要養3個Teams了. 養3個teams真是又累!又xxoo.
Highlander
初階會員


發表:0
回覆:40
積分:43
註冊:2008-10-08

發送簡訊給我
#7 引用回覆 回覆 發表時間:2013-03-01 08:32:00 IP:180.177.xxx.xxx 訂閱
我不是說了嗎, 我要能再重利用我的大量Object Pascal/Delphi codes. 

===================引 用 leveon 文 章===================
依照您的說法 您想要的產品早就出現 不需要再空耗時間等待前途不明的工具了
趕快進行 "3個Team" 的整合吧

http://xamarin.com/

===================引 用 Highlander 文 章===================
我只能說只要Embarcadero最終推出穩定的Delphi for iOS, 我們一定轉到Delphi for iOS, 到時XCode在我們這會成非主流, Delphi for iOS會成主流. 更別說Delphi for Android出來後, 我想我只需要一個Team就可以用時做Windows, iOS和Android的開發, 再也不需要養3個Teams了. 養3個teams真是又累!又xxoo.
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#8 引用回覆 回覆 發表時間:2013-03-01 17:44:20 IP:111.240.xxx.xxx 訂閱
原來如此 我瞭解您的想法了
不過有個疑惑 你說你們單位有養3個team
猜測3個team的開發工具:
IOS team : objective-c
Android team: Java
Win Phone 8 : C#
不知道您的 "大量" Pascal碼 目前是放在那?
放在和上面打不著關係的X86 win32 嗎?
感覺您是要把3個team現有的程式碼全部丟掉
整合成一個Delphi team 然後開始抽換變成pascal碼
能快速搞定的原因是因為以前有留下大量的win32 的pascal碼
可以用來"參考"和 "複製 貼上" 這樣.....
聽起來真是匪夷所思呢!!!
依您的情況 那為何不把delphi的程式放在後端 化為網路服務呢?
何苦要發散到各平台?軟體即是服務嘛....
沒有什麼絕對的事 選擇當然都是在個人....

大多數的人都學的會

換個平台就是新的開始 換個開發環境也是很合理的事
跨平台重用程式是一門學問很高的事 能跑又要好 那是
難上加難 需要有長期跨平台經驗的人 才能做的好

空等空耗只會讓人心慌慌 貨比三家不吃虧
最近比較忙 沒有要戰啦 大家都想把產品做好
不是要唱衰 只是好意建議 參考看看囉



===================引 用 Highlander 文 章===================
我不是說了嗎, 我要能再重利用我的大量Object Pascal/Delphi codes.


Highlander
初階會員


發表:0
回覆:40
積分:43
註冊:2008-10-08

發送簡訊給我
#9 引用回覆 回覆 發表時間:2013-03-01 18:02:29 IP:180.177.xxx.xxx 訂閱
我們沒有Win phone, 我的3個平台是Win32/Win64, iOS和Android.

Win32/Win64 : Delphi
iOS : Object-C
Android : Java

就是因為3個平台不同, 不同程式碼, 不同UI Framework, 不同開發工具, 吃足了苦頭, 用了Delphi for iOS beta之後發覺生產力高, 又可以把Win32/Win64的經驗和codes帶過去, 實在不錯, 如果日後能再帶到Android去那更好. Window Phone目前就不必了, 市占率太小, 能把iOS/Android做好就夠了.

我沒有想戰什麼, 只是想這是一個技術的地方, 你有一些說法並不正確才提出我的看法來討論討論, 應該沒什麼吧.

===================引 用 leveon 文 章===================
原來如此 我瞭解您的想法了
不過有個疑惑 你說你們單位有養3個team
猜測3個team的開發工具:
IOS team : objective-c
Android team: Java
Win Phone 8 : C#
不知道您的 "大量" Pascal碼 目前是放在那?
放在和上面打不著關係的X86 win32 嗎?
感覺您是要把3個team現有的程式碼全部丟掉
整合成一個Delphi team 然後開始抽換變成pascal碼
能快速搞定的原因是因為以前有留下大量的win32 的pascal碼
可以用來"參考"和 "複製 貼上" 這樣.....
聽起來真是匪夷所思呢!!!
依您的情況 那為何不把delphi的程式放在後端 化為網路服務呢?
何苦要發散到各平台?軟體即是服務嘛....
沒有什麼絕對的事 選擇當然都是在個人....

大多數的人都學的會

換個平台就是新的開始 換個開發環境也是很合理的事
跨平台重用程式是一門學問很高的事 能跑又要好 那是
難上加難 需要有長期跨平台經驗的人 才能做的好

空等空耗只會讓人心慌慌 貨比三家不吃虧
最近比較忙 沒有要戰啦 大家都想把產品做好
不是要唱衰 只是好意建議 參考看看囉



===================引 用 Highlander 文 章===================
我不是說了嗎, 我要能再重利用我的大量Object Pascal/Delphi codes.


ANDY8C
資深會員


發表:114
回覆:582
積分:299
註冊:2006-10-29

發送簡訊給我
#10 引用回覆 回覆 發表時間:2013-03-01 19:25:41 IP:210.66.xxx.xxx 未訂閱
不是很懂您的用途,我很簡單的思考....既然有跨平台需求
何不用 WEB 方面的語言 ,例如 : HTML.....是否就更有彈性 ??

Win32/Win64 : HTML
iOS : HTML
Android : HTML

===================引 用 Highlander 文 章===================
我們沒有Win phone, 我的3個平台是Win32/Win64, iOS和Android.

Win32/Win64 : Delphi
iOS : Object-C
Android : Java

就是因為3個平台不同, 不同程式碼, 不同UI Framework, 不同開發工具, 吃足了苦頭, 用了Delphi for iOS beta之後發覺生產力高, 又可以把Win32/Win64的經驗和codes帶過去, 實在不錯, 如果日後能再帶到Android去那更好. Window Phone目前就不必了, 市占率太小, 能把iOS/Android做好就夠了.

我沒有想戰什麼, 只是想這是一個技術的地方, 你有一些說法並不正確才提出我的看法來討論討論, 應該沒什麼吧.


------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.
P.D.
版主


發表:603
回覆:4038
積分:3874
註冊:2006-10-31

發送簡訊給我
#11 引用回覆 回覆 發表時間:2013-03-02 02:44:24 IP:36.228.xxx.xxx 未訂閱
不想加入戰局, 不過我自己的感受來說
web 好嗎?
app 就不好嗎?
每一種軟體都有其好的地方, 也有不足的地方,
就像用 web開發, 好處是 web平台基本上有browse就可以跑, 看起來是沒有任何平台的問題,
但ios 不支援 flash, java又是一個大量充斥著 flash 的世界, 在 ios上就會綁手綁腳,
web 能做的到 ios 的 驅動 camera 功能嗎? 又或者感應器的驅動?
我想能達到的技術員, 門檻是很高的,
但app 就沒有缺陷嗎? 開發的門檻, 如果是那麼容易, 那我們設計人員早早就能弄出來了, 何必苦守著 dephi for ios,
一個技術員的養成不容易, 要轉型是要更大的勇氣, 就像我, 由dos一直一路走來, 市面上的語言, 我幾乎都學過, 能精的
沒幾種, 設計員只有懂那是不夠的, 必須要專精, 就像金庸筆下天龍八部的鳩摩智精通少林七十二絕, 其實是用小無相功催動一樣,
要成精沒那麼容易, 通才易就, 專才難成,
再者 app 想要設計出如同 web 的功能, 真的就那麼容易嗎?
所以我認為
app 與 web 是兩個世界的東西, 或許未來能再出一個賈柏斯或者是Sergey Brin (google技術創辦人), 把這兩個世界的東西整合在一起,
讓 google 與 ms 和解,
也讓技術員享受到和解的好處, 但如果是這樣的話, 反觀, 我們之所以還能存在這世界上, 就是我們有別人所沒有的技術, 如果大家都很容易就會的話, 那像我們這樣的技術員還有立足之地嗎? 這實在是很矛盾>>>
===================引 用 ANDY8C 文 章===================
不是很懂您的用途,我很簡單的思考....既然有跨平台需求
何不用 WEB 方面的語言 ,例如 : HTML.....是否就更有彈性 ??

Win32/Win64 : HTML
iOS : HTML
Android : HTML





ANDY8C
資深會員


發表:114
回覆:582
積分:299
註冊:2006-10-29

發送簡訊給我
#12 引用回覆 回覆 發表時間:2013-03-02 05:59:25 IP:210.66.xxx.xxx 未訂閱
所以說....WEB / BROWSER 最原始的美意是好的
但是 因為後來使用者環境的需求(視覺/硬體...等)多了
導致 WEB/BROWSER 的功能無法滿足 所以有 FLASH....新東西的加入
而這些非 "標準" 的 HTML 功能,在某些 BROWSER 平台,是否可以運作,變成關鍵


以單純的資料庫存取及顯示而言,HTML 是否就足夠了 ??


===================引 用 P.D. 文 章===================
不想加入戰局, 不過我自己的感受來說
web 好嗎?
app 就不好嗎?
每一種軟體都有其好的地方, 也有不足的地方,
就像用 web開發, 好處是 web平台基本上有browse就可以跑, 看起來是沒有任何平台的問題,
但ios 不支援 flash, java又是一個大量充斥著 flash 的世界, 在 ios上就會綁手綁腳,
web 能做的到 ios 的 驅動 camera 功能嗎? 又或者感應器的驅動?
我想能達到的技術員, 門檻是很高的,
但app 就沒有缺陷嗎? 開發的門檻, 如果是那麼容易, 那我們設計人員早早就能弄出來了, 何必苦守著 dephi for ios,
一個技術員的養成不容易, 要轉型是要更大的勇氣, 就像我, 由dos一直一路走來, 市面上的語言, 我幾乎都學過, 能精的
沒幾種, 設計員只有懂那是不夠的, 必須要專精, 就像金庸筆下天龍八部的鳩摩智精通少林七十二絕, 其實是用小無相功催動一樣,
要成精沒那麼容易, 通才易就, 專才難成,
再者 app 想要設計出如同 web 的功能, 真的就那麼容易嗎?
所以我認為
app 與 web 是兩個世界的東西, 或許未來能再出一個賈柏斯或者是Sergey Brin (google技術創辦人), 把這兩個世界的東西整合在一起,
讓 google 與 ms 和解,
也讓技術員享受到和解的好處, 但如果是這樣的話, 反觀, 我們之所以還能存在這世界上, 就是我們有別人所沒有的技術, 如果大家都很容易就會的話, 那像我們這樣的技術員還有立足之地嗎? 這實在是很矛盾>>>
===================引 用 ANDY8C 文 章===================
不是很懂您的用途,我很簡單的思考....既然有跨平台需求
何不用 WEB 方面的語言 ,例如 : HTML.....是否就更有彈性 ??

Win32/Win64 : HTML
iOS : HTML
Android : HTML





------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#13 引用回覆 回覆 發表時間:2013-03-02 15:34:33 IP:111.240.xxx.xxx 訂閱

===================引 用 P.D. 文 章===================
不想加入戰局, 不過我自己的感受來說
web 好嗎?
app 就不好嗎?
每一種軟體都有其好的地方, 也有不足的地方,
就像用 web開發, 好處是 web平台基本上有browse就可以跑, 看起來是沒有任何平台的問題,
但ios 不支援 flash, java又是一個大量充斥著 flash 的世界, 在 ios上就會綁手綁腳,
用檔案上傳的方式去兜 或用phonegap

下面影片是控制相機的Demo
我只能說 沒有真心熱情 做甚麼都很困難
每出一款新手機都想買 每次限免一定跟
都想要去了解別人是如何辦到的 並且動手
現階段 我還在努力去研究了解

成為專精高手 某顆能

充其量 那不過是工具廠商的廣告詞而已


===================引 用 ANDY8C 文 章===================
不是很懂您的用途,我很簡單的思考....既然有跨平台需求
何不用 WEB 方面的語言 ,例如 : HTML.....是否就更有彈性 ??

Win32/Win64 : HTML
iOS : HTML
Android : HTML





Highlander
初階會員


發表:0
回覆:40
積分:43
註冊:2008-10-08

發送簡訊給我
#14 引用回覆 回覆 發表時間:2013-03-02 18:26:15 IP:180.177.xxx.xxx 訂閱
很簡單啊, 因為Win32/Win64有Delphi的系統(C/S, 3-Tier), 現在客戶除了要傳統的PC, Desktop客戶端之外, 還要連結iOS, Android客戶端.

===================引 用 ANDY8C 文 章===================
不是很懂您的用途,我很簡單的思考....既然有跨平台需求
何不用 WEB 方面的語言 ,例如 : HTML.....是否就更有彈性 ??

Win32/Win64 : HTML
iOS : HTML
Android : HTML

===================引 用 Highlander 文 章===================
我們沒有Win phone, 我的3個平台是Win32/Win64, iOS和Android.

Win32/Win64 : Delphi
iOS : Object-C
Android : Java

就是因為3個平台不同, 不同程式碼, 不同UI Framework, 不同開發工具, 吃足了苦頭, 用了Delphi for iOS beta之後發覺生產力高, 又可以把Win32/Win64的經驗和codes帶過去, 實在不錯, 如果日後能再帶到Android去那更好. Window Phone目前就不必了, 市占率太小, 能把iOS/Android做好就夠了.

我沒有想戰什麼, 只是想這是一個技術的地方, 你有一些說法並不正確才提出我的看法來討論討論, 應該沒什麼吧.


Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#15 引用回覆 回覆 發表時間:2013-03-03 01:19:07 IP:111.243.xxx.xxx 訂閱
FB 都承認它們的HTML5 作APP 的方式掛點了, 結果你還在作HTML5 全功能的夢?
還是你比較高人一點, 我就不知道了.
但抓CAMERA 還要搞個上傳什麼, 光OVERHEAD 就飽了.


leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#16 引用回覆 回覆 發表時間:2013-03-03 02:02:58 IP:111.240.xxx.xxx 訂閱
中文能力有問題?你從那一句看到html5做全功能?
===================引 用 Lordaeron 文 章===================
FB 都承認它們的HTML5 作APP 的方式掛點了, 結果你還在作HTML5 全功能的夢?
還是你比較高人一點, 我就不知道了.
但抓CAMERA 還要搞個上傳什麼, 光OVERHEAD 就飽了.


Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#17 引用回覆 回覆 發表時間:2013-03-03 06:50:39 IP:111.243.xxx.xxx 訂閱
http://techorange.com/2012/09/12/mark-zuckerberg-html5-mobile/
http://news.cnyes.com/Content/20120824/KFM6WGR49S6RB.shtml
連CAMERA 都HTML了, 是我想太多? 還是你什麼都HTML的, 原來還要NATIVE?
我的中文應該沒問題, 不知你呢?

編輯記錄
Lordaeron 重新編輯於 2013-03-03 07:33:05, 註解 無‧
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#18 引用回覆 回覆 發表時間:2013-03-03 08:53:06 IP:111.240.xxx.xxx 訂閱
你貼這舊聞是要幹嗎?連我家隔壁念小學的小妹妹早就更新他
Iphone上的FB程式了

===================引 用 Lordaeron 文 章===================
http://techorange.com/2012/09/12/mark-zuckerberg-html5-mobile/
http://news.cnyes.com/Content/20120824/KFM6WGR49S6RB.shtml
連CAMERA 都HTML了, 是我想太多? 還是你什麼都HTML的, 原來還要NATIVE?

我指的檔案上傳是 http://pastehtml.com/view/chh0dj31e.html

在winodws看是選擇圖片檔 無法直接打開相機
在iphone android 是直接打開相機
不知道您的其他高招是?
我現在就是用Iphone回你這篇 來個範例網址吧 我馬上測
等你的"OVERHEAD" 大法喔



我的中文應該沒問題, 不知你呢?




Highlander
初階會員


發表:0
回覆:40
積分:43
註冊:2008-10-08

發送簡訊給我
#19 引用回覆 回覆 發表時間:2013-03-03 10:37:45 IP:180.177.xxx.xxx 訂閱
>http://phonegap.com/about/feature/

下面影片是控制相機的Demo
你的邏輯真的有問題, 你前面說不要相信"
工具廠商的例子, 那個Delphi for PHP更是使用了許多的Frameworks.

>?成為專精高手 某顆能充其量 那不過是工具廠商的廣告詞而已
太托大了吧, 為什麼你可以肯定別人沒熱情又不是高手呢? Delphi for iOS有新的FireMonkey for Mobile Framework, 新的 LLVM compiler, 新的ARC RTL, 都是要學的, 只是EMBT封裝的好, Delphi的開發人員可以藉由以前瞭解的技術很容易的上手, 很快的就有生產力. 對於剛要進入iOS開發的人更容易, 因為Delphi for iOS提供RAD/CBD開發方式, 比起要寫一大堆程式碼的XCode來說方便多了.

不依靠經驗更可笑, Object-C是從C/C 來的, iOS是受Next的影響, XCode和許多其他的開工具都有類似的設計和概念. 能寫好出程式更是經驗的累積和精化.

看來你可能沒試過Delphi for iOS, 那我建議你沒有用過, 不瞭解的東西不要遽下評論. Delphi for iOS是工具, XCode也是工具, Delphi for iOS能取代XCdoe? 當然不能. 就像Delphi/BCB不能取代VC 一樣, 但Delphi/BCB有很大的市場, 為什麼? 因為有高生產力, 不是每個人都要去寫drivers.

熟悉VC 且對MFC瞭若指掌的人不是高手?
熟悉Delphi/BCB且對VCL/FireMonkey瞭若指掌的人不是高手?
熟悉Eclipse且對Spring/Hibernate/EJB瞭若指掌的人不是高手?
java?flash? 看不懂這句是?

web 能做的到 ios 的 驅動 camera 功能嗎? 又或者感應器的驅動?

http://phonegap.com/about/feature/
delphi for php 就有用phonegap
https://www.youtube.com/watch?v=IPWUHomwvAw




我想能達到的技術員, 門檻是很高的,
但app 就沒有缺陷嗎? 開發的門檻, 如果是那麼容易, 那我們設計人員早早就能弄出來了, 何必苦守著 dephi for ios,
一個技術員的養成不容易, 要轉型是要更大的勇氣, 就像我, 由dos一直一路走來, 市面上的語言, 我幾乎都學過, 能精的
沒幾種, 設計員只有懂那是不夠的, 必須要專精, 就像金庸筆下天龍八部的鳩摩智精通少林七十二絕, 其實是用小無相功催動一樣,
要成精沒那麼容易, 通才易就, 專才難成,
再者 app 想要設計出如同 web 的功能, 真的就那麼容易嗎?
所以我認為
app 與 web 是兩個世界的東西, 或許未來能再出一個賈柏斯或者是Sergey Brin (google技術創辦人), 把這兩個世界的東西整合在一起,
讓 google 與 ms 和解,
也讓技術員享受到和解的好處, 但如果是這樣的話, 反觀, 我們之所以還能存在這世界上, 就是我們有別人所沒有的技術, 如果大家都很容易就會的話, 那像我們這樣的技術員還有立足之地嗎? 這實在是很矛盾>>>


如果你跟我一樣 當一個專業的低頭族
每個月花上幾百元買app 看到神奇的功能
看看自己也能不能辦到 這樣的話
你絕不會想要死守某個工具

還有很多地方不懂
沒有熱情參與 只想依靠以前平台的經驗 或某總熟悉工具 就想
成為專精高手 某顆能

充其量 那不過是工具廠商的廣告詞而已


===================引 用 ANDY8C 文 章===================
不是很懂您的用途,我很簡單的思考....既然有跨平台需求
何不用 WEB 方面的語言 ,例如 : HTML.....是否就更有彈性 ??

Win32/Win64 : HTML
iOS : HTML
Android : HTML





leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#20 引用回覆 回覆 發表時間:2013-03-03 12:35:25 IP:111.240.xxx.xxx 訂閱

===================引 用 Highlander 文 章===================

你的邏輯真的有問題, 你前面說不要相信"
工具廠商的例子, 那個Delphi for PHP更是使用了許多的Frameworks.


6. 即使日後時機成熟轉換成Delphi 學習投資絕不會白費 反而更加游刃有餘
是"現階段" 而不是指 "永遠" 或 "將來" OK?


太托大了吧, 為什麼你可以肯定別人沒熱情又不是高手呢? Delphi for iOS有新的FireMonkey for Mobile Framework, 新的 LLVM compiler, 新的ARC RTL, 都是要學的, 只是EMBT封裝的好, Delphi的開發人員可以藉由以前瞭解的技術很容易的上手, 很快的就有生產力. 對於剛要進入iOS開發的人更容易, 因為Delphi for iOS提供RAD/CBD開發方式, 比起要寫一大堆程式碼的XCode來說方便多了.

不依靠經驗更可笑, Object-C是從C/C 來的, iOS是受Next的影響, XCode和許多其他的開工具都有類似的設計和概念. 能寫好出程式更是經驗的累積和精化.

注意喔 是"平台"的經驗 請注意"
你自己也曾說過"又可以把Win32/Win64的經驗和codes帶過去, 實在不錯"
熟悉XCode且對Cocoa瞭若指掌的人不是高手?



且在各自領域有一席之地 這我是知道的
我說的專精高手 是指"IOS專精高手" "Android專精高手"
曾經 我想靠D2006 成為.Net 高手 結果??




一點建議 參考看看囉





我身邊很多朋友/同事都是熟悉 "這些某種工具" 的人, 我認為這些人都是高手.
Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#21 引用回覆 回覆 發表時間:2013-03-03 13:41:48 IP:111.243.xxx.xxx 訂閱
http://stackoverflow.com/questions/7521963/phonegap-app-performance-vs-native-app-performance
overhead 大法來了, 你回家吃自己吧.
你家小妹沒OVERHEAD 嘛.
leveon
資深會員


發表:30
回覆:389
積分:303
註冊:2012-02-12

發送簡訊給我
#22 引用回覆 回覆 發表時間:2013-03-03 14:00:30 IP:111.240.xxx.xxx 訂閱
 看來看去看不懂你到底想表達甚麼?
不過無所謂 我要去找其他懂中文的人聊天了 不送~ 掰
===================引 用 Lordaeron 文 章===================
http://stackoverflow.com/questions/7521963/phonegap-app-performance-vs-native-app-performance
overhead 大法來了, 你回家吃自己吧.
你家小妹沒OVERHEAD 嘛.
Lordaeron
初階會員


發表:24
回覆:93
積分:33
註冊:2004-05-19

發送簡訊給我
#23 引用回覆 回覆 發表時間:2013-03-03 14:16:43 IP:111.243.xxx.xxx 訂閱
不懂還可以這麼嗆的回呢. 真是神人.
Highlander
初階會員


發表:0
回覆:40
積分:43
註冊:2008-10-08

發送簡訊給我
#24 引用回覆 回覆 發表時間:2013-03-04 10:55:08 IP:180.177.xxx.xxx 訂閱
>1.Android Dalvik或 Cocoa 都算是很簡單的OS API,一般有經驗的程式師都可輕易學會,那還有沒有必要再包裝抽象一層?將來OS API更新是不是也要依賴開發工具商包裝?
我說的 "以前平台的經驗" 平台指的是win32 平台"兩字

windows和Mac 許多機制天生就不同 相差很大阿怎麼到這裡變成Next了?

你說經驗不重要所以我舉了2個程式語言和一個你特別用紅字打的平台. iOS和Next都是平台, 你不憧嗎? 我說Mac和iOS都是從Next發展出來的, 我在以前用Next的經驗也在Mac/iOS中看到, Windows, Mac, iOS, Android的Event trigger, message handling都是類似的經驗和概念, Framework封裝的好會有什麼差別? 就像我們以前從OWL換到MFC, 再從MFC換到VCL這些Framework都是封裝Window messages和event handling, 有了一個framework的經驗之後學其他的就很快了, Delphi的FireMonkey framework學了之後用它寫Windows/Mac幾乎沒差別.

>曾經 我想靠D2006 成為.Net 高手 結果??

這只是你的結果, 不代表別人都是如此. 因為不管你是使用API, XCode, VC , Delphi, BCB., Eclipse..., 沒有深掘的精神用什麼都成不了高手. 事實上我個人絕得用好的Frameworks才能成高手, 因為一旦有了生產力之後再去trace整個framework的source, 學學人家怎麼寫出這麼好的framework, 再比較不同frameworks的設計架構和差異才能進步神速, 對軟體設計功力大增, 眼界大開, 我身邊幾位高手都是這樣練成的. 反而一樣只用API的人, 我只能說他們用API很熟,但成不了高手, 只能稱做熟手, 而且很難到其他平台, 因為學全一個平台的API太麻煩了, 所以這些人通常也不願意離開他們熟悉的平台, 也不太願意學新的東西和新的平台.


>一點建議 參考看看囉


這是沒錯, 我也沒什麼意見. 只是你的建議中說的東西有些不對所以我才上來討論一下, 以免不瞭解的人錯判觀念.


===================引 用 leveon 文 章===================


===================引 用 Highlander 文 章===================

你的邏輯真的有問題, 你前面說不要相信"
工具廠商的例子, 那個Delphi for PHP更是使用了許多的Frameworks.


6. 即使日後時機成熟轉換成Delphi 學習投資絕不會白費 反而更加游刃有餘
是"現階段" 而不是指 "永遠" 或 "將來" OK?


太托大了吧, 為什麼你可以肯定別人沒熱情又不是高手呢? Delphi for iOS有新的FireMonkey for Mobile Framework, 新的 LLVM compiler, 新的ARC RTL, 都是要學的, 只是EMBT封裝的好, Delphi的開發人員可以藉由以前瞭解的技術很容易的上手, 很快的就有生產力. 對於剛要進入iOS開發的人更容易, 因為Delphi for iOS提供RAD/CBD開發方式, 比起要寫一大堆程式碼的XCode來說方便多了.

不依靠經驗更可笑, Object-C是從C/C 來的, iOS是受Next的影響, XCode和許多其他的開工具都有類似的設計和概念. 能寫好出程式更是經驗的累積和精化.

注意喔 是"平台"的經驗 請注意"
你自己也曾說過"又可以把Win32/Win64的經驗和codes帶過去, 實在不錯"
熟悉XCode且對Cocoa瞭若指掌的人不是高手?



且在各自領域有一席之地 這我是知道的
我說的專精高手 是指"IOS專精高手" "Android專精高手"
曾經 我想靠D2006 成為.Net 高手 結果??




一點建議 參考看看囉





我身邊很多朋友/同事都是熟悉 "這些某種工具" 的人, 我認為這些人都是高手.
ANDY8C
資深會員


發表:114
回覆:582
積分:299
註冊:2006-10-29

發送簡訊給我
#25 引用回覆 回覆 發表時間:2013-03-04 11:21:23 IP:210.66.xxx.xxx 未訂閱
 唉 !!

我想大家是針對技術討論,講話對事不對人,無心去攻擊任何人
所以前輩們,我們年紀也有了,也有了一些技術,所以更有智慧處理這些事......

也許
千錯萬錯都是 delphi 這家公司的錯 !!

懇請....前輩們針對以上的主題或內容,就不要再回覆了
懇請....前輩們針對以上的主題或內容,就不要再回覆了
懇請....前輩們針對以上的主題或內容,就不要再回覆了

不然.....我變成罪人....

還有,在網路上,因為見不到對方,所以不小心就會容易 "動肝火"
我的意思是不要因此失去了網路上的朋友

因為沒有見過各位,也許下次若參加 Qcom 活動
各位可以到 "第一排" 那一地帶,找我 / PD / 大俠 / LULU....等
(我們通常都座那裡)
大家認識一下,
認識許多網友後,技術交流/接案子/吃飯聊是非....都是很輕鬆平常的事

Qcom 也許下次活動時,撥 30 分鐘,讓我們大家可以自我介紹一下
順便認識彼此,應該有正向的意義,

在此網站上/在民間各行業,大家各有一片天,
歷年來,為了案子/技術問題,已經被 DELPHI 這家公司的產品搞的爆肝了
何需在此又 "動肝火" ,多麼不值得呀 !!

謝謝您




------
---------------------------------------
偶爾才來 KTOP ,交流條碼問題,在 FB [條碼標籤達人] 社團留言,感恩.
GrandRURU
站務副站長


發表:240
回覆:1680
積分:1874
註冊:2005-06-21

發送簡訊給我
#26 引用回覆 回覆 發表時間:2013-03-05 16:55:58 IP:59.120.xxx.xxx 未訂閱
相比之下,我會比較擔心聽到

「Delphi for iOS 2不相容1的產品,需要重新來過……八啦八啦」

D7->D8->D20... (VCL->VCL.NET->VCL 中間0066中斷陣亡的項目應該不需我多言,就連官方主推的DBX到現在都沒有官方的BDE/ADO移轉升級工具,這是痛一)

XE2 -> XE3 =FM for iOS1->FM for iOS2 (有去聽產品發表會的應該知道1->2必須打掉重寫這件事,很妙的是,發表會上說的是概念相同,移轉不是難事。這叫已開案的TEAM情何已堪,更糟的是XE3不能使用XE2的FM專案接續開發,這是痛二)

FM for iOS已經炸了一次,但也許Delphi for iOS或許是好物,但說真的,我根本不敢用

對於資金緊縮的公司(我相信會越來越多),很難有年年買的預算,買軟體,是要負責專案成敗的

一個有潛在地雷 需要自行掃雷的產品,要怎麼說服愛好者來買呢?

===================引 用 P.D. 文 章===================
推出速度不夠快, IOS下滑, Android 越來越多廠商支援及使用,反觀IOS的系統, 越來越顯"卡卡", 太嚴格的門檻, 令人卻步, 讓我十分憂心, 是否 Delphi 要再重演一次 IOS 的悲劇
而 我下載 IOS測試, 連一行程式也沒寫到, 編譯就出狀況, 求助無門, 卡了3個月還是停留在原步, 上回發了一篇被警告,
趕緊刪除內容, 以免觸法, 我想, 這就是 ANDY8C 所憂心的, 也是我所憂心的事情
===================引 用 qcom 文 章===================
EMBT 今年全力放在推出 mobile 產品(iOS & Android) 上, Delphi for iOS是第一個附iOS native compiler的產品且已在最後測試階段, 尤其是iOS 與 Windows 的軟硬體規範以及deploy 方式不盡相同, 我們也正在同步測試並規劃推出中文參考書與訓練課程, 希望能在產品推出時協助用戶可快速上手進入iOS的開發領域.
編輯記錄
GrandRURU 重新編輯於 2013-03-05 17:07:54, 註解 無‧
系統時間:2024-04-20 5:55:55
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!