Pure Java java.util.zip Implementation

   在J2ME的世界裡，沒有java.util.zip的lib可以用（弔詭的是明明porting也需要jar decoder，還是要包一個zip lib），對於J2ME的開發環境，Jar size動不動就限制2M或4M（此時覺得nokia的偉大，隨便都16M），遊戲圖片想要多一點、華麗一點就可以宣告死刑，當然有很多種方式可以達成目的，例如：降低圖片解析度、減少code size(這有點...)、全部resource用OTA下載、有些programmer就會利用zip的方式減少Jar Size，就最後一個方案是最不傷遊戲畫面及遊戲邏輯的解決方案，該死的是J2ME沒有這個玩意！

   不過日本的J2ME（DoJa）有com.nttdocomo.util.JarInflater取代之，所以才發想此專案 - Jazzlib2me

https://github.com/bearprada/jazzlib2me

   主要還是改自jazzlib這個J2SE的solution，歡迎大家享用(不過話說寫J2ME App的Programmer應該不多了:( )

Mobile Backend Services

The Administrator Page on Helios Server

   在開發App的同時，需要一些Server的功能來輔助，例如：Bug report、Push Message、In-app-purchase(包含購買即下載的功能)、使用者資料分析（好像有點違法）、雲端記錄檔等等。話說技術上難度並不是太高，反而多的是冗於的重工，又或者API或資料格式定義不好，導致實作的SDK有點難以理解。

通常尋求這類型解答有幾種思考模式：


第一、花錢消災型：多用第三方服務以利於快速達陣，花錢好辦事，問題有人檔，根據以上需求分別有：

Bug report : Bugsense、TestFight、Crashlytics
Push Message : Parse(最近被Facebook買走了)、UrbanAirShip
使用者資料分析：Flurry、Mixpanel

   這類型服務通常各種平台的SDK都要有，後端的資料儲存有多Big Data就多Big Data，當然好看的後台管理介面同樣只是基本需求，不過每種服務都可以相互跨越、取代（能存使用者資訊當然就能夠存Bug訊息）。

第二、硬幹型：這類型的思考通常覺得，東西是別人的就沒有安全感（怕很客製化的東西沒辦法加上去），不過如果太客製的需求是否代表著這是一個荒謬的需求？

第三、Open Source型：還是有些好心人會把類似的服務包成一個Open Source專案（例如: Helios或者OpenKit：OpenKit的前身的OpenFeint），自己就可以架一台Server囉！