Develop Reference

Pushbot Android or IOS how to get a device to register for specific types of Messages

I have a question about PushBots(https://pushbots.com/). Sofar I have a basic Pushbot service working and all devices get notfications when they are sent out from the server.
However I would like to create types of messages which some devices may recieve and some may not. For example if it was a news application then I would like some devices to be able to register for Sports and Weather updates and receive message only for those topics.
I tried using TAGS to clasify messages but this did not, as all devices receive all messages regardless if it is using a TAG or not.
Does anyone have any idea how this can be done ?
Thanks !

in your app you need first to use the SDK to tag those devices before you are able to send messages to them.
Android Example:
Context appContext = getApplicationContext();
// tag the device with "tag"
Pushbots.getInstance().tag(appContext, "tag", null);
iOS Example
// Tag the device with "tag"
[[Pushbots getInstance] tag:#"tag"];
I hope this helps.

Sending Message to Application from Server- Connecting the GCM

I try to implement an application with Google Cloud Messaging from http://developer.android.com/guide/google/gcm/gs.html
Sender sender = new Sender(myApiKey);
Message message = new Message.Builder()
.collapseKey("1")
.timeToLive(3)
.delayWhileIdle(true)
.addData("message", "message is created at builder")
.build();
Result result = sender.send(message, reGid, 5);
System.out.println("result of message is "+result);
and consequently i get a message id and can see from console; but i want to show message at my device with a toast.
GCMIntentService.java:
#Override
protected void onMessage(Context arg0, Intent arg1) {
Log.i(TAG, "new message= ");
Toast.makeText(this, arg1.getStringExtra("message"), Toast.LENGTH_SHORT)
.show();
}
from GCM Advanced Topics:
When a 3rd-party server posts a message to GCM and receives a message ID back, it does not mean that the message was already delivered to the device. Rather, it means that it was accepted for delivery. What happens to the message after it is accepted depends on many factors.
In the best-case scenario, if the device is connected to GCM, the screen is on, and there are no throttling restrictions (see Throttling), the message will be delivered right away.
I can't understand what means "the device is connected to GCM".
How can device connect the GCM, connecting the internet and running the application from device isn't enough?

Connecting to GCM depends on a few things.
The device has registered to receive messages - GCMRegistrar.register
The device has a connection that allows the message to be delivered
The device meets certain requirements for installed software that allows the delivery of messages - namely the Google API's - Minimum SDK 2.2
UPDATE:
When you send the message you receive a status response which if everything is ok will mean a message id. The device that sent the message will not receive the message unless the message was sent to that device (using the devices registered GCM id). The devices registration id is return following the call from the device to register.
Please note that with GCM there is no guarantee that the message will be delivered. It is normally very reliable but should not be used if delivery is critical.
Yes onMessage() is the entry point for a new message being received by the device.

You should follow this link to get answers of your all questions :
http://www.androidhive.info/2012/10/android-push-notifications-using-google-cloud-messaging-gcm-php-and-mysql/
you just need to implement client and server. I have implemented on my own PC and got running code. I have already tested on PC to Mobile also.
Source Code is available. you just need to download and follow some easy steps.
I bet you will get your code running within 30 min.
Happy to Help !!

Android sipdemo timeout when making calls

Having a problem with the android sipdemo timing out when making calls. The native sip client on the phone has no issues calling, works perfect. Its When i initiate the call within the sipdemo i get a timeout in the logcat. timeout is set to standard of 30 seconds.. a local asterisk box is what its connecting to. Registers fine.

I'm having the same problem.
I traced packages in wireshark and here's what I found:
I register to SIP server in SipDemo
I register to SIP server on Desktop (using Ekiga)
I place a call in SipDemo to Ekiga.
INVITE message gets sent to Ekiga
Trying is sent from Ekiga to the server
Ringing is sent from Ekiga to SipDemo
I answer the call on Ekiga client
OK (with session description) is sent from Ekiga to SipDemo. This happens 11 times before Ekiga just gives up
BYE is sent from Ekiga client to SipDemo
Please note that OK is being sent 11 times before Ekiga just gives up and ends the call. This is why the call lasts just 30 seconds.
If you take a look at the RFC here:
http://www.ietf.org/rfc/rfc3261.txt section 13.3.1.4
you can see that the reason Ekiga is giving up on SipDemo client is because it never gets ACK back from SipDemo.
I believe this is android bug, but I can't imagine they could have missed something this basic in their SIP implementation.
In the next few days, I'll try to dig up some answers in android source code...
I'll try see what happens when establishing calls between 2 SipDemo applications. If it works, that means android just ignores ACK all together.
EDIT:
I just tried a call between 2 SipDemo clients. It sends OK 5 times and gives up on the OK, but does not end the call. Interesting behavior :)
EDIT2:
I dug up androids SIP implementation, and I found that ACK should get sent... Even logcat logs this, but I still see nothing in Wireshark. I thought maybe it gets blocked or something, so I ran Shark (like Wireshark for android) on the device, pulled the dump to my laptop, opened it up in Wireshark, and I don't see ACK anywhere. I even looked trough all packets... No filters, just in case I might be filtering it out. Anyways... Here's what I found in android code:
http://hi-android.info/src/com/android/server/sip/SipSessionGroup.java.html
class: SipSessionImpl
method: private boolean outgoingCall(EventObject evt)
in case Response.OK:
you can see this call:
mSipHelper.sendInviteAck(event, mDialog);
In SipHelper, method sendInviteAck, you can see:
if (DEBUG) Log.d(TAG, "send ACK: " + ack);
dialog.sendAck(ack);
Dialog is nist javax.sip, so I don't think there's a need to go further...
I see this message "send ACK" in my logcat when running the application
EDIT3:
I noticed that this issue occurs only with some SIP servers. I now tried opensips, and it works fine. I guess the problem I was having had to do with the server responding to androids keep-alive OPTIONS messages with 404 Not Found. Then, android tried to not use the server as soon as possible. Because of that, as soon as android got the address of its peer client, it tried to send a direct message, and failed

Hard to tell just like that. Try capturing the packages with wireshark, filter for the SIP protocol and have a look at what is sent over the network. Also try it with the native client and compare it to the sipdemo.
Another starting point is the log of your asterisk instance (systemlog)
If you can't figure it out yourself, post the results here.

Lost messages with aSmack

i'm using aSmack in my Android app to receive messages from my Desktop-Jabber-client. This works fine and even if my android phone is offline (after the connection was closed properly) it will receive the offline messages after the next login.
But when i enter the airplane-mode on the phone or shutdown the phone so that the connection is abruptly closed (without calling disconnect() on the Connection-object) the phone stays "online" in the contact-list of my Desktop-Jabber-client for a while and i can send messages to it. However these messages never arrive. Even though the phone logs in to the server again. These messages are lost.
Does anyone know how to fix this issue? Losing messages in a chat is not an option. :)
EDIT: Added Test-Code
BroadcastReceiver: http://pastebin.com/cFLzGXgy
Service: http://pastebin.com/wLpQCQfT
The first one is a BroadcastReceiver starting the service (second URL) each time the phone is connected to a network.
PS: This is only a test-code! You must change the server/username/password if you want to use/test it.

You can try to send delivered message from client b to client A when the message arrival. The problem is if the client A is offline (no connection break) the delivered confirm don't send until the user receives the message and the client B can't re-send the message.

you can try to send acknowledgement of receiving the message using Smackx Message Events
this will assure the message is delivered else you take corrective action.

this problem occurs when your connection broke.
You need "Stream Management" XEP-198 enabled connections to achieve this messages. refer to this blog : http://op-co.de/blog/posts/XEP-0198/ Basically it allows for stanza acknowledgement and stream resumption, which is exactly what you want to do in case.so you should wait till smack will 4.1 release.

Doing something just BEFORE wifi disconnection

I understand that on a wifi network there are sudden disconnections which prevent me from sending messages to my server.
But sometimes there's still one last chance before the disconnection, for example if the signal is low or the user is trying to turn off the wifi. On those occasions I would like to send a logout message to my server.
How do I detect disconnections like those?
I tried to retrieve changes of connectivity by registering a broadcast listener:
registerReceiver(this,new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION));
...
public void onReceive(Context context, Intent intent) {
NetworkInfo info = intent.getParcelableExtra(ConnectivityManager.EXTRA_NETWORK_INFO);
if( (info.getState()== State.DISCONNECTING) && (info.getType() == ConnectivityManager.TYPE_WIFI) ) {
//send logout
}
But it looks like at that time it's already too late. My logout message doesn't go through.
Is there a better way?
[Update 1]
I also tried:
if( (info.getDetailedState()== DetailedState.DISCONNECTING) && connectionTypeOK ) {
[Update 2 - SOLUTION]
The solution is, as stated below, using a combination of receiving the RSSI_CHANGED_ACTION and WIFI_STATE_CHANGED_ACTION broadcasts to monitor the signal strength and the WIFI_STATE_DISABLING events respectively. When this happens, I send my logout request. This works exactly as I needed. Thanks!!

You could try to implement a variable "heartbeat" function, by using WifiManager to detect changes in signal strength. Here you can find some related code, btw.
Now, once you receive a RSSI_CHANGED notification, according to the corresponding signal strength, you will update the frequency of your app's "heartbeats" to the server: if the signal is strong, you will only need to notify the server infrequently that the app is alive. Once the signal becomes week, however, just like adrenaline kicking in for a real live being, so should your app notify the server more frequently. If the signal's strength recovers, you'll send a specific message to let the server know everything is all right again; if, however, the server does not receive this message in a certain period of time and the "heartbeat" stops - your app ceases notifications for that amount of time - then the server logs it out until receiving from it again.

If you're based on TCP connections, the server should know when a session disconnects unexpectedly - it will get an RST or FIN packet, depending on the router configuration between the client and server.
There's no need to do anything from the client's point of view - TCP connections are designed so you can know when they're interrupted.

Why don't you have the server regularly ping the client, at certain intervals, and just log out if it doesn't get a response? Trying to make this happen through client side will be cumbersome.

A better way is not to have sessions at all, if possible.
Why is it a problem if the user doesn't log out?

Maybe this is a long shot.. but why don't you use Google push notifications to start an activity if wifi is on. That would tell the server that the phone is "online". If that doesn't happen in X seconds or 1 minute ou whatever, redirect it to somewhere else.

I would implement a handler on the server that handles when the client is not able to receive a message. After each message the phone could send a message back to the server saying it successfully received the message.

are you looking for a good way for users to send / receive data after a disconnection?
HTML5 has a local storage (with a good file size too) so if a user is attempting a huge form, you first save it locally and then attempt to send it to server. if failed when the user loads the page again, you can first check if the file has some content, and if so, you can send that data, clear the content and proceed accordingly.
may be this will help you out http://www.html5rocks.com/tutorials/appcache/beginner/
or look at the local storage tutorial: http://www.youtube.com/watch?v=h0uZIljjElo
using this you could save frequent status data and modify it on the fly.
and Android should support HTML5 too.