androidxmpp刪除好友

⑴ 如何實現android和伺服器長連接

這種功能實際上就是數據同步，同時要考慮手機本身、電量、網路流量等等限制因素，所以通常在移動端上有一下兩個解決方案: 1.一種是定時去server查詢數據，通常是使用HTTP協議來訪問web伺服器，稱Polling（輪詢）； 2.還有一種是移動端和伺服器建立長連接，使用XMPP長連接，稱Push（推送）。 從耗費的電量、流量和數據延遲性各方面來說，Push有明顯的優勢。但是使用Push的缺點是： 對於客戶端：實現和維護相對成本高，在移動無線網路下維護長連接，相對有一些技術上的開發難度。 對於伺服器：如何實現多核並發，cpu作業調度，數量龐大的長連接並發維護等技術，仍存在開發難點。 在講述Push方案的原理前，先了解一下移動無線網路的特點。 移動無線網路的特點： 因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊 GGSN（Gateway GPRS Support Node 網關GPRS支持結點）模塊就實現了NAT功能。 因為大部分移動無線網路運營商都是為了減少網關的NAT映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。 Push在Android平台上長連接的實現： 既然自己知道自己移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，咋們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。 這時候就要用到定時器，在android系統上，定時器通常有一下兩種： 1.java.util.Timer 2.android.app.AlarmManager 分析： Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。 AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。 RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC 來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz 晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概） 好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當自己用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。 下面簡單來說明其使用： 1.類似於Timer功能： //獲得鬧鍾管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //設置任務執行計劃 am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行 2.實現全局定時功能： //獲得鬧鍾管理器 AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE); //設置任務執行計劃 am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行 總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。

⑵ 在android開發xmpp中除了 roster.createentry方法之外還有什麼方法可以添加好友

主要用的類有：
Roster 可以理解為好友花名冊，提供創建刪除獲取列表等功能Roster.SubscriptionMode 這個在建立鏈接的時候使用，我的理解就是設置接收請求的模式，有三種，我們項目用的是SubscriptionMode.manual 也就是手動處理。
Presence 有關好友的推送消息，都是Presence包
Presence.Type 有7個Type，包含了好友上線下線、添加刪除好友及錯誤信息的Type
PacketFilter 過濾器，此功能中主要實現過濾出Presence
PacketListener 看名字就知道，Packet監聽，可以監聽到服務端發來的所有信息。因為xmpp發的包都是它的子類

另外還有一點，就是好友雙方對彼此的狀態，有網友總結如下：
none：是用戶和自己roster中的好友彼此不關心，既不想把自己的presence狀態告訴對方，也不願意收到對方presence更新消息
to：是關心roster中好友的presence狀態消息，而不將自己的消息告訴對方
from：是只關心，接受對方的狀態消息，而不將自己的消息告訴對方
both:即收取對方狀態更新，又將自己的更新告知對方
Remove :將對方幹掉，不再關心他的任何信息。

⑶ android如何實現消息推送有哪些方式各自的優缺點是什麼

【答案】：實現消息推送的方式有五種，分別是輪詢，SMS,C2DM,MQTT,XMPP最常使用的是XMPP, 我們做項目時採用的是XMPP協議
1.XMPP協議，它是一種基於XML的傳遞協議，具有很強的靈活性和可擴展性。它的特點是將復雜性從客戶端轉移到了伺服器端。GTalk、QQ、IM等都用這個協議。
2.輪詢:客戶端定時去服務端取或者保持一個長Socket，從本質講這個不叫推送， 而是去服務端拽數據。但是實現簡單，主要缺點：耗電,浪費用戶流量等
3.Google的C2DM，具體不細說，缺點，伺服器在國外，不是很穩定。
4.通過簡訊方式, 但是很難找到免費簡訊平台
5. MQTT協議, IBM提供的一種推送服務,不太靈活

⑷ Android怎麼實現類似微信，聊天室的功能，後端是php

後台好友分組，然後android端直接用xmpp協議往組中的每個好友發送消息，就可以實現聊天室的功能唄，後台不用幹啥，管理群組就夠了

⑸ android 即時通信。。如何實現

Android現在即時通訊（或者消息推送）有好幾個開源項目框架可以實現，可以使用XMPP來實現即時通信。

XMPP（Extensible Messageing and Presence Protocol：可擴展消息與存在協議）是目前主流的四種IM（IM：instant messaging,即時消息）協議之一，其他三種分別為：即時信息和空間協議(IMPP)、空間和即時信息協議(PRIM)、針對即時通訊和空間平衡擴充的進程開始協議SIP(SIMPLE)。

1. XMPP的前身是Jabber，一個開源形式組織產生的網路即時通信協議。XMPP目前被IETF國際標准組織完成了標准化工作。標准化的核心結果分為兩部分； 核心的XML流傳輸協議 基於XML流傳輸的即時通訊擴展應用 XMPP的核心XML流傳輸協議的定義使得XMPP能夠在一個比以往網路通信協議更規范的平台上。藉助於XML易於解析和閱讀的特性，使得XMPP的協議能夠非常漂亮。 XMPP的即時通訊擴展應用部分是根據IETF在這之前對即時通訊的一個抽象定義的，與其他業已得到廣泛使用的即時通訊協議，諸如AIM，QQ等有功能完整，完善等先進性。

2.XMPP中定義了三個角色，客戶端，伺服器，網關。通信能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網關承擔著與異構即時通信系統的互聯互通，異構系統可以包括SMS（簡訊），MSN，ICQ等。基本的網路形式是單客戶端通過TCP/IP連接到單伺服器，然後在之上傳輸XML。

3.傳輸的是與即時通訊相關的指令。在以前這些命令要麼用2進制的形式發送，要麼用純文本指令加空格加參數加換行苻的方式發送（比如MSN）。而XMPP傳輸的即時通訊指令的邏輯與以往相仿，只是協議的形式變成了XML格式的純文本。這不但使得解析容易了，人也容易閱讀了，方便了開發和查錯。而XMPP的核心部分就是一個在網路上分片斷發送XML的流協議。這個流協議是XMPP的即時通訊指令的傳遞基礎，也是一個非常重要的可以被進一步利用的網路基礎協議。

⑹ android消息推送GCM、XMPP、MQTT三種方案的優劣，越仔細越好，有具體分析更好！

⑺ android實現聊天功能是怎麼做到的

1、使用網路技術：通過對TCP/IP協議的支持，搭建TCP/IP客戶端/服務端通信系統，由服務端負責接收發送消息，客戶端負責發送消息。

2、利用XMPP技術：XMPP（Extensible Messaging and Presence Protocol）是一種可擴展的即時消息和存在協議，XMPP可以實現多用戶實時聊天，也可以實現多種客戶端的消息交互功能。

3、 利用HTTP協議：HTTP協議是多用戶聊天室的主要技術手段，在HTTP協議支持的客戶端/伺服器結構模型中，客戶端發送消息到伺服器，伺服器再將消息轉發給客戶端，實現多用戶聊天室。