Opinionated comments on mobile phone industry news
|
All entries are written by Anders Borg, CEO and Consultant of Abiro, that has a long experience in strategic planning, developing embedded and Java software, usability aspects, and the mobile phone industry in general. You can also read the latest Mobile News entries on your phone via wap.abiro.com, and we provide many News Feeds from popular news services. For advertising and contribution queries, please use the feedback form. News feed (local) FeedBurner Feed
|
|
Tuesday, June 12, 2007
Make MIDlets smaller by downloading resources on demand
Here's a good way to save on MIDlet size (and hence also downloading time and cost): Implementing a Local Cache to Manage Resources
Apart from images and other "normal" resources I would also suggest localization string lists could gain from this: Then the (likely only) needed language would be downloaded when the application is started for the first time (simply choosing the desired language from a list that's part of the MIDlet). It could also be used for application skins/themes etc.
When it comes to data that might need updating over time it's even more fitting. E.g. landmarks, users, contact information, additional levels in games, interpreted scripts (a la widgets) that could completely change the application behavior, etc.
Most non-game MIDlets are service frontends, so they anyway communicate via switched data (HTTP or other), even if they were installed from a PC, so updating resources this way is already prepared for.
It should be noted though that not all phones have tons of RMS space. In the early days of MIDP it could even just be a few kiobytes per MIDlet, so for maximum phone compatibility this still needs to be used cautiously.
Over time, and with flatrate subs etc and faster networks, resources can and will be downloaded each time the MIDlet is started and instead stored in RAM. I use that approach in a service frontend type MIDlet I'm currently working on, where the list of users, landmarks etc could change at any moment, but that still gains from semi-permanent local access while the application is running.
Whatever the means for storage, such downloading and access could be completely abstracted (which is also described in this note), so that when a resource is needed the resource class would figure out if it's already cached or needs downloading because it doesn't exist locally or has expired. It should also check if it runs out of storage, and if so delete the least accessed resource(s), to make room for the new one(s).
If there had been a business in selling code libraries for MIDlets someone would have already developed this class and licensed it to development houses. Unfortunately it doesn't work that way.
(via CEO's Mobility Weblog)
Apart from images and other "normal" resources I would also suggest localization string lists could gain from this: Then the (likely only) needed language would be downloaded when the application is started for the first time (simply choosing the desired language from a list that's part of the MIDlet). It could also be used for application skins/themes etc.
When it comes to data that might need updating over time it's even more fitting. E.g. landmarks, users, contact information, additional levels in games, interpreted scripts (a la widgets) that could completely change the application behavior, etc.
Most non-game MIDlets are service frontends, so they anyway communicate via switched data (HTTP or other), even if they were installed from a PC, so updating resources this way is already prepared for.
It should be noted though that not all phones have tons of RMS space. In the early days of MIDP it could even just be a few kiobytes per MIDlet, so for maximum phone compatibility this still needs to be used cautiously.
Over time, and with flatrate subs etc and faster networks, resources can and will be downloaded each time the MIDlet is started and instead stored in RAM. I use that approach in a service frontend type MIDlet I'm currently working on, where the list of users, landmarks etc could change at any moment, but that still gains from semi-permanent local access while the application is running.
Whatever the means for storage, such downloading and access could be completely abstracted (which is also described in this note), so that when a resource is needed the resource class would figure out if it's already cached or needs downloading because it doesn't exist locally or has expired. It should also check if it runs out of storage, and if so delete the least accessed resource(s), to make room for the new one(s).
If there had been a business in selling code libraries for MIDlets someone would have already developed this class and licensed it to development houses. Unfortunately it doesn't work that way.
(via CEO's Mobility Weblog)
