Talk:Binary Runtime Environment for Wireless

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)

Very sad to see folks dismissing hobbyists in such a cavalier, off-hand manner. Typical of the ignorance generally prevalent amongst the kids today. Wouldn't they PTP if they were to learn that if it weren't for a few dedicated hobbyists like MITS and Gary Kildall and many others that these twerps would still be hitchin' up their jeans and walking down to the local soda bar to chat with their few friends from the local neighborhood instead of FBing globally. What the current BREW program really means is that only larger corporations, trust fund kids and the porn industry will be developing apps for great phones like the LG Dare. How sad. JimScott (talk) 15:51, 2 March 2009 (UTC)

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. >_>

ADS/RVDS vs. gcc

It's possible to develop for Brew phones with GCC, see [1] Perhaps it would be worthwhile to mention this?

redirect

Should Brew redirect to Brewing? Wouldn't that make sense? Or maybe a disambig?

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)

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).

Needs more wiki

Seems unencylopedic to me. Mathiastck 21:32, 4 January 2007 (UTC)

True Brew Testing

The link is incorrect

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.

Sprint?

Does Sprint count as a carrier running a JVM ontop of BREW? Mathiastck 02:48, 24 May 2007 (UTC)

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)

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)

I've done some cleanup.

*The BREW API is more standard across supported phones than the J2ME API...

Added dead link notice to the dead link, and added a dubious tag to the statement: what does it mean by standard? J2ME is created precisely to have a standard platform to develop mobile applications, how is BREW more "standard"?

* The API tends to be cleaner than J2ME, and many of the recent API changes have made BREW very game friendly.

Repeat of the first point, not backed up by reference

* Graphics tricks are easier, especially with BREW 2.0 and direct access to the screen buffer.

Not clear on what it means by graphics tricks, only retained the direct access to the screen buffer and added a citation required tag.

* J2ME phones often have an artificial limit to the size of the binary (128KB is common). This isn't present with BREW.

Changed to legacy J2ME phones, modern phones don't have this size limit any more.

* BREW applications can use Object-oriented programming.

Changed to "allows more freedom": it's not that you can't do OOP in Java, just that it has more overhead.

* BREW applications perform much faster

Added "due to its native nature", as native applications will run faster than Java apps. Also added mention to Symbian OS, another system with native application support.

* Being embedded on the chipset and connected to a tight and secure distribution network...

Removed. Security advantage is vague, the phone capability section basically says "while you can do it in J2ME in BREW it's defined!" and the "states" thing doesn't make sense. J2ME MIDlets allows multi-tasking, provided your phone supports it (eg. Most Sony Ericsson phones released after (and including) K800 and possibly before).

I've left the neutrality on there because there are still some that sound like advertising. --antilived^{T | C | G} 11:44, 2 August 2008 (UTC)

Conflicting info on emulators

On one hand, at first the article says:

The BREW Emulator... does not emulate handset's hardware. Instead... compiled to native code... obscure platform bugs related to memory alignment and various firmware related glitches make debugging applications without a BREW handset difficult. Developers must test their applications on real BREW-enabled handsets.

Later is says:

The development environment is standardized... and contains a well integrated emulator that properly reflects the behaviour of the actual device

Which one is it?

82.81.35.212 (talk) 16:53, 13 November 2008 (UTC)

Additionally, as I have come to understand things over the years, their tool is correctly called a simulator and not an emulator. The distinction between the two is that an emulator is run to produce the same effect as the thing being emulated, whereas a simulator is run for any other purpose, such as to determine if the new package will work correctly.

For example running an Atari emulator would be for the purpose of playing an Atari game. One might also play an Atari game on an Atari simulator, but the simulator would have been produced to explore and measure the behavior of an Atari, such as to study its efficiency of power or storage.

Arthur Protin 68.166.100.10 (talk) 16:21, 8 May 2009 (UTC)

NPOV and OR issues

Much of the critisms of BREW are WP:OR. While I agree with the issues expressed regarding frustration of hobbyists with signature costs, petitioning operators, and required test certifications, they can't just be voiced. Criticisms must be attributed to a source. I rewrote the critism section and the section about application development (I still need to add sources for the latter, but it's all straight summary of the content on the official BREW site).

Claims about platform specific bugs come off as contradictory, as the entire idea of a runtime environment is for it to work the same across all platforms. It wouldn't surprise me if such bugs were indeed an issue, but any contradictory sounding claims really need sourcing.

The whole issue about benefiting large development houses as an advantage of BREW is pure conjecture. (I believe this is also discussed above).

Going into detail about specific file names is overkill for this type of article. Readers interested in that level of detail should be reading the SDK documentation directly.

I can't find information concerning enabling and disabling apps based on handset free space. It sound like something specific to certain versions or even certain operators. I'm considering removing it. -Verdatum (talk) 21:42, 12 June 2009 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Binary Runtime Environment for Wireless. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090205050241/http://www.verisign.com:80/products-services/security-services/code-signing/brew-document-ids/index.html to http://www.verisign.com/products-services/security-services/code-signing/brew-document-ids/index.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:29, 2 November 2016 (UTC)