I wanted to ask you do you know which of the following files is not used in
current android project:
On Sat, May 18, 2013 at 7:45 PM, Damian Minkov <email@example.com> 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" <firstname.lastname@example.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" <email@example.com> a écrit :
no this bundle contains all the resources, like sounds, images,
On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs < >> firstname.lastname@example.org> wrote:
Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...
-- sent from my mobile
Le 18.05.2013 à 14:31, "Damian Minkov" <email@example.com> 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?
On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <firstname.lastname@example.org>wrote:
On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <email@example.com>wrote:
> I have compared the sources from jitsi and jitsi-android which we
> sync and here is what I have in my todo list:
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
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
Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
change. For the time being, I think you could just leave out the
dns impl package.
Also done that.
> using java.awt.Toolkit use reflection to load it.
Not sure, but I'd have guessed that the whole NotificationService
be implemented differently for Android?
> - operation set desktop sharing was removed from jabber and sip
> java.awt.event.MouseEvent and java.awt.event.KeyEvent
Not sure how this would work out for Android, but if some classes in a
wouldn't be available on the desktop, it wouldn't matter as long as
not called. So as long as it isn't registered as an operation set, this
Well loading some classes is failing currently cause of missing classes
but I'm currently on it.
> sasl mechanisum does not compile in android
Smack for Android seems to import
I'm wondering if we still really need our own modified SaslMd5 thing.
do, loading it conditionally on the desktop or through reflection
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
> bundle will normally operation under android with it
I thought we dropped support for that long ago? Why not completely
> - in ProtocolProviderServiceJabberImpl we are pre-configuring some
> services as they are normally loaded from the jar file.
Could that be done somewhere outside of the PPS, or maybe by
Yep I'm currently integrating protocol bundles and will test it (code
> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile
Um, why? It should be there...
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
decided to kind of drop support for httpcomponents and suggesting some
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
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form
-> To plugin
> - NotificationManager - some image loading which we must remove in
> 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
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it
> 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
> - android's UtilActivator adds JavaUtilLoggingConfig
> This are the notes and changes we need to do in order to reuse jitsi
> in android.
> Also I'm currently testing a change in the build system in order to
> development/test process.
> Comments and help are welcome