專利名稱：文件發(fā)送、接收方法及裝置和文件傳輸方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種文件發(fā)送、接收方法及裝置和文件傳輸方法及系統(tǒng)。
背景技術(shù)：
藍(lán)牙技術(shù)是一種短距離傳輸語音和數(shù)據(jù)的無線通信技術(shù)，在大多數(shù)數(shù)字移動(dòng)設(shè)備中加入藍(lán)牙技術(shù)的芯片，可以取代傳統(tǒng)電子設(shè)備間的電纜，使個(gè)人數(shù)字處理器(PDA)，筆記本電腦，移動(dòng)電話間信息的無線傳輸成為可能。其中對(duì)象交換協(xié)議(Object Exchange，簡稱為OBEX)是一種簡單、高效的高層應(yīng)用協(xié)議。隨著手機(jī)和各種便攜式產(chǎn)品得到廣泛的應(yīng)用，可以通過OBEX協(xié)議的文件傳輸，可實(shí)現(xiàn)多種設(shè)備，如個(gè)人電腦(PC)機(jī)、PDA、筆記本、移動(dòng)終端的文件共享、應(yīng)用范圍相當(dāng)廣泛。在層次結(jié)構(gòu)的藍(lán)牙協(xié)議棧中，OBEX協(xié)議是一種面向應(yīng)用的會(huì)話層協(xié)議，圖1是根據(jù)相關(guān)技術(shù)的OBEX在藍(lán)牙協(xié)議棧中的位置示意圖，其應(yīng)用原理請(qǐng)參見圖1，OBEX協(xié)議運(yùn)行于藍(lán)牙協(xié)議的頂部，支持文件傳輸，對(duì)象“推”操作，同步等多種應(yīng)用。OBEX協(xié)議能夠提供設(shè)備間簡單易行的對(duì)象交換手段。可交換的對(duì)象可以是文件、圖像，也可以是應(yīng)用支持的任何數(shù)據(jù)單位，對(duì)象交換采用了基于查詢-應(yīng)答方式的主設(shè)備/從設(shè)備(Client/Server)模式，任意兩臺(tái)藍(lán)牙設(shè)備間都可以組成主從關(guān)系，主動(dòng)發(fā)起方式是主設(shè)備(Client)，被找到者是從設(shè)備(Server)。OBEX相關(guān)的過程包括連接建立(Connect)、連接斷開(Disconnect)、發(fā)文件 (Put)、接收文件(Get)、操作放棄(Abort)、設(shè)置路徑(Set Path)。OBEX協(xié)議涉及的對(duì)象交換包括文件和目錄的交換。在應(yīng)用過程中，Client客戶端能初始化各種請(qǐng)求，如發(fā)送和接收文件，瀏覽krver端對(duì)象，因此Client客戶端具備解釋 OBEX文件夾及其中文件的格式以及大小的能力Jerver端與Client客戶端相對(duì)應(yīng)，作為一種遠(yuǎn)程目標(biāo)設(shè)備，提供了對(duì)象交換的服務(wù)以及使用OBEX文件夾格式的瀏覽功能，Server端的只讀文件夾以及只讀文件，可以限制對(duì)象的發(fā)出以及文件/目錄的刪除與建立。目前，藍(lán)牙功能在人們?nèi)粘Ｊ褂檬謾C(jī)、PC機(jī)等終端時(shí)被用到的機(jī)會(huì)越來越頻繁，如文件傳輸、接聽電話、播放音視頻文件等。好友之間為了共享好玩好用的文件、軟件等，也經(jīng)常使用到藍(lán)牙。而目前的藍(lán)牙傳輸模式，是先傳輸文件，當(dāng)空間不足的時(shí)候才提示用戶，然后之前傳輸?shù)臄?shù)據(jù)都被清除，比如對(duì)方存儲(chǔ)空間為300M，在事先未知的情況下需要傳輸一個(gè)400M的文件給對(duì)方，當(dāng)傳輸了 300M的數(shù)據(jù)后，對(duì)方會(huì)提示空間不足，然后之前傳輸?shù)臄?shù)據(jù)被清除。針對(duì)相關(guān)技術(shù)中用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，目前尚未提出有效的解決方案。

發(fā)明內(nèi)容
4
本發(fā)明提供了一種文件發(fā)送、接收方法及裝置和文件傳輸方法及系統(tǒng)，以至少解決相關(guān)技術(shù)中的用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足， 使用不方便的問題。根據(jù)本發(fā)明的一個(gè)方面，提供了一種文件發(fā)送方法，應(yīng)用于藍(lán)牙傳輸，包括發(fā)送端確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端。優(yōu)選地，發(fā)送端將空間值發(fā)送至接收端包括發(fā)送端將空間值封裝到0ΒΧΕ_ ObjectAddHeader數(shù)據(jù)包中；發(fā)送端將0BXE_0bjectAddHeader數(shù)據(jù)包發(fā)送至接收端。根據(jù)本發(fā)明的另一個(gè)方面，提供了一種文件接收方法，應(yīng)用于藍(lán)牙傳輸，包括接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；接收端比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。優(yōu)選地，接收端根據(jù)比較結(jié)果確定是否接收待傳輸文件，包括在接收端本地的存儲(chǔ)空間的大小不小于空間值時(shí)，接收端判斷本地未被占用的存儲(chǔ)空間的大小是否不小于空間值；若是，接收端進(jìn)行藍(lán)牙傳輸，接收待傳輸文件；若否，接收端刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用，直至未被占用的存儲(chǔ)空間的大小不小于空間值。優(yōu)選地，接收端刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用，包括接收端提示用戶本地沒有足夠的存儲(chǔ)空間進(jìn)行本次藍(lán)牙傳輸；接收端接收用戶輸入的刪除指示，其中，刪除指示用于指示刪除的文件或應(yīng)用；接收端根據(jù)刪除指示刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用。優(yōu)選地，接收端根據(jù)比較結(jié)果確定是否接收待傳輸文件，包括當(dāng)接收端本地的存儲(chǔ)空間的大小小于空間值時(shí)，接收端提示用戶當(dāng)前空間無法進(jìn)行待傳輸文件的藍(lán)牙傳輸。優(yōu)選地，接收端確定本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，包括接收端接收封裝有空間值的0BXE_0b jectAddHeader數(shù)據(jù)包；接收端解析0BXE_0b jectAddHeader數(shù)據(jù)包，獲取空間值。根據(jù)本發(fā)明的再一個(gè)方面，提供了一種文件傳輸方法，應(yīng)用于藍(lán)牙傳輸，包括發(fā)送端確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大?。话l(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端；接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值；接收端比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。根據(jù)本發(fā)明的一個(gè)方面，提供了一種文件發(fā)送裝置，應(yīng)用于藍(lán)牙傳輸，包括確定模塊，用于確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大小；發(fā)送模塊，用于將待傳輸文件以及空間值均發(fā)送至接收端。根據(jù)本發(fā)明的另一個(gè)方面，提供了一種文件接收裝置，應(yīng)用于藍(lán)牙傳輸，包括接收模塊，用于接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大小；比較模塊，用于比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。根據(jù)本發(fā)明的再一個(gè)方面，提供了一種文件傳輸系統(tǒng)，應(yīng)用于藍(lán)牙傳輸，包括發(fā)送端與接收端發(fā)送端用于確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大小； 將待傳輸文件以及空間值均發(fā)送至接收端；接收端用于確定本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。通過本發(fā)明，發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端，接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，獲知待傳輸文件的大小，進(jìn)而比較本地的存儲(chǔ)空間的大小與空間值，接收端可以根據(jù)比較結(jié)果確定是否接收待傳輸文件。即，發(fā)送端提前告知接收端待傳輸文件的大小，保證接收端在傳輸待傳輸文件前就能夠獲知待傳輸文件的大小， 進(jìn)而可以判斷出本地存儲(chǔ)空間是否足夠支持本次藍(lán)牙傳輸，解決了用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，提高了用戶體驗(yàn)。


此處所說明的附圖用來提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本申請(qǐng)的一部分，本發(fā)明的示意性實(shí)施例及其說明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定。在附圖中圖1是根據(jù)相關(guān)技術(shù)的OBEX在藍(lán)牙協(xié)議棧中的位置示意圖2是根據(jù)本發(fā)明實(shí)施例的文件發(fā)送方法的流程圖3是根據(jù)本發(fā)明實(shí)施例的文件接收方法的流程圖4是根據(jù)本發(fā)明實(shí)施例的文件傳輸方法的流程圖5是根據(jù)本發(fā)明實(shí)施例的藍(lán)牙發(fā)送端流程圖6是根據(jù)本發(fā)明實(shí)施例的藍(lán)牙接收端流程圖7是根據(jù)本發(fā)明實(shí)施例的header :0BEX_0bJectAddHeader數(shù)據(jù)包結(jié)構(gòu)圖
圖8是根據(jù)本發(fā)明實(shí)施例的發(fā)送端和接收端OBEX協(xié)議數(shù)據(jù)包流程圖9是根據(jù)本發(fā)明實(shí)施例的文件發(fā)送裝置的結(jié)構(gòu)框圖10是根據(jù)本發(fā)明實(shí)施例的文件接收裝置的結(jié)構(gòu)框圖11是根據(jù)本發(fā)明實(shí)施例的文件傳輸系統(tǒng)的結(jié)構(gòu)框圖。
具體實(shí)施例方式需要說明的是，在不沖突的情況下，本申請(qǐng)中的實(shí)施例及實(shí)施例中的特征可以相互組合。下面將參考附圖并結(jié)合實(shí)施例來詳細(xì)說明本發(fā)明。本發(fā)明提供了一種文件發(fā)送方法，圖2是根據(jù)本發(fā)明實(shí)施例的文件發(fā)送方法的流程圖，如圖2所示，包括如下的步驟S202至步驟S204。步驟S202，發(fā)送端確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大小。步驟S204，發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端。在本發(fā)明實(shí)施例中，發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端，S卩，發(fā)送端提前告知接收端待傳輸文件的大小，保證接收端在傳輸待傳輸文件前就能夠獲知待傳輸文件的大小，進(jìn)而可以判斷出本地存儲(chǔ)空間是否足夠支持本次藍(lán)牙傳輸。由此可見，本發(fā)明實(shí)施例能夠解決用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，提高了用戶體驗(yàn)。發(fā)送端將空間值發(fā)送至接收端可以有多種發(fā)送方式，例如，在發(fā)送端與接收端交互的信令或消息中攜帶空間值，或者，可以在發(fā)送端與接收端間傳輸?shù)臄?shù)據(jù)包中封裝該空間值，優(yōu)選地，可以使用0BXE_0bjeCtAddHeader數(shù)據(jù)包，即，發(fā)送端將空間值封裝到0ΒΧΕ_ ObjectAddHeader數(shù)據(jù)包中，之后，發(fā)送端將0BXE_0bjectAddHeader數(shù)據(jù)包發(fā)送至接收端， 從而完成空間值的發(fā)送。本發(fā)明還提供了一種文件接收方法，圖3是根據(jù)本發(fā)明實(shí)施例的文件接收方法的流程圖，如圖3所示，包括如下的步驟S302至步驟S304。步驟S302，接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大小。步驟S304，接收端比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。在本發(fā)明實(shí)施例中，接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，獲知待傳輸文件的大小，進(jìn)而比較本地的存儲(chǔ)空間的大小與空間值，接收端可以根據(jù)比較結(jié)果確定是否接收待傳輸文件。即，接收端在傳輸待傳輸文件前就能夠獲知待傳輸文件的大小，進(jìn)而可以判斷出本地存儲(chǔ)空間是否足夠支持本次藍(lán)牙傳輸。由此可見，本發(fā)明實(shí)施例能夠解決用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，提高了用戶體驗(yàn)。接收端根據(jù)步驟S304中的比較結(jié)果確定是否接收待傳輸文件，在接收端本地的存儲(chǔ)空間的大小不小于空間值時(shí)，接收端判斷本地未被占用的存儲(chǔ)空間的大小是否不小于空間值；若是，接收端進(jìn)行藍(lán)牙傳輸，接收待傳輸文件。若本地未被占用的存儲(chǔ)空間的大小小于空間值，接收端需要?jiǎng)h除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用，直至未被占用的存儲(chǔ)空間的大小不小于空間值。相關(guān)技術(shù)中使用的藍(lán)牙傳輸方式，在本地存儲(chǔ)空間不足時(shí)，也提及需要用戶先刪除一部分文件然后再重新傳輸，由于已存儲(chǔ)的文件較多，且每個(gè)文件占用的空間大小也不相同，因此，需要?jiǎng)h除哪些文件才能滿足接收對(duì)方文件需要對(duì)用戶也是一個(gè)比較困難的問題，為解決該技術(shù)問題，相關(guān)技術(shù)提供了一種解決方式用戶刪除一個(gè)文件之后需要再去查看一下手機(jī)的內(nèi)存空間，再與對(duì)方傳輸?shù)奈募M(jìn)行大小比對(duì)，如果空間不足的話還要去刪除其他文件，用戶會(huì)感覺到很不方便而且浪費(fèi)時(shí)間。因此，本發(fā)明實(shí)施例提供了另外一種解決方式，S卩，接收端刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用，刪除后接收端會(huì)自動(dòng)計(jì)算未被占用的存儲(chǔ)空間的大小，直至未被占用的存儲(chǔ)空間的大小不小于空間值，此時(shí)，接收端就能夠進(jìn)行藍(lán)牙傳輸，接收待傳輸文件，不需要再進(jìn)行刪除操作。為了避免刪除操作刪除有用的文件或應(yīng)用，例如，刪除了系統(tǒng)文件可能導(dǎo)致接收端無法進(jìn)行正常的操作，因此，接收端可以在提示用戶本地沒有足夠的存儲(chǔ)空間進(jìn)行本次藍(lán)牙傳輸，按照用戶輸入的刪除指示刪除文件或應(yīng)用，接收端接收用戶輸入的刪除指示，其中，刪除指示用于指示刪除的文件或應(yīng)用，進(jìn)而接收端根據(jù)刪除指示刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用。在應(yīng)用中，若當(dāng)接收端本地的存儲(chǔ)空間的大小小于空間值時(shí)，接收端不需要進(jìn)行任何操作，直接提示用戶當(dāng)前空間無法進(jìn)行待傳輸文件的藍(lán)牙傳輸即可。上文提及，發(fā)送端將空間值發(fā)送至接收端可以有多種發(fā)送方式，例如，在發(fā)送端與接收端交互的信令或消息中攜帶空間值，或者，可以在發(fā)送端與接收端間傳輸?shù)臄?shù)據(jù)包中封裝該空間值，優(yōu)選地，可以使用0BXE_0bjeCtAddHeader數(shù)據(jù)包，對(duì)應(yīng)的，接收端可以接收封裝有空間值的0BXE_0bjeCtAddHeader數(shù)據(jù)包。進(jìn)一步，接收端解析0ΒΧΕ_ ObjectAddHeader數(shù)據(jù)包，獲取空間值。本發(fā)明實(shí)施例還提供了一種文件傳輸方法，圖4是根據(jù)本發(fā)明實(shí)施例的文件傳輸方法的流程圖，如圖4所示，包括如下的步驟S402至步驟S408。步驟S402，發(fā)送端確定空間值，其中，該空間值為待傳輸文件占用的存儲(chǔ)空間的大步驟S404，發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端。步驟S406，接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值。步驟S408，接收端比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。在本發(fā)明實(shí)施例中，發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端，接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，獲知待傳輸文件的大小，進(jìn)而比較本地的存儲(chǔ)空間的大小與空間值，接收端可以根據(jù)比較結(jié)果確定是否接收待傳輸文件。即，發(fā)送端提前告知接收端待傳輸文件的大小，保證接收端在傳輸待傳輸文件前就能夠獲知待傳輸文件的大小，進(jìn)而可以判斷出本地存儲(chǔ)空間是否足夠支持本次藍(lán)牙傳輸。由此可見，本發(fā)明實(shí)施例能夠解決用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，提高了用戶體驗(yàn)。采用本發(fā)明實(shí)施例提供的方法、裝置和系統(tǒng)，與相關(guān)技術(shù)相比，取得了明顯進(jìn)步， 能夠在文件通過藍(lán)牙接收前提前判斷空間是否滿足要求，避免了在接收了一段數(shù)據(jù)后由于空間不足導(dǎo)致浪費(fèi)，使用不便的問題。同時(shí)在空間不足的情況下，用戶可以直接進(jìn)入文件刪除或應(yīng)用卸載界面，刪除文件后自動(dòng)判斷空間是否滿足要求，免除用戶手動(dòng)計(jì)算空間大小的不便。下面將結(jié)合實(shí)例對(duì)本發(fā)明實(shí)施例的實(shí)現(xiàn)過程進(jìn)行詳細(xì)描述。流程部分包括以下幾個(gè)步驟1.發(fā)送端選擇文件發(fā)送，同時(shí)得到文件大小。2.發(fā)送端將發(fā)送文件大小放入0BEX_0bjeCtAddHeader數(shù)據(jù)包發(fā)送給接收端。3.接收端收到0BEX_0bjeCtAddHeader數(shù)據(jù)包后判斷容量是否足夠存儲(chǔ)待接收的文件。4.如果接收端判斷容量足夠，則根據(jù)OBEX協(xié)議接收文件數(shù)據(jù)包，如果接收端判斷容量不足，則提示用戶刪除部分文件以騰出部分空間供文件接收，用戶選擇清除文件則直接進(jìn)入文件選擇界面去選擇文件刪除，待空間足夠則進(jìn)入文件傳輸過程。5.關(guān)閉底層連接釋放資源。圖5是根據(jù)本發(fā)明實(shí)施例的藍(lán)牙發(fā)送端流程圖，如圖5所示，發(fā)送端進(jìn)行如下的處理，包括如下的步驟S501至步驟S509。步驟S501，選擇需要發(fā)送的文件。步驟S502，得到待發(fā)送文件大小。步驟S503，判斷藍(lán)牙是否打開。如果是，執(zhí)行步驟S504 ；如果否，執(zhí)行步驟S505。
步驟S504，搜索接收端，配對(duì)，連接。步驟S505，打開藍(lán)牙。步驟S506，調(diào)用 OBEX 初始化接口 0BEX_Init。步驟S507，向Header請(qǐng)求包格式中加入文件大小參數(shù)。步驟S508，向待發(fā)送隊(duì)列中加入Header。步驟S509，向接收端發(fā)送傳輸請(qǐng)求。圖6是根據(jù)本發(fā)明實(shí)施例的藍(lán)牙接收端流程圖，如圖6所示，接收端進(jìn)行如下的步驟S601至步驟S610。步驟S601，接收 0BEX_0bjectAddHeader 數(shù)據(jù)包。步驟S602，解析0BEX_0bjectAddHeader數(shù)據(jù)包，得到待接收文件大小。步驟S603，搜索配置文件，獲得剩余存儲(chǔ)空間大小值。步驟S604，比較傳輸文件與剩余存儲(chǔ)空間大小。步驟S605，判斷空間是否足夠。如果是，執(zhí)行步驟S606 ；如果否，執(zhí)行步驟S608。步驟S606，接收文件。步驟S607，判斷是否清理空間。如果是，執(zhí)行步驟S608 ；如果否，執(zhí)行步驟S610。步驟S608，自動(dòng)將可刪除的文件按文件大小排列，且顯示文件大小值以及需要的
清理的空間值。步驟S609，刪除文件后，空間足夠，接收文件。步驟S610，結(jié)束文件傳輸。根據(jù)圖1所示的OBEX協(xié)議進(jìn)行如下處理1)將待發(fā)送的文件大小封裝到0BEX_0bjectAddHeader數(shù)據(jù)包中。2)處理文件發(fā)送和接收流程，過程如圖8所示，在藍(lán)牙協(xié)議棧中所處的位置如圖1 所示。圖7是根據(jù)本發(fā)明實(shí)施例的header :0BEX_0bjectAddHeader數(shù)據(jù)包結(jié)構(gòu)圖，如圖 7所示，0BEX_0bjectAddHeader數(shù)據(jù)包具有了如下功能。1)封裝了發(fā)送文件大小參數(shù)。2)供接收端解析待接收文件大小。3)包含應(yīng)答碼，供接收端反饋給發(fā)送端用來進(jìn)行文件傳輸。圖8是根據(jù)本發(fā)明實(shí)施例的發(fā)送端和接收端OBEX協(xié)議數(shù)據(jù)包流程圖，現(xiàn)結(jié)合圖8 舉例說明，如圖8所示，包括如下的步驟S801至步驟S816。步驟S801，OBEX 初始化接口 0BEX_Init。步驟S802，調(diào)用藍(lán)牙傳輸方式。步驟S803，向header :0BEX_0bjectAddHeader中加入發(fā)送包長度等信息。步驟S804，向接收端發(fā)送 header :0BEX_0bjectAddHeader。步驟S805，接收端解析header數(shù)據(jù)結(jié)構(gòu)。步驟S806，判斷終端所有的存儲(chǔ)空間(包括已用空間和空閑空間)是否滿足要求， 如果是，執(zhí)行步驟S807 ；如果否，執(zhí)行步驟S813。步驟S807，進(jìn)行傳輸。步驟S808，判斷傳輸是否結(jié)束，如果是，執(zhí)行步驟S809 ；如果否，執(zhí)行步驟S810。
步驟S809，當(dāng)傳輸結(jié)束，關(guān)閉底層連接釋放資源0BEX_Clrarup。步驟S810，發(fā)送數(shù)據(jù) 0BEX_Request。步驟S811，處理服務(wù)器響應(yīng)0BEX_Request。步驟S812，調(diào)用應(yīng)用層的事件處理函數(shù)。步驟S813，終端總存儲(chǔ)空間大小是否滿足。如果是，執(zhí)行步驟S814 ；如果否，執(zhí)行步驟S816。步驟S814，判斷用戶是否清理存儲(chǔ)空間，如果是，執(zhí)行步驟S815 ；如果否，執(zhí)行步驟 S816。步驟S815，清理空間。步驟S816，結(jié)束整個(gè)傳輸程序。需要說明的是，在附圖的流程圖示出的步驟可以在諸如一組計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟。本發(fā)明實(shí)施例提供了一種文件發(fā)送裝置，該裝置可以用于實(shí)現(xiàn)上述文件發(fā)送方法。圖9是根據(jù)本發(fā)明實(shí)施例的文件發(fā)送裝置的結(jié)構(gòu)框圖，文件發(fā)送裝置包括確定模塊92 和發(fā)送模塊94。確定模塊92，用于確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；發(fā)送模塊94，連接至確定模塊92，用于將待傳輸文件以及空間值均發(fā)送至接收端。本發(fā)明實(shí)施例提供了一種文件接收裝置，該裝置可以用于實(shí)現(xiàn)上述文件接收方法。圖10是根據(jù)本發(fā)明實(shí)施例的文件接收裝置的結(jié)構(gòu)框圖，包括接收模塊102和比較模塊 104。接收模塊102，用于接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；比較模塊104，連接至接收模塊102，用于比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。本發(fā)明實(shí)施例提供了一種文件傳輸系統(tǒng)，該系統(tǒng)可以用于實(shí)現(xiàn)上述文件傳輸方法。圖11是根據(jù)本發(fā)明實(shí)施例的文件傳輸系統(tǒng)的結(jié)構(gòu)框圖，包括發(fā)送端112和接收端114。 發(fā)送端112用于確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；將待傳輸文件以及空間值均發(fā)送至接收端114 ；接收端114用于確定本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。綜上所述，根據(jù)本發(fā)明的上述實(shí)施例，提供了一種文件發(fā)送、接收方法及裝置和文件傳輸方法及系統(tǒng)。通過本發(fā)明，發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端，接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，獲知待傳輸文件的大小，進(jìn)而比較本地的存儲(chǔ)空間的大小與空間值，接收端可以根據(jù)比較結(jié)果確定是否接收待傳輸文件。即，發(fā)送端提前告知接收端待傳輸文件的大小，保證接收端在傳輸待傳輸文件前就能夠獲知待傳輸文件的大小，進(jìn)而可以判斷出本地存儲(chǔ)空間是否足夠支持本次藍(lán)牙傳輸，解決了用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，提高了用戶體驗(yàn)。需要說明的是，裝置實(shí)施例中描述的文件發(fā)送裝置、文件接收裝置和文件傳輸系統(tǒng)對(duì)應(yīng)于上述的文件發(fā)送、接收和傳輸方法實(shí)施例，其具體的實(shí)現(xiàn)過程在方法實(shí)施例中已經(jīng)進(jìn)行過詳細(xì)說明，在此不再贅述。
顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計(jì)算裝置來實(shí)現(xiàn)，它們可以集中在單個(gè)的計(jì)算裝置上，或者分布在多個(gè)計(jì)算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計(jì)算裝置可執(zhí)行的程序代碼來實(shí)現(xiàn)，從而，可以將它們存儲(chǔ)在存儲(chǔ)裝置中由計(jì)算裝置來執(zhí)行，或者將它們分別制作成各個(gè)集成電路模塊，或者將它們中的多個(gè)模塊或步驟制作成單個(gè)集成電路模塊來實(shí)現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。以上所述僅為本發(fā)明的優(yōu)選實(shí)施例而已，并不用于限制本發(fā)明，對(duì)于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1.一種文件發(fā)送方法，其特征在于，應(yīng)用于藍(lán)牙傳輸，包括發(fā)送端確定空間值，其中，所述空間值為待傳輸文件占用的存儲(chǔ)空間的大??； 所述發(fā)送端將所述待傳輸文件以及所述空間值均發(fā)送至接收端。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述發(fā)送端將所述空間值發(fā)送至接收端， 包括所述發(fā)送端將所述空間值封裝到0BXE_0bjeCtAddHeader數(shù)據(jù)包中； 所述發(fā)送端將所述0BXE_0bjectAddHeader數(shù)據(jù)包發(fā)送至所述接收端。
3.一種文件接收方法，其特征在于，應(yīng)用于藍(lán)牙傳輸，包括接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，所述空間值為所述待傳輸文件占用的存儲(chǔ)空間的大??；所述接收端比較本地的存儲(chǔ)空間的大小與所述空間值，根據(jù)比較結(jié)果確定是否接收所述待傳輸文件。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述接收端根據(jù)比較結(jié)果確定是否接收所述待傳輸文件，包括在所述接收端本地的存儲(chǔ)空間的大小不小于所述空間值時(shí)，所述接收端判斷本地未被占用的存儲(chǔ)空間的大小是否不小于所述空間值；若是，所述接收端進(jìn)行藍(lán)牙傳輸，接收所述待傳輸文件；若否，所述接收端刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用，直至所述未被占用的存儲(chǔ)空間的大小不小于所述空間值。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述接收端刪除本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用，包括所述接收端提示用戶本地沒有足夠的存儲(chǔ)空間進(jìn)行本次藍(lán)牙傳輸； 所述接收端接收用戶輸入的刪除指示，其中，所述刪除指示用于指示刪除的文件或應(yīng)用；所述接收端根據(jù)所述刪除指示刪除所述本地被占用的存儲(chǔ)空間中存儲(chǔ)的文件或應(yīng)用。
6.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述接收端根據(jù)比較結(jié)果確定是否接收所述待傳輸文件，包括當(dāng)所述接收端本地的存儲(chǔ)空間的大小小于所述空間值時(shí)，所述接收端提示用戶當(dāng)前空間無法進(jìn)行所述待傳輸文件的藍(lán)牙傳輸。
7.根據(jù)權(quán)利要求3至6任一項(xiàng)所述的方法，其特征在于，所述接收端確定本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，包括所述接收端接收封裝有所述空間值的0BXE_0bjeCtAddHeader數(shù)據(jù)包； 所述接收端解析所述0BXE_0b jectAddHeader數(shù)據(jù)包，獲取所述空間值。
8.一種文件傳輸方法，其特征在于，應(yīng)用于藍(lán)牙傳輸，包括發(fā)送端確定空間值，其中，所述空間值為待傳輸文件占用的存儲(chǔ)空間的大小； 所述發(fā)送端將所述待傳輸文件以及所述空間值均發(fā)送至接收端； 所述接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值；所述接收端比較本地的存儲(chǔ)空間的大小與所述空間值，根據(jù)比較結(jié)果確定是否接收所述待傳輸文件。
9.一種文件發(fā)送裝置，其特征在于，應(yīng)用于藍(lán)牙傳輸，包括確定模塊，用于確定空間值，其中，所述空間值為待傳輸文件占用的存儲(chǔ)空間的大小； 發(fā)送模塊，用于將所述待傳輸文件以及所述空間值均發(fā)送至接收端。
10.一種文件接收裝置，其特征在于，應(yīng)用于藍(lán)牙傳輸，包括接收模塊，用于接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，所述空間值為所述待傳輸文件占用的存儲(chǔ)空間的大小；比較模塊，用于比較本地的存儲(chǔ)空間的大小與所述空間值，根據(jù)比較結(jié)果確定是否接收所述待傳輸文件。
11.一種文件傳輸系統(tǒng)，其特征在于，應(yīng)用于藍(lán)牙傳輸，包括發(fā)送端與接收端所述發(fā)送端用于確定空間值，其中，所述空間值為待傳輸文件占用的存儲(chǔ)空間的大?。?將所述待傳輸文件以及所述空間值均發(fā)送至所述接收端；所述接收端用于確定本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值，其中，所述空間值為所述待傳輸文件占用的存儲(chǔ)空間的大?。槐容^本地的存儲(chǔ)空間的大小與所述空間值，根據(jù)比較結(jié)果確定是否接收所述待傳輸文件。
全文摘要
本發(fā)明公開了一種文件發(fā)送、接收方法及裝置和文件傳輸方法及系統(tǒng)，該文件傳輸方法包括發(fā)送端確定空間值，其中，空間值為待傳輸文件占用的存儲(chǔ)空間的大??；發(fā)送端將待傳輸文件以及空間值均發(fā)送至接收端；接收端接收本次藍(lán)牙傳輸?shù)拇齻鬏斘募目臻g值；接收端比較本地的存儲(chǔ)空間的大小與空間值，根據(jù)比較結(jié)果確定是否接收待傳輸文件。本發(fā)明解決了用戶使用藍(lán)牙接收文件時(shí)，終端只有在接收部分文件后才提示空間不足，從而導(dǎo)致之前傳輸?shù)臄?shù)據(jù)丟失，使用不方便的問題，提高了用戶體驗(yàn)。
文檔編號(hào)H04B5/00GK102412875SQ20111044116
公開日2012年4月11日 申請(qǐng)日期2011年12月26日 優(yōu)先權(quán)日2011年12月26日
發(fā)明者周琦, 楊小明, 范曉黎 申請(qǐng)人:中興通訊股份有限公司