問題描述
為多個移動設備構建單一應用程序 (Single application build for multiple mobile devices)
是否可以為多個移動設備構建一個應用程序二進製文件（在 BREW 平台上） ，而不是使用帶有條件編譯的構建腳本為每個設備單獨構建。
特別是是否可以為多個屏幕分辨率使用單個 BREW 應用程序構建？
請注意，目標是有一個單一的二進制構建。如果只是擁有一個代碼庫，那麼條件編譯和智能構建腳本就可以解決問題。
參考解法
方法 1:
Yes, it is possible, we were able to do this at my previous place of work. What's required is tricky though:
- Compile for the lowest common denominator BREW version. Version 1.1 is the base for all current handsets out there.
- Your code must be able to handle multiple resolutions. The methods for detecting screen width and height are accurate for all handsets in my experience.
- All your resources must load on all devices. This would require making your own custom image loader to work around certain device issues. For sound, I know simple MIDI type 0 works on all but QCP should also work (no experience of it myself).
- Use bitmap fonts. There are too many device issues with fonts to make it worthwhile using the system fonts.
- Design your code structure as a finite state machine. I cannot emphasise this enough ‑ do this and many, many problems never materialise.
- Have workarounds for every single device issue. This is the hard part! It's possible but this rabbit hole is incredibly deep...
In the end, the more complex and advanced the application, the less likely you can go this route. Some device properties simply cannot be detected reliably at runtime (such as platform ID) and so multiple builds are then required.
方法 2:
I wrote a J2ME to Brew conversion that is used at Javaground. It is quite possible to write multiple resolution, single binary code. We have a database of device bugs so that it can detect via platform id the device and then generate a series of flags which mark which bugs are tagged. For example most (if not all) of the Motorola Brew phones have a bug where an incoming call does not interrupt the application until you answer the call, so I use TAPI to monitor for an incoming call and generate a hideNotify event (since we are emulating Java, although the generated code is pure C++). I do some checks at runtime for Brew version, and disable certain APIs if it is Brew 2 rather than Brew 3.
3D type games are easier to make resolution independent since you are scaling in software.
Also there are 2 separate APIs for sound, IMEDIA and ISOUNDPLAYER, ISOUNDPLAYER is the older API and is supported on all devices but doesn't have as many facilities (you can only do multichannel audio using IMEDIA). I create an IMEDIA object, and it will fall back to create an ISOUNDPLAYER object if it can't get the IMEDIA object.
The problem with a totally universal build is that there is a big difference in capability, so it can be worth having a few builds, the older devices only have under 1MB of heap (and a small screen size), and then you get a lot with 6MB+ (176x204 to larger).
With Brew you do have a fairly consistent set of key values (unlike Java), although some of the new devices are touch screen (and you have to handle pointer input) and rotating screens.
There are also some old Nokia phones that use big endian mode which mean the files are not the same as the normal mod files (UNLESS you want to write some REALLY cool assembly language prefix header that decodes the file)
方法 3:
Another idea might be to have the handsets divided into 2 to 4 categories based on say screen dimensions and create builds for them. It is a much faster route too as you will be able to support all the handsets you want to support with much lesser complexity.
Another thing to see is the BREW versions on the handsets you want to launch on. If say BREW 1.1 is on one handset and that is owned by a small percentage in your target market, it doesnt make sense to work to support it.
(by Maxim、Shane Breatnach、nharding、Omer Muhammed)