Talk:Binary Runtime Environment for Wireless
From Wikipedia, the free encyclopedia
Contents |
[edit] Question about criticism section
Does anyone think the word hobbyist should be replaced with something else. When I think of a hobbyist I think of someone wanting to make a program just for fun or to show friends, not someone who want's to make a product to be sold on carrier decks. Technically it is still possible for hobbyists to make applications for BREW handsets and load it on the handsets (if they can get access to qualcoms app loader or a similar program), they just won't be able to sell it through carrier decks (correct??). I'm thinking of changing it from hobbyists to something like small devlopers. What does anyone think about this? *Nov 2006*
- One of two conditions must be met in order to load a BREW applet onto a handset with the BREW AppLoader. a) The handset must be specially configured as a "test" handset; these are not available to the general public. b) The application must be True BREW certified and digitally signed, which is what the $400+ certification mentioned in the article is about. This means that hobbyists are pretty much excluded from developing even for their *own* handset, let alone distribution through carriers. --Nephtes 18:20, 10 November 2006 (UTC)
[edit] Interested in BREW info for the Mobile Development page
A few people said that BREW should be included in the Mobile development page, I'd be interested in any and all additions to the comparison chart. Benjaminhill 01:38, 27 February 2006 (UTC)
Got a lot of suggestions, all set, thanks! Benjaminhill 03:43, 30 March 2006 (UTC)
GAAAAA! My phone only supports brew, and that sucks, because I can't develop for it then. >_>
[edit] ADS/RVDS vs. gcc
It's possible to develop for Brew phones with GCC, see [1] Perhaps it would be worthwhile to mention this?
[edit] redirect
Should Brew redirect to Brewing? Wouldn't that make sense? Or maybe a disambig?
[edit] Advantages of Brew over J2ME
From the advantages of Brew over J2ME:
The testing and development costs and difficulties weed out developers with low budgets and low tolerance for pain, resulting in less market dilution.
This is not a very neutral statement and perhaps should be removed. Plus, is this really an advantage? From my point of view, any application platform that is plagued with testing and development difficulties is a bad platform.
- It could be taken to mean that the lower level of competition is an advantage from a business perspective -- in which case in needs clarifying. Really though, I'd say that whole section (advantages + disadvantages) could do with rewriting --Nephtes 16:57, 5 October 2006 (UTC)
-
- I've added a cleanup tag to those sections. The wording is slangy and their point of view may not be neutral. Sentences like these...
-
-
Time to market can take longer than with J2ME. After application is written it takes 2 weeks per iteration of True BREW testing (if your app fails). Then negotiations with carrier have to commence. Then (if successful) carrier will spend time testing your application, because being True BREW is not enough for them. Imagine rolling out a new version: it's all over again.
-
-
- ...are why cleanup is needed. 216.98.197.149 21:50, 12 January 2007 (UTC)
[edit] Weakness turned into advantage?
This sounds like some twisted logic: "BREW applications can use Object-oriented programming. In J2ME the filesize overhead for extra classes encourages C-like programming. In addition, because arrays of non-primitive types are actually arrays of references, there is significant memory overhead in J2ME for arrays of classes. To get around this, parallel arrays of primitive types are often used in J2ME"
Let's think about it: it is _possible_ to write in BREW using object-oriented style. Author was vague on how easy it is or how many developers actually do that, smart move! Yet, Java offers object-oriented style and allows procedural style with no extra cost, and some developers (targeting their programs to low-end devices that may have 256K of RAM or less, good luck running BREW on one!) opt for that style, while majority enjoys programming in OO.
- Actually, the statement is valid (although perhaps the wording could be clearer). J2ME handsets, especially early models, have a fairly restrictive limit on the size of the .jar file the app must be stored in. Early Nokia handsets, for example 3595 and 6010 models, have a limit of 64k and are still in common use. Combined with the fact that defining a class incurs a substantial (400-1000 bytes) overhead, this makes it extremely difficult to use real object-oriented design, because for anything but very simple applications the per-class overhead would leave too little space for actual working code and data. On the other hand, it's no harder to code BREW apps in C++ than it is in straight C, and the per-class overhead is negligible (if any). --Nephtes 16:02, 13 November 2006 (UTC)
-
- But you should clarify that more recent J2ME handsets do not have such restictions anymore. For example I have a SonyEricsson K610i, it has a dynamic
heap for java apps of about 1.5M and the JAR size is only limited by available memory (whitch can be expanded by a memory card). Okay, this is a new 3G phone, but my 2.5 year old Siemens S65 also accepts JARs >350K without problems. (Christian) —The preceding unsigned comment was added by 80.133.155.79 (talk) 17:15, 8 December 2006 (UTC).
-
-
- It's true that JAR size limits are not an issue on modern phones. However, if you're developping for a wide array of handsets you still have to make the same design decisions if you don't want to have to completely rewrite your app for older phones (which, as I mentioned, still represent a significant portion of the installed base). Besides that, the overhead means that in a very real sense, each class you define costs your customers money if they pay by the kb to download your stuff.
-
-
-
- Let me clarify. J2ME programmers avoid writing lots of classes for two main reasons:
-
1) Smaller jar size ... the jar zip algorithm compresses better when there are less files. 2) uses more memory. But mainly the reason is 1). Also, I like to clarify some other points in the artical: The jar limit in most countries really more like 200K and this is due to GPRS download rates, NOT due to any "artifical limit". The artifical limit was mainly due to old handsets like Nokia S40 ed. 1, which do not exist anymore except in emerging markets. It follows that if you are talking about emerging markets like China or India this statement is accurate. And likewise if you are devloping for emerging markets, then you are also less likely to use OO methods for reasons mentioned above. —The preceding unsigned comment was added by 82.159.227.4 (talk) 07:29, 2 May 2007 (UTC).
[edit] Needs more wiki
Seems unencylopedic to me. Mathiastck 21:32, 4 January 2007 (UTC)
[edit] True Brew Testing
The link is incorrect
[edit] Profiler
Profilers for C/C++ are expensive, whereas the J2ME environment comes with a profiler.'
When you take a look at Performance analysis#List of Profilers, you'll see there are GNU (i.e. free) profilers for C/C++, so generally speaking you cannot say C/C++ profilers are expensive. --Abdull 09:00, 29 March 2007 (UTC)
I presume they are talking about the profiler that comes with the sun WTK. This software is incredibly slow and buggy. I imagine that most developers find it just too painful to use.
[edit] Sprint?
Does Sprint count as a carrier running a JVM ontop of BREW? Mathiastck 02:48, 24 May 2007 (UTC)
[edit] phonebooks
There are enough incompatibilities among BREW handsets. Addressbooks are implemented so differently in phones of different manufacturers that custom approach is needed to distinguish Motorola from Samsung from Kyocera (field-based vs record-based phonebooks).
- There are three carrier names but only two types of phonebooks. Can we make the numbers match (Motorola and Samsung from Kyocera)? Or add another type of phonebook? I don't know anything about them and simple google searching didn't help. Thanks! --Daev 14:57, 29 May 2007 (UTC)
[edit] NPOV "Advantages"
Several of the noted points are claiming things that are true of both J2ME and BREW, as if they applied only to BREW. Until cleaned up to be more neutral and fact-based, this needs to be marked for NPOV cleanup. Note several citation requests throughout the section. Todd Vierling (talk) 20:00, 14 February 2008 (UTC)
