[jitsi-dev] Android discussions


#1

Hey Pawel,

I wanted to ask you do you know which of the following files is not used in
current android project:
config/defaults.properties
images/image_path.properties
images/images.properties
languages/resources.properties
sounds/sounds.properties

Thanks
damencho

···

On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> wrote:

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile
On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images,
translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs < >> ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from
the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org>wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org>wrote:

> I have compared the sources from jitsi and jitsi-android which we
used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in
separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

> -

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService
needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip
because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

> -
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
cause of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html<http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFactory.html>
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must
check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in
order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it
will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to
speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#2

Hi Damian,

Hey Pawel,

I wanted to ask you do you know which of the following files is not used in
current android project:
config/defaults.properties
images/image_path.properties
images/images.properties
languages/resources.properties
sounds/sounds.properties

Thanks
damencho

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

···

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> wrote:

On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> wrote:

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile

On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images,
translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs >>> <ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from the
desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> >>>> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> >>>>> wrote:

> I have compared the sources from jitsi and jitsi-android which we
> used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
> already
> changed.

That looks very good and is probably the blueprint for further
changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is
> shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in
> separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

> -

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService
needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip
> because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set,
this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

> -
> net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some
> smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
> cause of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must
> check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in
> order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for
Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this
> one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it
> will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to
> speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hi devs,

the android project is ready and you can all check it out.
https://github.com/jitsi/jitsi-android
Currently only the specific android source is available and jitsi bundles
are in folder lib/bundles.
As in the old repository there is a need of some classes renaming, as the
jsip packages to avoid clashing with the one in android, the sasl stuff in
smack, and the core java packages missing in android as java.awt and javax
.swing.
The libs folder (which in android projects is by default used for
libraries) is created if missing and there are copied all the needed
libraries. The jars which will have packages renamed need to be copied
every time in libs folder, because of the compilation of the android
sources. And when all classes are available the rename can take place over
the class files and the jars.
There is a new task named "copy-jitsi-bundles" which will take care to
update all current bundles from the original sc-bundles folder. Later we
can make this automatic or just make those libs available for ivy.

I think the compile process is a little bit faster now cause the libs
folder used to be deleted and recreated every time which lead to
pre-dexingall jars, now this is done only for the changed files and
those that have
packages renamed.

The only problem now is that I didn't managed to force libs reload after
coping. The problem is only on the first time the project is checkout and
the first compile fails as when started compiling, libs folder is missing
and empty. But after the first compile everything works just fine.

Ready for any questions or suggestions

Regards
damencho

···

On Sat, May 18, 2013 at 9:38 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Damian,

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> wrote:
> Hey Pawel,
>
> I wanted to ask you do you know which of the following files is not used
in
> current android project:
> config/defaults.properties
> images/image_path.properties
> images/images.properties
> languages/resources.properties
> sounds/sounds.properties
>
> Thanks
> damencho
>
>

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

> On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> > wrote:
>>
>> Well it is the notification service who is using it. This is the biggest
>> change left from the refactoring I'm currently doing.
>> Currently checking what is actually used there and will come up with
>> something on Monday and then it will be ready for the new repository.
>>
>> -- sent from my mobile
>>
>> On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:
>>>
>>> Yepp, thats clear. I was refering to its usage from within the
protocols.
>>>
>>> -- sent from my mobile
>>>
>>> Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :
>>>
>>> Hi Ingo,
>>>
>>> no this bundle contains all the resources, like sounds, images,
>>> translates ...
>>>
>>> Regards
>>> damencho
>>>
>>>
>>> On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs > >>> <ingo@sip-communicator.org> wrote:
>>>>
>>>> Isn't this thing only used for settings-defaults? If so, we wanted to
>>>> move the default settings into the configurationService anyway...
>>>>
>>>> Ingo
>>>>
>>>> -- sent from my mobile
>>>>
>>>> Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :
>>>>
>>>> Hey Yana, Pawel,
>>>>
>>>> we also need to discuss and the defaultresourcepack bundle. Cause the
>>>> source code is the same but in android we do not need the resources
from the
>>>> desktop application.
>>>> Actually are we using that? Wasn't there a new resource service impl?
>>>>
>>>> Regards
>>>> damencho
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> > >>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> more inline:
>>>>>
>>>>>
>>>>> On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> > >>>>> wrote:
>>>>>>
>>>>>> > I have compared the sources from jitsi and jitsi-android which we
>>>>>> > used to
>>>>>> > sync and here is what I have in my todo list:
>>>>>> >
>>>>>> > - in net.java.sip.communicator.impl.certificate a dialog is shown,
>>>>>> > already
>>>>>> > changed.
>>>>>>
>>>>>> That looks very good and is probably the blueprint for further
>>>>>> changes.
>>>>>>
>>>>>> > - net.java.sip.communicator.impl.credentialsstorage a dialog is
>>>>>> > shown
>>>>>>
>>>>>> Similar to the certificate service?
>>>>>
>>>>>
>>>>> Yep, already fixed.
>>>>>
>>>>>>
>>>>>>
>>>>>> > - net.java.sip.communicator.impl.dns to move the config form in
>>>>>> > separate
>>>>>> > bundle
>>>>>>
>>>>>> Yepp, into the plugin namespace.
>>>>>> I'm working on replacing the unbound native stuff and the config
will
>>>>>> also
>>>>>> change. For the time being, I think you could just leave out the
>>>>>> complete
>>>>>> dns impl package.
>>>>>
>>>>>
>>>>> Also done that.
>>>>>
>>>>>>
>>>>>>
>>>>>> > -
>>>>>>
>>>>>>
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
>>>>>> > using java.awt.Toolkit use reflection to load it.
>>>>>>
>>>>>> Not sure, but I'd have guessed that the whole NotificationService
>>>>>> needs to
>>>>>> be implemented differently for Android?
>>>>>>
>>>>>> > - operation set desktop sharing was removed from jabber and sip
>>>>>> > because of
>>>>>> > java.awt.event.MouseEvent and java.awt.event.KeyEvent
>>>>>>
>>>>>> Not sure how this would work out for Android, but if some classes
in a
>>>>>> jar
>>>>>> wouldn't be available on the desktop, it wouldn't matter as long as
>>>>>> they're
>>>>>> not called. So as long as it isn't registered as an operation set,
>>>>>> this
>>>>>> shouldn't matter.
>>>>>
>>>>>
>>>>> Well loading some classes is failing currently cause of missing
classes
>>>>> but I'm currently on it.
>>>>>
>>>>>>
>>>>>>
>>>>>> > -
>>>>>> >
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
>>>>>> > sasl mechanisum does not compile in android
>>>>>>
>>>>>> Smack for Android seems to import
>>>>>> org.apache.harmony.javax.security.sasl.*
>>>>>> I'm wondering if we still really need our own modified SaslMd5
thing.
>>>>>> If we
>>>>>> do, loading it conditionally on the desktop or through reflection
>>>>>> should be
>>>>>> possible.
>>>>>
>>>>>
>>>>> Well it is used for some buggy xmpp servers ... well I'm also not
sure
>>>>> how to handle it,
>>>>> maybe turn it off and enable it on demand with prop.
>>>>>
>>>>>>
>>>>>>
>>>>>> > - check why white board operation set is commented and will jabber
>>>>>> provider
>>>>>> > bundle will normally operation under android with it
>>>>>>
>>>>>> I thought we dropped support for that long ago? Why not completely
>>>>>> remove
>>>>>> the code?
>>>>>>
>>>>>> > - in ProtocolProviderServiceJabberImpl we are pre-configuring some
>>>>>> > smack
>>>>>> > services as they are normally loaded from the jar file.
>>>>>>
>>>>>> Could that be done somewhere outside of the PPS, or maybe by
>>>>>> subclassing it?
>>>>>
>>>>>
>>>>> Yep I'm currently integrating protocol bundles and will test it (code
>>>>> running only
>>>>> under android).
>>>>>
>>>>>>
>>>>>>
>>>>>> > - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
>>>>>> > cause of
>>>>>> > SSLSocketFactory
>>>>>>
>>>>>> Um, why? It should be there...
>>>>>>
>>>>>>
http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
>>>>>> tory.html
>>>>>> Are we using some methods/constructors that are not yet there?
>>>>>> OTOH: we have a // TODO: move to HttpUtil.
>>>>>> I don't know what API level we want to support, but at some point
>>>>>> Android
>>>>>> decided to kind of drop support for httpcomponents and suggesting
some
>>>>>> other
>>>>>> method for HTTP requests (sorry, don't remember the class name)
>>>>>
>>>>>
>>>>> Well the version differ, I currently get this error:
>>>>> 05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
>>>>> org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from
method
>>>>>
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
>>>>> 05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve
direct
>>>>> method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
>>>>>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V
>>>>>
>>>>> Thanks
>>>>> damencho
>>>>>
>>>>>>
>>>>>> > - in SipStackSharing we have changed the path name of the factory
to
>>>>>> > org.jitsi.gov.nist, because of the renaming of jsip package, must
>>>>>> > check
>>>>>> will
>>>>>> > it work after adding the protocol bundle
>>>>>> > - LoggingUtils separate the configuration form
>>>>>>
>>>>>> -> To plugin
>>>>>>
>>>>>> > - NotificationManager - some image loading which we must remove in
>>>>>> > order
>>>>>> to
>>>>>> > use the plugin in android
>>>>>>
>>>>>> The NM is a complex beast. I'm wondering if we could split it up
into
>>>>>> multiple classes or even provide a different implementation for
>>>>>> Android
>>>>>> (because I'm guessing that not all events are needed there).
>>>>>>
>>>>>> > - UIContact and UIGroup use SIPCommButton (from desktoputil) -
this
>>>>>> > one
>>>>>> Yana
>>>>>> > has upcoming change which will fix it
>>>>>> > - service.httputil.HttpUtils - doesn't compile in android, using
it
>>>>>> > will
>>>>>> not
>>>>>> > be possible
>>>>>>
>>>>>> I'm wondering why (because Apache HttpClient should be available),
but
>>>>>> otherwise same as with the XCAP stuff.
>>>>>>
>>>>>> > - icon in FileUtils, maybe separate as service
>>>>>>
>>>>>> Move the whole FileUtils into impl.gui.utils? It seems it's not used
>>>>>> outside
>>>>>> of impl.gui.
>>>>>>
>>>>>> > - android's UtilActivator adds JavaUtilLoggingConfig
>>>>>> >
>>>>>> > This are the notes and changes we need to do in order to reuse
jitsi
>>>>>> bundles
>>>>>> > in android.
>>>>>> > Also I'm currently testing a change in the build system in order
to
>>>>>> > speed
>>>>>> up
>>>>>> > development/test process.
>>>>>> >
>>>>>> > Comments and help are welcome :slight_smile:
>>>>>> >
>>>>>> > Thanks
>>>>>> > damencho
>>>>>>
>>>>>> Ingo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev@jitsi.org
>>>>>> Unsubscribe instructions and other list options:
>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi Pawel,

Hi Damian,

Hey Pawel,

I wanted to ask you do you know which of the following files is not used in
current android project:
config/defaults.properties
images/image_path.properties
images/images.properties
languages/resources.properties
sounds/sounds.properties

Thanks
damencho

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

Have you committed the whole implementation related to this image_path.properties mapping? I'm trying to use getImageInBytes method and it doesn't seem to work properly. I don't see any lookup to be done in image_path.properties in the latest code from svn (I'll switch to git tomorrow, but I thought that your changes should already be part of the last version on svn). Am I missing something?

Cheers,
Yana

···

On May 18, 2013, at 9:38 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> wrote:

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> wrote:

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile

On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images,
translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs >>>> <ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from the
desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> >>>>> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> >>>>>> wrote:

I have compared the sources from jitsi and jitsi-android which we
used to
sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown,
already
changed.

That looks very good and is probably the blueprint for further
changes.

- net.java.sip.communicator.impl.credentialsstorage a dialog is
shown

Similar to the certificate service?

Yep, already fixed.

- net.java.sip.communicator.impl.dns to move the config form in
separate
bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

-

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,

using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService
needs to
be implemented differently for Android?

- operation set desktop sharing was removed from jabber and sip
because of
java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set,
this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

-
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

- check why white board operation set is commented and will jabber

provider

bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

- in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
cause of
SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

- in SipStackSharing we have changed the path name of the factory to
org.jitsi.gov.nist, because of the renaming of jsip package, must
check

will

it work after adding the protocol bundle
- LoggingUtils separate the configuration form

-> To plugin

- NotificationManager - some image loading which we must remove in
order

to

use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for
Android
(because I'm guessing that not all events are needed there).

- UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one

Yana

has upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it
will

not

be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

- icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse jitsi

bundles

in android.
Also I'm currently testing a change in the build system in order to
speed

up

development/test process.

Comments and help are welcome :slight_smile:

Thanks
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi Yana,

This method takes as parameter drawable name and it doesn't use
image_path.properties. Correct parameter would be for example "call",
because we have call.png file in drawable resources.

Regards the paths they are used only in getImageInputStreamForPath and
we should threat it only as temporary solution for Jabber protocol
code. And the thing which might not work for you is probably jabber
icons. When I was implementing the resources service and account
status view I've missed to apply the patch. It changes
JabberStatusEnum in method getResourceAsStream(String name, Class<?>
clazz) to use the resources service not the URL class or class loader.
I'll fix that tomorrow.

Regards,
Pawel

···

On Mon, May 20, 2013 at 9:47 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Pawel,

On May 18, 2013, at 9:38 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Damian,

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hey Pawel,

I wanted to ask you do you know which of the following files is not used in
current android project:
config/defaults.properties
images/image_path.properties
images/images.properties
languages/resources.properties
sounds/sounds.properties

Thanks
damencho

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

Have you committed the whole implementation related to this image_path.properties mapping? I'm trying to use getImageInBytes method and it doesn't seem to work properly. I don't see any lookup to be done in image_path.properties in the latest code from svn (I'll switch to git tomorrow, but I thought that your changes should already be part of the last version on svn). Am I missing something?

Cheers,
Yana

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> wrote:

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile

On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images,
translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs >>>>> <ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from the
desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> >>>>>> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> >>>>>>> wrote:

I have compared the sources from jitsi and jitsi-android which we
used to
sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown,
already
changed.

That looks very good and is probably the blueprint for further
changes.

- net.java.sip.communicator.impl.credentialsstorage a dialog is
shown

Similar to the certificate service?

Yep, already fixed.

- net.java.sip.communicator.impl.dns to move the config form in
separate
bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

-

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,

using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService
needs to
be implemented differently for Android?

- operation set desktop sharing was removed from jabber and sip
because of
java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set,
this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

-
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

- check why white board operation set is commented and will jabber

provider

bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

- in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
cause of
SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

- in SipStackSharing we have changed the path name of the factory to
org.jitsi.gov.nist, because of the renaming of jsip package, must
check

will

it work after adding the protocol bundle
- LoggingUtils separate the configuration form

-> To plugin

- NotificationManager - some image loading which we must remove in
order

to

use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for
Android
(because I'm guessing that not all events are needed there).

- UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one

Yana

has upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it
will

not

be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

- icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse jitsi

bundles

in android.
Also I'm currently testing a change in the build system in order to
speed

up

development/test process.

Comments and help are welcome :slight_smile:

Thanks
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Hi Pawel,

Hi Yana,

This method takes as parameter drawable name and it doesn't use
image_path.properties. Correct parameter would be for example "call",
because we have call.png file in drawable resources.

Oh, ok. I was hoping to use some utility classes that search for a string by the key in images.properties. I was thinking that images_path will give me some general mapping between the keys in images.properties and the images in android. I'll investigate the possibilities, what are the best ways of making such a mapping.

Regards the paths they are used only in getImageInputStreamForPath and
we should threat it only as temporary solution for Jabber protocol
code. And the thing which might not work for you is probably jabber
icons. When I was implementing the resources service and account
status view I've missed to apply the patch. It changes
JabberStatusEnum in method getResourceAsStream(String name, Class<?>
clazz) to use the resources service not the URL class or class loader.
I'll fix that tomorrow.

Ok, thanks.

Cheers,
Yana

···

On May 20, 2013, at 11:17 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Regards,
Pawel

On Mon, May 20, 2013 at 9:47 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Pawel,

On May 18, 2013, at 9:38 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Damian,

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hey Pawel,

I wanted to ask you do you know which of the following files is not used in
current android project:
config/defaults.properties
images/image_path.properties
images/images.properties
languages/resources.properties
sounds/sounds.properties

Thanks
damencho

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

Have you committed the whole implementation related to this image_path.properties mapping? I'm trying to use getImageInBytes method and it doesn't seem to work properly. I don't see any lookup to be done in image_path.properties in the latest code from svn (I'll switch to git tomorrow, but I thought that your changes should already be part of the last version on svn). Am I missing something?

Cheers,
Yana

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> wrote:

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile

On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images,
translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs >>>>>> <ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from the
desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> >>>>>>> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> >>>>>>>> wrote:

I have compared the sources from jitsi and jitsi-android which we
used to
sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown,
already
changed.

That looks very good and is probably the blueprint for further
changes.

- net.java.sip.communicator.impl.credentialsstorage a dialog is
shown

Similar to the certificate service?

Yep, already fixed.

- net.java.sip.communicator.impl.dns to move the config form in
separate
bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

-

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,

using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService
needs to
be implemented differently for Android?

- operation set desktop sharing was removed from jabber and sip
because of
java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set,
this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

-
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

- check why white board operation set is commented and will jabber

provider

bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

- in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
cause of
SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

- in SipStackSharing we have changed the path name of the factory to
org.jitsi.gov.nist, because of the renaming of jsip package, must
check

will

it work after adding the protocol bundle
- LoggingUtils separate the configuration form

-> To plugin

- NotificationManager - some image loading which we must remove in
order

to

use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for
Android
(because I'm guessing that not all events are needed there).

- UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one

Yana

has upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it
will

not

be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

- icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse jitsi

bundles

in android.
Also I'm currently testing a change in the build system in order to
speed

up

development/test process.

Comments and help are welcome :slight_smile:

Thanks
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Hi,

I've just added targets to match those that exist in Jitsi: make, rebuild
and run.
And now the initial compilation problem is gone and on change ant make run
will be enough to test.

Cheers
damencho

···

On Mon, May 20, 2013 at 6:24 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi devs,

the android project is ready and you can all check it out.
https://github.com/jitsi/jitsi-android
Currently only the specific android source is available and jitsi bundles
are in folder lib/bundles.
As in the old repository there is a need of some classes renaming, as the
jsip packages to avoid clashing with the one in android, the sasl stuff
in smack, and the core java packages missing in android as java.awt and
javax.swing.
The libs folder (which in android projects is by default used for
libraries) is created if missing and there are copied all the needed
libraries. The jars which will have packages renamed need to be copied
every time in libs folder, because of the compilation of the android
sources. And when all classes are available the rename can take place over
the class files and the jars.
There is a new task named "copy-jitsi-bundles" which will take care to
update all current bundles from the original sc-bundles folder. Later we
can make this automatic or just make those libs available for ivy.

I think the compile process is a little bit faster now cause the libs
folder used to be deleted and recreated every time which lead to pre-
dexing all jars, now this is done only for the changed files and those
that have packages renamed.

The only problem now is that I didn't managed to force libs reload after
coping. The problem is only on the first time the project is checkout and
the first compile fails as when started compiling, libs folder is missing
and empty. But after the first compile everything works just fine.

Ready for any questions or suggestions

Regards
damencho

On Sat, May 18, 2013 at 9:38 PM, Paweł Domas <pawel.domas@jitsi.org>wrote:

Hi Damian,

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> >> wrote:
> Hey Pawel,
>
> I wanted to ask you do you know which of the following files is not
used in
> current android project:
> config/defaults.properties
> images/image_path.properties
> images/images.properties
> languages/resources.properties
> sounds/sounds.properties
>
> Thanks
> damencho
>
>

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

> On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> >> wrote:
>>
>> Well it is the notification service who is using it. This is the
biggest
>> change left from the refactoring I'm currently doing.
>> Currently checking what is actually used there and will come up with
>> something on Monday and then it will be ready for the new repository.
>>
>> -- sent from my mobile
>>
>> On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:
>>>
>>> Yepp, thats clear. I was refering to its usage from within the
protocols.
>>>
>>> -- sent from my mobile
>>>
>>> Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :
>>>
>>> Hi Ingo,
>>>
>>> no this bundle contains all the resources, like sounds, images,
>>> translates ...
>>>
>>> Regards
>>> damencho
>>>
>>>
>>> On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs >> >>> <ingo@sip-communicator.org> wrote:
>>>>
>>>> Isn't this thing only used for settings-defaults? If so, we wanted to
>>>> move the default settings into the configurationService anyway...
>>>>
>>>> Ingo
>>>>
>>>> -- sent from my mobile
>>>>
>>>> Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit
:
>>>>
>>>> Hey Yana, Pawel,
>>>>
>>>> we also need to discuss and the defaultresourcepack bundle. Cause the
>>>> source code is the same but in android we do not need the resources
from the
>>>> desktop application.
>>>> Actually are we using that? Wasn't there a new resource service impl?
>>>>
>>>> Regards
>>>> damencho
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> >> >>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> more inline:
>>>>>
>>>>>
>>>>> On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> >> >>>>> wrote:
>>>>>>
>>>>>> > I have compared the sources from jitsi and jitsi-android which we
>>>>>> > used to
>>>>>> > sync and here is what I have in my todo list:
>>>>>> >
>>>>>> > - in net.java.sip.communicator.impl.certificate a dialog is
shown,
>>>>>> > already
>>>>>> > changed.
>>>>>>
>>>>>> That looks very good and is probably the blueprint for further
>>>>>> changes.
>>>>>>
>>>>>> > - net.java.sip.communicator.impl.credentialsstorage a dialog is
>>>>>> > shown
>>>>>>
>>>>>> Similar to the certificate service?
>>>>>
>>>>>
>>>>> Yep, already fixed.
>>>>>
>>>>>>
>>>>>>
>>>>>> > - net.java.sip.communicator.impl.dns to move the config form in
>>>>>> > separate
>>>>>> > bundle
>>>>>>
>>>>>> Yepp, into the plugin namespace.
>>>>>> I'm working on replacing the unbound native stuff and the config
will
>>>>>> also
>>>>>> change. For the time being, I think you could just leave out the
>>>>>> complete
>>>>>> dns impl package.
>>>>>
>>>>>
>>>>> Also done that.
>>>>>
>>>>>>
>>>>>>
>>>>>> > -
>>>>>>
>>>>>>
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
>>>>>> > using java.awt.Toolkit use reflection to load it.
>>>>>>
>>>>>> Not sure, but I'd have guessed that the whole NotificationService
>>>>>> needs to
>>>>>> be implemented differently for Android?
>>>>>>
>>>>>> > - operation set desktop sharing was removed from jabber and sip
>>>>>> > because of
>>>>>> > java.awt.event.MouseEvent and java.awt.event.KeyEvent
>>>>>>
>>>>>> Not sure how this would work out for Android, but if some classes
in a
>>>>>> jar
>>>>>> wouldn't be available on the desktop, it wouldn't matter as long as
>>>>>> they're
>>>>>> not called. So as long as it isn't registered as an operation set,
>>>>>> this
>>>>>> shouldn't matter.
>>>>>
>>>>>
>>>>> Well loading some classes is failing currently cause of missing
classes
>>>>> but I'm currently on it.
>>>>>
>>>>>>
>>>>>>
>>>>>> > -
>>>>>> >
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
>>>>>> > sasl mechanisum does not compile in android
>>>>>>
>>>>>> Smack for Android seems to import
>>>>>> org.apache.harmony.javax.security.sasl.*
>>>>>> I'm wondering if we still really need our own modified SaslMd5
thing.
>>>>>> If we
>>>>>> do, loading it conditionally on the desktop or through reflection
>>>>>> should be
>>>>>> possible.
>>>>>
>>>>>
>>>>> Well it is used for some buggy xmpp servers ... well I'm also not
sure
>>>>> how to handle it,
>>>>> maybe turn it off and enable it on demand with prop.
>>>>>
>>>>>>
>>>>>>
>>>>>> > - check why white board operation set is commented and will
jabber
>>>>>> provider
>>>>>> > bundle will normally operation under android with it
>>>>>>
>>>>>> I thought we dropped support for that long ago? Why not completely
>>>>>> remove
>>>>>> the code?
>>>>>>
>>>>>> > - in ProtocolProviderServiceJabberImpl we are pre-configuring
some
>>>>>> > smack
>>>>>> > services as they are normally loaded from the jar file.
>>>>>>
>>>>>> Could that be done somewhere outside of the PPS, or maybe by
>>>>>> subclassing it?
>>>>>
>>>>>
>>>>> Yep I'm currently integrating protocol bundles and will test it
(code
>>>>> running only
>>>>> under android).
>>>>>
>>>>>>
>>>>>>
>>>>>> > - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
>>>>>> > cause of
>>>>>> > SSLSocketFactory
>>>>>>
>>>>>> Um, why? It should be there...
>>>>>>
>>>>>>
http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
>>>>>> tory.html
>>>>>> Are we using some methods/constructors that are not yet there?
>>>>>> OTOH: we have a // TODO: move to HttpUtil.
>>>>>> I don't know what API level we want to support, but at some point
>>>>>> Android
>>>>>> decided to kind of drop support for httpcomponents and suggesting
some
>>>>>> other
>>>>>> method for HTTP requests (sorry, don't remember the class name)
>>>>>
>>>>>
>>>>> Well the version differ, I currently get this error:
>>>>> 05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
>>>>> org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from
method
>>>>>
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
>>>>> 05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve
direct
>>>>> method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
>>>>>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V
>>>>>
>>>>> Thanks
>>>>> damencho
>>>>>
>>>>>>
>>>>>> > - in SipStackSharing we have changed the path name of the
factory to
>>>>>> > org.jitsi.gov.nist, because of the renaming of jsip package, must
>>>>>> > check
>>>>>> will
>>>>>> > it work after adding the protocol bundle
>>>>>> > - LoggingUtils separate the configuration form
>>>>>>
>>>>>> -> To plugin
>>>>>>
>>>>>> > - NotificationManager - some image loading which we must remove
in
>>>>>> > order
>>>>>> to
>>>>>> > use the plugin in android
>>>>>>
>>>>>> The NM is a complex beast. I'm wondering if we could split it up
into
>>>>>> multiple classes or even provide a different implementation for
>>>>>> Android
>>>>>> (because I'm guessing that not all events are needed there).
>>>>>>
>>>>>> > - UIContact and UIGroup use SIPCommButton (from desktoputil) -
this
>>>>>> > one
>>>>>> Yana
>>>>>> > has upcoming change which will fix it
>>>>>> > - service.httputil.HttpUtils - doesn't compile in android, using
it
>>>>>> > will
>>>>>> not
>>>>>> > be possible
>>>>>>
>>>>>> I'm wondering why (because Apache HttpClient should be available),
but
>>>>>> otherwise same as with the XCAP stuff.
>>>>>>
>>>>>> > - icon in FileUtils, maybe separate as service
>>>>>>
>>>>>> Move the whole FileUtils into impl.gui.utils? It seems it's not
used
>>>>>> outside
>>>>>> of impl.gui.
>>>>>>
>>>>>> > - android's UtilActivator adds JavaUtilLoggingConfig
>>>>>> >
>>>>>> > This are the notes and changes we need to do in order to reuse
jitsi
>>>>>> bundles
>>>>>> > in android.
>>>>>> > Also I'm currently testing a change in the build system in order
to
>>>>>> > speed
>>>>>> up
>>>>>> > development/test process.
>>>>>> >
>>>>>> > Comments and help are welcome :slight_smile:
>>>>>> >
>>>>>> > Thanks
>>>>>> > damencho
>>>>>>
>>>>>> Ingo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev@jitsi.org
>>>>>> Unsubscribe instructions and other list options:
>>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hi Pawel,

Hi Yana,

This method takes as parameter drawable name and it doesn't use
image_path.properties. Correct parameter would be for example "call",
because we have call.png file in drawable resources.

Oh, ok. I was hoping to use some utility classes that search for a string by the key in images.properties. I was thinking that images_path will give me some general mapping between the keys in images.properties and the images in android. I'll investigate the possibilities, what are the best ways of making such a mapping.

Hm, yes images.properties should map between the keys and images in
android. I'll change it that it will first lookup images.properties
for mapping.

···

On Mon, May 20, 2013 at 10:38 PM, Yana Stamcheva <yana@jitsi.org> wrote:

On May 20, 2013, at 11:17 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Regards the paths they are used only in getImageInputStreamForPath and
we should threat it only as temporary solution for Jabber protocol
code. And the thing which might not work for you is probably jabber
icons. When I was implementing the resources service and account
status view I've missed to apply the patch. It changes
JabberStatusEnum in method getResourceAsStream(String name, Class<?>
clazz) to use the resources service not the URL class or class loader.
I'll fix that tomorrow.

Ok, thanks.

Cheers,
Yana

Regards,
Pawel

On Mon, May 20, 2013 at 9:47 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Pawel,

On May 18, 2013, at 9:38 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Damian,

On Sat, May 18, 2013 at 6:55 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hey Pawel,

I wanted to ask you do you know which of the following files is not used in
current android project:
config/defaults.properties
images/image_path.properties
images/images.properties
languages/resources.properties
sounds/sounds.properties

Thanks
damencho

Those files are usefull to map to Android resources without
modyfications in Jitsi code.

config/defaults.properties are loaded as default config bundle by the
resources management service.

image_path.properties is used to map image paths to image resources
and will be removed once some code in jabber protocol will be changed
to ask for properties instead of paths.

Have you committed the whole implementation related to this image_path.properties mapping? I'm trying to use getImageInBytes method and it doesn't seem to work properly. I don't see any lookup to be done in image_path.properties in the latest code from svn (I'll switch to git tomorrow, but I thought that your changes should already be part of the last version on svn). Am I missing something?

Cheers,
Yana

languages/resources.properties - if needed I can remove it by copying
strings into Android's res/values/strings.xml

sounds/sounds.properties - are required to map sound names to sound
filenames in /res/raw folder

Regards,
Pawel

On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <damencho@jitsi.org> wrote:

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile

On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images,
translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs >>>>>>> <ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from the
desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> >>>>>>>> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> >>>>>>>>> wrote:

I have compared the sources from jitsi and jitsi-android which we
used to
sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown,
already
changed.

That looks very good and is probably the blueprint for further
changes.

- net.java.sip.communicator.impl.credentialsstorage a dialog is
shown

Similar to the certificate service?

Yep, already fixed.

- net.java.sip.communicator.impl.dns to move the config form in
separate
bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

-

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,

using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService
needs to
be implemented differently for Android?

- operation set desktop sharing was removed from jabber and sip
because of
java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set,
this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

-
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

- check why white board operation set is commented and will jabber

provider

bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

- in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
cause of
SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

- in SipStackSharing we have changed the path name of the factory to
org.jitsi.gov.nist, because of the renaming of jsip package, must
check

will

it work after adding the protocol bundle
- LoggingUtils separate the configuration form

-> To plugin

- NotificationManager - some image loading which we must remove in
order

to

use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for
Android
(because I'm guessing that not all events are needed there).

- UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one

Yana

has upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it
will

not

be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

- icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse jitsi

bundles

in android.
Also I'm currently testing a change in the build system in order to
speed

up

development/test process.

Comments and help are welcome :slight_smile:

Thanks
damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev