Comments on Masabists: The Truth About Mobile Fragmentation

Thanks. :)--Ehud.

2008-04-11T13:36:00.000+01:00

Thanks. :)

--
Ehud.

Hi again Elud,Low memory basically means of the or...

2008-04-05T09:39:00.000+01:00

Hi again Elud,

Low memory basically means of the order of early S40 devices, so 64K jar + 200K RAM - we still see significant downloads for these phones, but many of the other older platforms are dying away now which makes life easier :)

Normally we adjust API support at build time and have more speciifc builds, but if the project demands it we can do single app builds with the old Class.forName trick - usually we would do this where the client needed to be able to use any standard web server. You lose some functionality and some devices this way - eg. some JBed JVM devices won't allow it.

For remote testing we have used DeviceAnywhere and Forum Nokia's service; I believe Sony-Ericsson now offer one too. Normally we use this just to test out specific API or handset bug support, and do the main user experience testing on local handsets - remote testing is a great additional resource but not a complete substitute for a big cupboard of devices!

PNG bugs: there are about 3 "levels" of Zlib bug we've found in PNGs, also issues with only allowing ARGB PNGs through to devices which have >1bit transparency, some types of palette which load incorrectly, some Sagem issues where the PNG row lengths are misread... plenty of irritating little things!

Automated testing I can't talk so much about I'm afraid, but basically scriptable emulators which can be customised to perform repeat workflows at build time and ensure certain properties are consistent, no exceptions, etc.

Hope that is some help!

Tom

Hey Tom.Thanks for the detailed and useful reply. ...

2008-03-31T17:13:00.000+01:00

Hey Tom.

Thanks for the detailed and useful reply.

I have some more questions, if you don't mind (and if it isn't too much of a "trade secret". :)

1. By saying "low memory profile", how much do you actually mean?

The few apps I've worked on so far were made to work on ~64/200K JAR/heap limits for 128x128x12, which mostly seemed to expand well to higher resolutions and bit depths (although with very textured graphic elements the file size increase was more rapid).

I guess this is much less of a problem, though, if targetting only 2005/2006 phones and onwards (and possibly ignoring the exceptionally limited ones).

2. Do you use dynamic class loading or on-the-fly determination of features to have more generic builds?

3. Did you mean dev portals that offer remote testing?

4. Have you used remote testing for apps that are sensitive to input timing?

5. Can you share what problems are caught during build? (And what PNG problems there are besides too few Huffman entries?)

6. Finally, can you give examples of "more automated testing"? :)

--
Ehud.

Hi Ehud,Sorry for the late reply: QA/testing is in...

2008-03-27T15:14:00.000Z

Hi Ehud,

Sorry for the late reply: QA/testing is indeed a tricky problem.

We use the following development strategy:

1) Write code which is "failsafe" ie. largely MIDP1 avoiding all types of bugs and problematic techniques we have encountered over the last 7 years, using a low memory profile etc.

2) Group devices together into platforms and do separate builds per platform - this is actually safe if done carefully, and you can the vast majority of devices with 30-60 builds. We always test on at least one real handset per group, then use a combination of dev portals (where available), 3rd party resources on the web and remote testing services to establish which devices fit into that platform safely. Advanced features (going beyond point 1) are then turned on and off per build based on our experiences with the platform - often we have two or three implementations of something and a platform uses the one that works best.

3) We use build tools which catch and automatically correct common problems, like PNGs which cannot load correctly (this is 99.9% predictable once you know how ;).

Our QA steps work like this for an application:

1) Wrap logic in unit tests where possible, run at build time for every device variant.

2) Perform initial logic and workflow testing on a few different emulators across different screen sizes - they are good for high level testing but not for fragmentation issues.

3) Application builds are then initially tested on a "core" set of devices - the most popular and the most buggy - until they work reliably.

4) We then test the remaining builds across all our other test devices.

5) Any "new" features and APIs being used are tested more extensively across real local and remote devices, and "best practice" implementations are then rolled into our framework.

We are also investing in more automated testing to catch common issues earlier and eliminate on-device testing for anything other than checking handset bugs and device quirks.

It's frustrating, but there isn't any viable alternative for any kind of mobile development (you need to do the same for the mobile web etc). Once you have a good stable core framework, it's surprisingly easy to develop apps that work pretty well first time.

Hope that helps some,

Tom.

Missing from the previous comment :) :--Ehud.

2008-03-14T23:42:00.000Z

Missing from the previous comment :) :
--
Ehud.

How do you deal with platform bugs and testing/QA?...

2008-03-14T23:41:00.000Z

How do you deal with platform bugs and testing/QA?

Assuming emulators or lead/reference devices are indicative can be dangerous, and having hundreds of devices available for testing is a problem, as is the time it would take to test on all of them.

And this is further compounded by having manufacturers that, for unclear reasons, make supporting their devices difficult, like LG's zero tools and information policy or Samsung's mostly OTA only installations.

Hi,For most day-to-day projects, we use a vector p...

2008-03-09T13:18:00.000Z

Hi,

For most day-to-day projects, we use a vector package like Xara X which allows you to draft at one size, then rapidly produce copies at different sizes which can be tweaked to look good.

For some designs, Photoshop designs (making use of layer styles) can work in the same way if the mockup is done at the largest size variant required, but resizing usually requires manual touching up.

For generating hundreds of reskins of a basic design across all screen sizes, it is worth investing the time to fine tune templates for every size which can then be customised automatically.

There is no perfect solution, but with a bit of practice it can be managable :)

Best regards,
Tom.

Hi Tom, really love the article, you totally hit t...

2008-03-09T12:41:00.000Z

Hi Tom, really love the article, you totally hit the target with this one.

Although I don't really understand this part:
Managing this screen size complexity is a challenge without huge graphics production timelines (and suicidal designers), but one that can be met with scripting and templates. In Playtech’s case games can feature amazing levels of variation where the graphics require less than a day to customise for a new licensee, ready to drop into an automated build.

How do you manage the multiple screen sizes? What techniques do you use? I gather, since it is all pixel graphics, the artist still needs to draw all the variants himself, you can't use a tool for "resizing" the graphics. Or can you?

Best Regards,
Tommy