Develop Reference

Should we use GCM (or new FCM) with openfire for offline pushnotification messages?

It seams like to work with chat application, using openfire and smack there can be two ways below,
First Way
Smack makes a connection with the openfire server and it can receive and send updates to the server as long as its connected to the openfire server. In case its not connected, theres a plugin on openfire which keeps the messages offline, and send them once the client is connected again.
In this scenario to receive all messages,
1.1 Device should only disconnected from the openfire in case if it don’t have internet.
1.2 User is sign out
1.3 Device is offline
If connection goes disconnected with the server in any other case this cause messages loss. Currently application is working with this architecture.
Problems with this method:
The major problem for this is if due to any crash, or problem application gets completely killed, and its not alarm manager task also gets killed. App didn’t restart until the application opens again.
Second problem with this is, its consuming battery due to continuous process
On updated OS application goes in deep sleep, doze mode, ulta power save mode, background
Second Way
2.Smack makes a connection with the openfire server and it can receive and send updates to the server as long as its connected to the openfire server until the application is in foreground. As soon as this goes in background the application will completely disconnect from the server. In this case as application is offline openfire have to send all the messages to the Firebase server, same application listens for the firebase notifications and when it receives the notification from firebase it reconnects to the openfire and gets the message and display or shows the message directly from firebase (in this case this record goes to the firebase server as well). Application receives that notification from the gcm and then need to manage in application about message delivery etc.
Problems
Disconnect from server when app goes in backgound, handle its usecases as app is in background for long time or not. Is app goes in background to select any file and use cases like this.
This makes the code and application very compelex and need to manage multiple servers as well.
There can also be more security breaches as i don't want to share my application messages data with any third party.
My Questions
Which way is better, secure and more reliable to use?
My application is working with way 1, should i switch to second way ?
what can be possible reasons to make sure that app stays connected in each and every way? and it consumes less batter as well?

1- Which way is better, secure and more reliable to use?
A: Second Way
2- My application is working with way 1, should i switch to second way ?
A: You should but obviously that would require Openfire skills to develop a plugin which will route messages to FCM.
3- what can be possible reasons to make sure that app stays connected in each and every way? and it consumes less batter as well?
A: Simply said, if we reduce XMPP traffic, processing power can be saved and as a result reduction in battery consumption. But obviously for a chat application, that won't be the option. So for keeping the application interactive and battery friendly you should disconnect XMPP when app goes to background and rely on Push notifications (integration on server side).

How to notify the user about received GTalk chats when the app is not running

I implemented a chat client using GTalk servers and (a)Smack library. So far so good. Now, what I can't wrap my head around is how to notify the user of received chats when the app is closed, the same way all other chat apps do. I was reading into push notifications but all examples I find have a server component as well, which I obviously don't since my app is just a client for GTalk.
Should I be using GCM and implement the server side for this? Should I instead attempt to start a service that will listen for incoming messages at boot time (similar to this example)?

Service is definitely the way to go, you can keep it running so that your XMPP connection remains open.
From the server you can receive the messages and through a Broadcast Receiver you can show your notification if the app is closed, when it's opened you disable the previous Broadcast Receiver and you register a new one to manage messages in your activity for example.
This is pretty much my implementation.
Thumbs up appreciated!
Enjoy

You should use an Android Service that holds the XMPPConnection.
See also:
- aSmack as a service
- https://github.com/Flowdalic/asmack/wiki/Should-applications-using-aSmack-use-foreground-Services%3F

You already have service that listens for messages, maintain network connection, etc., and it is Google Messaging Service. You want to reinvent the wheel, and duplicate existing functionality. It makes sense when you are using device without Google or other vendor services, but on typical device your service will be co-exist with Google (Amazon, Nokia) one, and maintaining multiple network connections will do much more cpu wakeups, wasting memory and that will cause battery drain.
So, using GCM/GMS is a must. Maybe fallback to self-made service will help you on the device without GCM.
Note about "GTalk client". Your application can not be full-featured GTalk client: Google Talk was a part of Google Platform (now rebranded as Hangouts). It uses many Google proprietary XMPP extensions, which you can't use from third-party client: you don't have access to message history/sync, groupchats, you can't register device in GCM for GTalk notifications, voice/video features are only partially accessible. And with GTalk deprecation in favour of Hangouts - you lost basic XMPP compatibility too and don't have modern API at all.
So, if you want to build messaging/voip application, you should have your own server, with own users database, authentication (your app still be able to authenticate users as Google users and import their contacts too), messaging storage and sync, and of course your messaging server should register users in GCM and forward messages to Google services when your client app is not connected.
There are some commercial platforms (like Parse, but I have not tested it) which gives you that "third-party server component" and SDK you should plug in to your client app and they will care about all "server-side" part of your project, including GCM.

Android Client Always Approachable From Web Server

In my first deployment my Android Application maintains throughout its execution (from power on until the device is turned off) a socket with the Web Server and in a Background Service await messages from the server.
Now I was wondering if you can do the same without having a Socket open all the time.
Is there an alternative way?

yes.
It's called Google Cloud Messaging (aka. GCM)
http://developer.android.com/google/gcm/index.html
it's quite straight forward to implement and you won't kill your devices battery,

push notifications on android

I have already implemented a push notification system for the android. My system works as following: From my server I communicate through the Http protocol with the google servers. Then the google servers are sending the notification to the mobiles. So, I was wondering if there are any alternatives ways to implement this functionality. However, I want something which will be reliable.
P.S. I would like to hear opinions from people that they implement something similar.

Not sure why you're looking for something else, if you've already got it working through the Google servers, but a good system to send push notifications easily is Urban Airship.

I was working with some Chinese tablets that could not receive android push notifs (very annoying). I had to implement a Comet like system on android.
Basically, on the android device, I created a service which essentially polled a URL. But since polling is very battery intensive, I used a push technique called long-polling. I had the Android http client set a very long timeout. I then on the server side had the server hold the connection open also for a very long time. What would end up happening is that as soon as a message had to be passed, the connection would finish, and the android device would get the message immediately. This is just an additional method of "push" technology.
The only other option not discussed here is a persistant TCP/IP connection. This can be very dicey because Android could kill the service at will, and it can be somewhat battery intensive as well.
From my experience, GCM is the best method out there, and I wish there was something as good as it available for iOS Devices!

How does a push notification system works like on Y! Mail app?

I installed today from Market, the Yahoo Mail application and I was reading it offers push message notification technique. Indeed it works, as I got exactly the same moment the alert on my desktop computer and my mobile mail client.
How is it accomplished?

There already is another question discussing how to implement push notification without the cloud to device messaging in older system.
There are several frameworks that give you push abillity. They all require a running a small background thread that is polling a server at a very short interval(Bad for data rate and battery) or keep an open connection to a server that is kept alive somehow and the client is notified every time a new message is waiting on the server.
Have a look at the question and maybe choose on of the mentioned frameworks, the frameworks will reuse the same service for all applications that are installed on the phone using the same framework and therefore save battery and general system usage.

Soon, you will be able to use the Cloud-to-Device Messaging (C2DM) system, though it will require Android 2.2 or higher. You might also want to watch the Google I|O 2010 conference presentation on it, which gives a few clues as to how they implemented it.

Without installing the app, setting up my router to capture packets, and doing some packet inspection I can't tell you exactly how they do it. At the lowest level it's as simple as keeping an open TCP connect to a remote server and having the server sending the client a packet when it needs to do something. My educated guess on the specific way they are doing it is either with IMAP IDLE, or XMPP.