APP程式和WEB程式有什麼不同

工作忙到有一陣子沒有寫文章了。事實上也有不知道要寫什麼對大家會比較有幫助。

最近有客戶希望服務單位幫客戶寫APP。在交談過程中，發現客戶對APP和WEB的解決方案在觀念上有誤解，認為手機的解決方案就是APP。

在交談過程中，知道客戶的使用者不只希望能在手機上使用，也希望有RWD(Responsive Web Design或叫響應式網頁)的效果。所以最後結果用WEB網頁，採用RWD的技巧，完成客戶交待的工作。

這個案例讓筆者覺得可以寫一篇文章來說明APP和WEB在本質上的不一樣，讓大家比較有清楚的觀念。希望以下的文章對大家的觀念有幫助。

APP和Web的不同

WINDOWS和WEB一定要選一邊嗎?

拜讀了Delphi先進有關平台的發展文章

風水輪流轉，這次又會轉回【Windows-base Client】了嗎？(上) ── Windows程式猿的危機
風水輪流轉，這次又會轉回【Windows-base Client】了嗎？(中) ── 開發界的潮流擂台賽
風水輪流轉，這次又會轉回【Windows-base Client】了嗎？(下) ── 存亡關鍵的最後一哩

除了覺得題目很有探討性以外，也在對方的留言中會說明自己的看法。結果因為當時比較忙，加上是別人的部落格，寫太多好像不太尊重主人，所以只留下了寫的很好的意見。

其實在發展平台上，的確是有WINDOWS、WEB、APP的區別；不過在應用上，個人比較偏向--管他黑貓白貓，會抓老鼠的就是好貓。能快速、適合的解決問題，就是好的解決方案。

舉例而言，ERP應該是WINDOWS的程式吧，怎麼樣也不適合用WEB來做，特別是執行效率上很慢。可是從WEB上做安裝下載，確是一件很方便的事。所以人口是WEB的(因為方便，大家用BROWSER就可以連上，不用做太多說明)。按下去之後，就會開始下載安裝程式，自動安裝連線到主機，接下來就是一連串的自動化設定，然後就是WINDOWS的ERP操作介面了。對使用者而言，這樣他們最方便，他才不管WINDOWS和WEB是有多麼大的不同。善用不同平台的特性，反而成了AP工程師比較重要的事了。

跨平台應該會是未來很重要的工作，我指的不是像JAVA這種跨平台的程式語言。而是你可以整合不同平台的程式(管它是用什麼開發的)，讓最終的使用者方便操作使用。只要和end User緊密結合，工作永遠都需要你。

公司用DELPHI開發WEB平台，計畫參與人寫了一系列的文章，推薦給大家。

當Delphi遇見Javascript

WEB前端列印

最近筆者和客戶見面，談到WEB的一些解決方案。發現有些工程師覺得Browser就是在WINDOWS上執行的程式，所以列印方式應該和在WIN FORM上的列印方式應該很接近。其實Browser為了安全性和本身作業的獨立性，不會和作業系統做很緊密的結合。
因為Browser有這樣的特性，所以要做類似ERP報表套印的程式，就變的比較麻煩，筆者寫了一篇有關 WEB列印 的文章，大家如果有興趣，可以連進去看看，參考一下。
對WEB老手來說，這應該是基本知識了，如果你剛進入WEB寫HTML，希望這篇文章對你有幫助。

DataAware簡易說明

最近一直在忙做產品的影片，其中有做到在WEB上的DataAware。如果對DataAware案例有興趣的朋友，可以參考一下 DataAware的簡介說明 這個影片。

既然都提到DataAware了，就來說明一下它的應用和好處吧。我們在做程式設計時，畫面顯示的資料和資料庫儲存的資料，基本上是連動的，一般而言，以下圖為例

左方的GRID如果筆數更改，右方EDIT的對應欄位也要跟著改變。同樣的如果右方EDIT修改內容，左方的GRID內容也要跟著改變。因為是他們都是同一筆資料。


現在問題來了，每個對應的欄位都要寫程式去改變其他元件(GRID、EDIT、CHECKBOX等)，工程是不是太大了。如果資料TABLE加一個欄位，是不是程式又要加一堆互動的程式?

DataAware就是為了解決這個問題。它的原理是以DataSet為中心，所有和DataSet有關的元件，只要有值變更，就會通知DataSet，然後DataSet再通知相關元件做資料的更新，達成資料的一致性。

有了DataAware和資料感知元件，程式人員就不用花心力在資料的同步上，可以減少大量的程式負擔。

[分享] Delphi 的 TColor 與常見 Hex 16進位色碼轉換

在網頁上總是有許多漂亮的顏色，我們也可以用簡單的小程式把它轉換成TColor
讓我們的程式不會總是預設的clBlack，clRed，clBlue...
以下是程式碼，原著來自Zarko Gajic

DELPHI上WEB辛苦談

當初要把Delphi上WEB是一個【選項】，不是個【必然】。可以選擇C# 或是 Java。幾經考慮之後，還是利用Delphi上WEB，但幾個問題橫在眼前：

1.      Delphi本身不能直接橋接IIS，只能使用ISAPI，但這技術似乎過時。

2.      Delphi是Native語言，無記憶體自動回收架構。

3.      Delphi是Native語言，要Compile之後才能分發。

左思右想之後，只有取巧利用C#當IIS與Delphi橋接口，將來自Browser需求利用C#轉呼叫由Delphi 做成的COM SERVER。C#負責Session 管理，Delphi提供服務。如此一來，就輕易解決上WEB的架構。

【無記憶體自動回收架構】這問題在傳統上是相當嚴重，因為Server 需長期運行，如果有記憶體遺漏，很快就會造成Server死當。後來，幾經折騰COM SERVER改成Single Instance之後，這問題就不嚴重了。因為，每個使用者都是獨立，反而系統更穩定。

【要Compile之後才能分發】這問題會帶來版本及分發安全的問題，不過，後來實作一個系統分發之後，這問題變成小問題。

用DELPHI產生HTML

大家熟悉的HTML一般都是用UTF-8格式來做存檔格式，可是DELPHI所用的TXT FILE卻都是用ANSI格式，所以在存檔和轉換都會有許多問題，那怎麼做比較好呢?
筆者最近因為工作上的關係，常會用HTML做樣板，然後再用DELPHI把檔案讀進來，做一些轉換，再形成新的HTML供BROWSER讀取，就碰上了格式的問題。
最後的解決方式是用TStringList的LoadFromFile來解決這個問題
舉例如下
function RefreshHTM():String;
var
  HTML1,HTML2  :TStrings;
  FG : Boolean;
  i : Integer;
begin
  try
    // 宣告二個TString，HTML1承接HTML樣版，HTML2是做轉換後要顯示的HTML結果
    HTML1 := TStringList.Create;
    HTML2 := TStringList.Create;
    try
      // 取得樣版的HTML
      HTML1 .LoadFromFile('D:\web_root\html\PTL01U05.htm');
      for i :=0 to HTML1.Count-1 do
      begin
        // 逐筆把資料抓入
        Ln := HTML1[i];
        // 這邊做想要更換的作

        // 把更改後的資料加到HTML2中
        HTML2.Add(Ln);
      end;
      Result := HTML2.Text;
    finally
      //把資料傳出後，把TString Free 掉
      HTML1.Free;
      HTML2.Free;
    end;
end;

Delphi可以上WEB嗎?

提供一篇還不錯的文章 DELPHI的WEB解決方案 ，在目前大家都熱衷於APP的時候，還有人做Delphi 的WEB解決方案。

大家有空看一下吧，可以讓大家更瞭解在Delphi領域的程式人員在思考什麼，用Delphi開發了那些應用程式。

Delphi缺的那一塊

Delphi在APP的領域，目前可說是發光發熱。大家也都覺得embarcadero會利用整合iOS、Android的平台開發，而讓Delphi重返昔日榮耀之路。這樣的方向應該也沒錯，畢竟在WEB這個領域，被.NET的佔有率給打趴了。

不過就商業運用來說，Delphi在WINDOWS介面的程式發展是相當不錯的，特別是在資料庫的領域方面。舉凡國內大廠鼎新的ERP和正航的大套系統，都是用DELPHI開發的。結果在WINDOWS開發的系統，在WEB這一塊必須用ASP、.NET開發，然後APP再回到DELPHI來做，感覺中間就缺了一段。

APP的程式運用能補足Delphi在WEB缺失的這一塊嗎?或許再往後一二年才知道結果如何吧！