Thanks ! I'll prepare the update for presence status and send it later
Thanks for the patch! It's now committed and ack-ed!
This was an important part of the android implementation base and I'm
very happy that we now have it. Are you going to send the presence status
patch with regards to this new resource implementation?
> I've added implementation for other resource types and changed the
architecture a little bit.
> Here's how it works now:
> Strings - requests are redirected to the strings defined in
"strings.xml" file, but in case the string is not found it will try to look
for strings defined in default string resources.
> Dots in keys are replaced with "_", as they can not be used for string
names in "strings.xml". For exmaple the string for key "service.gui.CLOSE"
should be declared as:
> <string name="service_gui_CLOSE">Close<string>
> Requests for other locales are redirected to corresponding folders as
it's defined in Android localization mechanism.
> Colors - mapped directly to those defined in /res/values/colors.xml
> Sounds - are stored in res/raw folder. The mappings are read from the
sounds.properties or other SoundPack's provided. Properties should point to
sound file names without the extension. For example:
> BUSY=busy (points to /res/raw/busy.wav)
> Images - images work the same as sounds except they are stored in
> For parts of Jitsi source that directly refer to image paths it will
map the requests to the drawable Android application resource names, so
that we can take advantage of built-in image size resolving mechanism. The
mapping must be specified in file
> Sample entries:
> I treat this as a temporary hack to make the presence statuses work
with jitsi code base, but I think the requests for paths that are not
returned by the resource service should be removed. It would be better if
they would ask the manager for images by keys like "protocol.sip.icon16".
> I'm sending a patch that implements Android version of
ResourceManagementService. It takes advantage of automatic Android's image
resolving mechanism. It's intention is to map path requests to Android
drawables, so that each time best image size will be selected basing on
user's screen size/resolution.
> The mapping is defined in file
> Example mapping:
> In this example requests for different icon sizes will be redirected to
Android drawable "sip_logo" which will be picked from one of folders:
res/drawable-ldpi, res/drawable-mdpi, res/drawable-hdpi and so on.
2013/3/6 Yana Stamcheva <email@example.com>
On Mar 1, 2013, at 11:31 AM, Paweł Domas <firstname.lastname@example.org> wrote:
> 2013/2/25 Paweł Domas <email@example.com>