Device differences

[Craig Evans]

We have had a number of "issues" with the Kyocera 3035b phone - code that passed on the Sharp Z800, failed on the Kyocera ...

We have resolved all our problems, but feel that if code works on one phone, under one version of the API, it should work on all phones with that same (or later) API version. At no point were we blowing the memory on the phone, everything was being dynamically created, used, then deleted from memory, and after running the app, the amount of memory left was the same as what we had started with.

So, all we can put it down to was the call stack getting too deep ...

Anyone else having (or had) similar issues in compiling code for multiple handsets where it works for one but not the other?

CSE

[BobF]

Indeed, we've observed that the two handsets have different behaviors, and the incompatibilities have appeared in both directions (Kyocera OK, Sharp not and vice versa).

The stack space is really tight on the 3035, and it has even changed between OEM builds of their code, so my advice is to be ultraconservative.

[Craig Evans]

That was actually our solution ... funny thing was that our code crashed the phone only after 45 passes through the grinder (@ 1000 keystrokes per grind run), so it took about 4 hours for the phone to crash.

Our eventual solution was to make one of the advanced features of our app an option that could be toggled on or off, with the feature off by default.

This is using the 1.0.18 build of BREW ... hopefully it's better under the 1.1.18 version, but we needed to code to the lowest common denominator.

[fredch]

I've had this problem on the Kyocera with 2 different apps. I ended up writing a lot of code to trace memory (heap) management, and the heap can get fragmented beyond use pretty quickly. For example, one of my apps never went below 10KB available, but quickly gets to where it can't allocation more than 256 contiguous bytes - any malloc attempt for more than that fails, and loading any resource larger than that fails. I tried allocating all the memory I was ever going to need at startup, then manage my own use of it. This helps, but the "system" does it's own allocations, so the heap still gets fragmented if I do various combinations of loading images and creating text controls. You have to make sure you only use 1 "system" item at a time - load bitmap/draw/free or create text control/use text control/free text control. Don't do any mallocs or creating of other controls while you are using a bitmap or control.

[Kevin]

The Kyocera3035 shares heap space with Brew. Other devices allocate a distinct region of the heap for Brew, so other phones will have less fragmentation.