ConversationCard and UI are competing for headless server

[pedbg7]

Hi,

Again many thanks to your efforts and time!

After debugging your program a little bit, I find that the ConversationCard in the Hub and the Hg UI part are competing for the headless service at localhost port 27015.

First I open a conversation card in the hub but do not close it by swiping it to the right. Then I switch to the desktop and open the UI part. Now the UI part cannot establish a connection with the headless server, because the conversation card in the hub is still using the port. Finally, the UI part will keep trying to connecting to the headless server forever.

Do you happen to have a solution to this?

[amonchakai]

Hello again

I like the fact you saw, and understood this issue :-)

I don't really have a solution for it yet. The obvious solution would be to add a second port letting both the UI from the Hub and from the App to connect to the headless. But it adds some further complexity: I would need to file which UI asked what to send an appropriate answer to the right one.

So I have been trying to address it differently and disconnect the UI from the headless as fast as possible.

As for the main UI, I detect when the app is minimized and disconnect the UI from the headless service when that happens. This method also address the issue of opening a card in the hub: when you do that, the main app also receive the "application minimized" signal.

The issue is on the other direction: if you open the app in the Hub, I still do not detect if the user is still looking at the hub or if he left it opened and moved to the application.

But that is the direction I would like to go as I am afraid to add too much bugs by adding another port for exchanging messages.

If I don't find the signal "the user is not looking at the hub", an alternative could be to have another port open, so one instance of the UI (the application) can contact the other instance of the UI (in the hub) and request to close the connection to the headless service.

So, yes, there is some solutions for this!

[pedbg7]

Hi!

Yes I agree with you. It will bring more complexity and bugs if you open another localhost port. It may consume more power as well.

I think you may open the main UI and switch to the right conversation when the user touches an item in the hub, instead of poping a conversation card. So we can always keep the connection between the headless service and the main UI. However, this is not the "Blackberry style".

As I notice, BBM solves this issue and responds to user interactions very quickly. Do you have any idea how they do this?

Finally, can I ask if you are a full time blackberry developer or you just do this for fun? I really hope there are much more developers like you! If you sell your app in Blackberry world I will buy for sure! :)

[amonchakai]

Hi!

I kinda like the card-based approach in the Hub, so I would like to keep it like that.

It is true, I am also slower than BBM to open the card, probably due to all the heavy components I have in it (WebView, ListView). BBM seems to also have them, so there is probably some optimization to be done on my side. Try to delay allocations and so on. On my passport, I don't suffer too much from it, so it was not really on my priority list.

As for the way they handle multiple connection to the headless, I don't really know. Maybe I should just ask them on the developer forum. There are some developers working for BlackBerry there.

But I would probably try to detect if the user is still on the Hub. There should be something, and I think that would be the easiest way.

Oh, and I just do that for fun. Mainly because I was really missing the synchronization of conversations with the server from google. So I felt I needed to do something about it!

And I don't think I will ever sell it, I like it free :)

However, I will probably add a donation option in a next release. But I will first fix some of my bugs.