本發(fā)明涉及自動讀取設(shè)備參數(shù)技術(shù)領(lǐng)域,尤其涉及一種自動讀取設(shè)備參數(shù)的方法和Android工控系統(tǒng)。
背景技術(shù):
隨著移動終端技術(shù)的發(fā)展,智能手機普及到了千家萬戶中?,F(xiàn)如今,市面上普遍的智能手機分為兩類,ios手機和Android手機。ios手機與Android手機的區(qū)別在于二者所搭載的手機操作系統(tǒng)的不同。ios手機的ios系統(tǒng)擁有其封閉完整的生態(tài)鏈系統(tǒng),不允許非官方開發(fā)人員對其進行數(shù)據(jù)的增刪改查;而Android手機由于其開源代碼的特性,允許任意開發(fā)人員對其進行增刪改查,兼容性和靈活性相對較強。ios系統(tǒng)和Android系統(tǒng)之間數(shù)據(jù)不互通,保障了各自系統(tǒng)的獨立性和完整性。
但是在某些特定場景中,如用戶需要對ios系統(tǒng)的設(shè)備參數(shù)進行數(shù)據(jù)讀取,而身邊只有Android系統(tǒng)的讀取設(shè)備時,用戶便無法獲得想要的數(shù)據(jù)。用戶無法跨越不同操作系統(tǒng)之間的隔離,實現(xiàn)ios系統(tǒng)和Android系統(tǒng)之間數(shù)據(jù)的互通,從而使用戶不得不使用ios系統(tǒng)官方讀取設(shè)備才能獲取到想要的數(shù)據(jù),極大地降低了用戶的使用體驗。
技術(shù)實現(xiàn)要素:
本發(fā)明的主要目的在于提供一種自動讀取設(shè)備參數(shù)的方法和Android工控系統(tǒng),旨在解決ios系統(tǒng)與Android系統(tǒng)因系統(tǒng)不互通數(shù)據(jù)導(dǎo)致用戶在缺乏ios系統(tǒng)官方設(shè)備時無法讀取ios手機的設(shè)備參數(shù)的技術(shù)問題。
為實現(xiàn)上述目的,本發(fā)明實施例提供一種自動讀取設(shè)備參數(shù)的方法,所述自動讀取設(shè)備參數(shù)的方法包括:
向ios手機發(fā)送連接信任請求;
當檢測到ios手機基于連接信任請求的第一確認指令,建立在ios手機和Android工控系統(tǒng)之間的數(shù)據(jù)連接;
基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;
當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)。
可選地,所述基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求的步驟之后還包括:
當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求時,向ios手機發(fā)送第一授權(quán)請求,以獲取ios手機基于第一授權(quán)請求的第一授權(quán)指令;
當檢測到ios手機基于第一授權(quán)請求的第一授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
可選地,所述第一授權(quán)請求包括驗證碼,所述驗證碼作為ios手機與Android工控系統(tǒng)實現(xiàn)授權(quán)驗證的驗證源,以獲得ios手機基于第一授權(quán)請求的第一授權(quán)指令。
可選地,所述當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求時,向ios手機發(fā)送第一授權(quán)請求的步驟之后還包括:
當檢測到ios手機對第一授權(quán)請求中的驗證碼授權(quán)驗證失敗時,更新驗證碼,并向ios手機發(fā)送第二授權(quán)請求,其中第二授權(quán)請求包括更新后新的驗證碼;
當檢測到ios手機基于第二授權(quán)請求中的驗證碼的第二授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
可選地,所述當檢測到驗證碼授權(quán)驗證失敗時,更新驗證碼,并向ios手機發(fā)送第二授權(quán)請求的步驟之后還包括:
當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的第二授權(quán)請求時,重新在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接。
此外,為實現(xiàn)上述目的,本發(fā)明還提供一種Android工控系統(tǒng),所述Android工控系統(tǒng)包括:
第一發(fā)送模塊,用于向ios手機發(fā)送連接信任請求;
第一連接模塊,用于當檢測到ios手機基于連接信任請求的第一確認指令,建立在ios手機和Android工控系統(tǒng)之間的數(shù)據(jù)連接;
第二發(fā)送模塊,用于基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;
讀取模塊,用于當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)。
可選地,所述Android工控系統(tǒng)還包括:
第三發(fā)送模塊,用于當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求時,向ios手機發(fā)送第一授權(quán)請求,以獲取ios手機基于第一授權(quán)請求的第一授權(quán)指令;
所述讀取模塊還用于當檢測到ios手機基于第一授權(quán)請求的第一授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
可選地,所述第一授權(quán)請求包括驗證碼,所述驗證碼作為ios手機與Android工控系統(tǒng)實現(xiàn)授權(quán)驗證的驗證源,以獲得ios手機基于第一授權(quán)請求的第一授權(quán)指令。
可選地,所述Android工控系統(tǒng)還包括:
第四發(fā)送模塊,用于當檢測到ios手機對第一授權(quán)請求中的驗證碼授權(quán)驗證失敗時,更新驗證碼,并向ios手機發(fā)送第二授權(quán)請求,其中第二授權(quán)請求包括更新后新的驗證碼;
所述讀取模塊還用于當檢測到ios手機基于第二授權(quán)請求中的驗證碼的第二授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
可選地,所述Android工控系統(tǒng)還包括:
第二連接模塊,用于當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的第二授權(quán)請求時,重新在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接。
本發(fā)明首先通過向ios手機發(fā)送連接信任請求;接著當檢測到ios手機基于連接信任請求的第一確認指令,建立在ios手機和Android工控系統(tǒng)之間的數(shù)據(jù)連接;然后基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;最后當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)本發(fā)明通過第三方授權(quán)產(chǎn)品Android工控系統(tǒng)作為媒介,在用戶添加信任的前提下實現(xiàn)了Android系統(tǒng)與ios系統(tǒng)之間的數(shù)據(jù)互通,從而通過Android工控系統(tǒng)讀取到ios系統(tǒng)對應(yīng)的ios手機里的設(shè)備參數(shù),進而方便用戶對ios手機設(shè)備參數(shù)的查詢,提高Android工控系統(tǒng)的系統(tǒng)兼容性,提升Android工控系統(tǒng)讀取設(shè)備參數(shù)的工作效率。
附圖說明
圖1為本發(fā)明自動讀取設(shè)備參數(shù)的方法第一實施例的流程示意圖;
圖2為本發(fā)明自動讀取設(shè)備參數(shù)的方法第二實施例的流程示意圖;
圖3為本發(fā)明自動讀取設(shè)備參數(shù)的方法第四實施例的流程示意圖;
圖4為本發(fā)明自動讀取設(shè)備參數(shù)的方法第五實施例的流程示意圖;
圖5是本發(fā)明Android工控系統(tǒng)第一實施例的模塊示意圖;
圖6為本發(fā)明Android工控系統(tǒng)第二實施例的模塊示意圖;
圖7為本發(fā)明Android工控系統(tǒng)第四實施例的模塊示意圖;
圖8為本發(fā)明Android工控系統(tǒng)第五實施例的模塊示意圖;
圖9為本發(fā)明自動讀取設(shè)備參數(shù)的方法的交互時序圖。
本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結(jié)合實施例,參考附圖做進一步說明。
具體實施方式
應(yīng)當理解,此處所描述的具體實施例僅僅用以解釋本發(fā)明,并不用于限定本發(fā)明。
現(xiàn)在將參考附圖描述實現(xiàn)本發(fā)明各個實施例的Android工控系統(tǒng)。在后續(xù)的描述中,使用用于表示元件的諸如“模塊”、“部件”或“單元”的后綴僅為了有利于本發(fā)明的說明,其本身并沒有特定的意義。因此,“模塊”與“部件”可以混合地使用。
所述Android工控系統(tǒng)是基于Android開發(fā)集成的工業(yè)控制系統(tǒng),指的是使用計算機技術(shù),微電子技術(shù),電氣技術(shù)等工業(yè)控制技術(shù)控制工程業(yè)務(wù)的自動控制系統(tǒng),能夠使所對應(yīng)的技術(shù)服務(wù)更加自動化、效率化、精確化,并具有可控性及可視性。Android工控系統(tǒng)可以以各種形式來實施。例如,本發(fā)明中描述的Android工控系統(tǒng)可以搭載Android工控系統(tǒng)的各種終端,包括諸如PC電腦、智能打印機、筆記本電腦、數(shù)字廣播接收器、PDA(個人數(shù)字助理)、PAD(平板電腦)、PMP(便攜式多媒體播放器)、手機回收終端等等的Android工控系統(tǒng)以及諸如數(shù)字TV、臺式計算機等等的固定終端。本領(lǐng)域技術(shù)人員將理解的是,除了特別用于移動目的的元件之外,根據(jù)本發(fā)明的實施方式的構(gòu)造也能夠應(yīng)用于固定類型的終端。
參考圖1和圖9,本發(fā)明提供一種自動讀取設(shè)備參數(shù)的方法,該自動讀取設(shè)備參數(shù)的方法主要應(yīng)用于Android工控系統(tǒng)上,在自動讀取設(shè)備參數(shù)的方法第一實施例中,所述自動讀取設(shè)備參數(shù)的方法包括:
步驟S10,向ios手機發(fā)送連接信任請求;
一般而言,Android工控系統(tǒng)與ios手機的連接,需要經(jīng)過用戶將ios手機的連接接口連接到Android工控系統(tǒng)的連接接口上。而由于ios手機與Android工控系統(tǒng)各自搭載的操作系統(tǒng)分屬不同陣營,存在著天然的系統(tǒng)隔離,雙方數(shù)據(jù)默認不互通,除非擁有相關(guān)的訪問權(quán)限,所以在ios手機與Android工控系統(tǒng)的連接接口連接上之后,仍然需要對兩端設(shè)備進行連接驗證。Android工控系統(tǒng)作為讀取ios手機設(shè)備參數(shù)的請求方,因此需要向ios手機發(fā)送連接信任請求,若ios手機通過該請求,則Android工控系統(tǒng)能獲取到訪問ios手機設(shè)備參數(shù)的相關(guān)權(quán)限。
步驟S20,當檢測到ios手機基于連接信任請求的第一確認指令,在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接;
連接信任請求的作用在于獲取Android工控系統(tǒng)與ios手機之間建立數(shù)據(jù)連接,以便進行數(shù)據(jù)傳輸?shù)臋?quán)限,而該權(quán)限來自于ios手機是否允許該連接信任請求,即ios手機是否生成了允許該連接信任請求的第一確認指令。第一確認指令代表了ios手機認可了Android工控系統(tǒng)的連接信任請求,允許Android工控系統(tǒng)對自身的設(shè)備數(shù)據(jù)的連接。一般而言,第一確認指令的生成來源于Android工控系統(tǒng)的底層協(xié)議被ios手機所認證;或者用戶確認了該連接信任請求;或者Android工控系統(tǒng)曾與該ios手機進行過連接,且該Android工控系統(tǒng)屬于ios手機的信任設(shè)備等等。基于該第一確認指令,Android工控系統(tǒng)在ios手機和Android工控系統(tǒng)之間建立連接通道,以便ios手機和Android工控系統(tǒng)之間能夠進行數(shù)據(jù)傳輸。
步驟S30,基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;
Android工控系統(tǒng)與ios手機建立數(shù)據(jù)連接之后,查詢ios手機的設(shè)備參數(shù)需要向ios手機進行請求,因此通過已建立的數(shù)據(jù)連接通道,Android工控系統(tǒng)向ios手機發(fā)送參數(shù)查詢請求。
步驟S40,當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)。
所述設(shè)備參數(shù)指代的是ios手機內(nèi)部存儲的配置參數(shù)以及一些本機設(shè)定的設(shè)置信息,如本機系統(tǒng)版本,內(nèi)存容量,屏幕分辨率,IMEI碼,賬號ID,或用戶昵稱等等數(shù)據(jù)。
ios手機對應(yīng)的ios系統(tǒng)內(nèi)對其本身的數(shù)據(jù)皆有對應(yīng)的安全守護進程,主要用于針對相應(yīng)的數(shù)據(jù)進行數(shù)據(jù)封裝,防止外部設(shè)備隨意訪問,保護數(shù)據(jù)隱私和安全。而參數(shù)查詢請求主要是獲取以上所述的安全守護進程的訪問權(quán)限,若安全守護進程通過了該參數(shù)查詢請求,則ios手機會據(jù)此生成參數(shù)查詢請求的第二確認指令。而Android工控系統(tǒng)能通過數(shù)據(jù)連接通道實時監(jiān)測到第二確認指令,從而根據(jù)第二確認指令,查找到ios手機內(nèi)相對應(yīng)的設(shè)備參數(shù),并將其讀取出來。需要說明的是,第二確認指令在給予Android工控系統(tǒng)相應(yīng)的參數(shù)查詢權(quán)限的同時,也指定了Android工控系統(tǒng)所能進行參數(shù)查詢的設(shè)備參數(shù)的存儲路徑,即Android工控系統(tǒng)只能查詢讀取該存儲路徑上的設(shè)備參數(shù),因為該設(shè)備參數(shù)對應(yīng)著相應(yīng)的安全守護進程,該安全守護進程允許的是Android工控系統(tǒng)對本安全守護進程所守護的設(shè)備數(shù)據(jù)的訪問,而不是其他設(shè)備數(shù)據(jù)的訪問,因此只提供對應(yīng)的設(shè)備數(shù)據(jù)的存儲路徑。
本發(fā)明通過向ios手機發(fā)送連接信任請求;然后當檢測到ios手機基于連接信任請求的第一確認指令,在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接;接著基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;最后當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)。本發(fā)明通過第三方授權(quán)產(chǎn)品Android工控系統(tǒng)作為媒介,在用戶添加信任的前提下實現(xiàn)了Android系統(tǒng)與ios系統(tǒng)之間的數(shù)據(jù)互通,從而通過Android工控系統(tǒng)讀取到ios系統(tǒng)對應(yīng)的ios手機里的設(shè)備參數(shù),進而方便用戶對ios手機設(shè)備參數(shù)的查詢,提高Android工控系統(tǒng)的系統(tǒng)兼容性,提升Android工控系統(tǒng)讀取設(shè)備參數(shù)的工作效率。
進一步地,在本發(fā)明自動讀取設(shè)備參數(shù)的方法第一實施例的基礎(chǔ)上,提出自動讀取設(shè)備參數(shù)的方法第二實施例,參考圖2和圖9,所述第二實施例與第一實施例之間的區(qū)別在于,所述基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求的步驟之后還包括:
步驟S50,當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求時,向ios手機發(fā)送第一授權(quán)請求,以獲取ios手機基于第一授權(quán)請求的第一授權(quán)指令;
所述當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)的步驟還包括:
當檢測到ios手機基于第一授權(quán)請求的第一授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
假設(shè)ios手機未通過Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求,則證明當前情況下Android工控系統(tǒng)未能獲得讀取訪問ios手機的設(shè)備參數(shù)的權(quán)限,為實現(xiàn)本發(fā)明的技術(shù)方案,Android工控系統(tǒng)需要獲取到讀取ios手機的設(shè)備參數(shù)的低一級權(quán)限。
參數(shù)查詢請求與第一授權(quán)請求的區(qū)別在于,參數(shù)查詢請求的第二確認指令提供給Android工控系統(tǒng)的權(quán)限可以讀取到ios手機設(shè)備信息中非鎖定保護的所有配置信息和設(shè)置數(shù)據(jù),如本機系統(tǒng)版本,內(nèi)存容量,屏幕分辨率,IMEI碼,賬號ID,或用戶昵稱等等;而第一授權(quán)請求的第一授權(quán)指令提供給Android工控系統(tǒng)的權(quán)限只限于讀取到本機系統(tǒng)版本,內(nèi)存容量,屏幕分辨率,IMEI碼等公開化的硬件配置信息或設(shè)置數(shù)據(jù),而無法讀取到ios手機設(shè)備信息中相對私人的配置信息和設(shè)置數(shù)據(jù),例如賬號ID或用戶昵稱等參數(shù)信息。而私人的配置信息和設(shè)置數(shù)據(jù)是可編輯的,其重要性不及公開化的配置信息或設(shè)置數(shù)據(jù)。很明顯,在未能獲得ios手機完整的設(shè)備參數(shù)的前提下,忽略ios手機中的私人附屬設(shè)備參數(shù),只獲取其主要的設(shè)備參數(shù)亦能夠滿足本發(fā)明的目的。其中,第一授權(quán)請求所請求的指令權(quán)限低于參數(shù)查詢請求的指令權(quán)限,其所能讀取到設(shè)備參數(shù)的范圍相對窄一些。
相對應(yīng)的,當檢測到ios手機基于第一授權(quán)請求的第一授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
進一步地,在本發(fā)明自動讀取設(shè)備參數(shù)的方法第二實施例的基礎(chǔ)上,提出自動讀取設(shè)備參數(shù)的方法第三實施例,所述第三實施例與第二實施例之間的區(qū)別在于,所述第一授權(quán)請求包括驗證碼,所述驗證碼作為ios手機與Android工控系統(tǒng)實現(xiàn)授權(quán)驗證的驗證源,以獲得ios手機基于第一授權(quán)請求的第一授權(quán)指令。
本實施例在第一授權(quán)請求中提供一種驗證碼,所述驗證碼能夠在第一授權(quán)請求中作為Android工控系統(tǒng)提供給ios手機進行身份認證的驗證參考源。
具體地,Android工控系統(tǒng)發(fā)送的第一授權(quán)請求中,包括了驗證碼,該驗證碼可顯示在Android工控系統(tǒng)的顯示界面上,若用戶在ios手機中輸入該驗證碼的具體內(nèi)容,從ios手機的角度來看,ios手機通過數(shù)據(jù)連接通道判斷驗證碼是否相匹配,若匹配,則證明用戶允許了本次第一授權(quán)請求,那么即意味著本機可以提供Android工控系統(tǒng)第一授權(quán)請求對應(yīng)的權(quán)限。ios手機據(jù)此生成第一授權(quán)請求對應(yīng)的第一授權(quán)指令。而Android工控系統(tǒng)通過數(shù)據(jù)連接通道可實時監(jiān)測到該第一授權(quán)指令,從而獲取到對應(yīng)的讀取權(quán)限。
進一步地,在本發(fā)明自動讀取設(shè)備參數(shù)的方法第三實施例的基礎(chǔ)上,提出自動讀取設(shè)備參數(shù)的方法第四實施例,參考圖3和圖9,所述第四實施例與第三實施例之間的區(qū)別在于,所述當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求時,向ios手機發(fā)送第一授權(quán)請求的步驟之后還包括:
步驟S60,當檢測到驗證碼授權(quán)驗證失敗時,更新驗證碼,并向ios手機發(fā)送第二授權(quán)請求,其中第二授權(quán)請求包括更新后新的驗證碼;
所述當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)的步驟還包括:
當檢測到ios手機基于第二授權(quán)請求的第二授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
驗證碼在ios手機上的輸入可能出現(xiàn)錯誤,導(dǎo)致驗證碼授權(quán)驗證失敗,進而導(dǎo)致第一授權(quán)請求被拒絕,從而使得Android工控系統(tǒng)無法獲得第一授權(quán)請求對應(yīng)的第一授權(quán)指令。為防止因輸入錯誤導(dǎo)致第一授權(quán)請求被拒絕,造成重新發(fā)送第一授權(quán)請求,進而浪費系統(tǒng)資源。在檢測到驗證碼授權(quán)驗證失敗時,Android工控系統(tǒng)更新所述驗證碼,將該驗證碼連同第二授權(quán)請求發(fā)送至ios手機,進行新一輪的授權(quán)驗證,以獲得第二授權(quán)請求的第二授權(quán)指令。假設(shè)獲取到第二授權(quán)指令,則證明Android工控系統(tǒng)獲取到ios手機基于第二授權(quán)請求的權(quán)限。
若Android工控系統(tǒng)檢測到第二授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
進一步地,在本發(fā)明自動讀取設(shè)備參數(shù)的方法第四實施例的基礎(chǔ)上,提出自動讀取設(shè)備參數(shù)的方法第五實施例,參考圖4和圖9,所述第五實施例與第四實施例之間的區(qū)別在于,所述當檢測到驗證碼授權(quán)驗證失敗時,更新驗證碼,并向ios手機發(fā)送第二授權(quán)請求的步驟之后還包括:
步驟S70,當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的第二授權(quán)請求時,重新在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接。
若檢測到ios手機拒絕了Android工控系統(tǒng)的第一授權(quán)請求,則證明Android工控系統(tǒng)多次獲取ios手機的設(shè)備參數(shù)權(quán)限的請求都沒有通過,也就是說,ios手機沒有通過Android工控系統(tǒng)的參數(shù)查詢請求、第一授權(quán)請求以及第二授權(quán)請求,而當前是處于數(shù)據(jù)連接狀態(tài),那么該狀態(tài)很可能已經(jīng)失效,或者Android工控系統(tǒng)與ios手機的數(shù)據(jù)連接處于異常狀態(tài)。為糾正這一可能存在的故障問題,需要將當前的數(shù)據(jù)連接狀態(tài)初始化為未連接狀態(tài),重新進行連接驗證,即重新在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接。
參考圖5和圖9,本發(fā)明還提供一種Android工控系統(tǒng),在Android工控系統(tǒng)第一實施例中,所述Android工控系統(tǒng)包括:
第一發(fā)送模塊10,用于向ios手機發(fā)送連接信任請求;
一般而言,Android工控系統(tǒng)與ios手機的連接,需要經(jīng)過用戶將ios手機的連接接口連接到Android工控系統(tǒng)的連接接口上。而由于ios手機與Android工控系統(tǒng)各自搭載的操作系統(tǒng)分屬不同陣營,存在著天然的系統(tǒng)隔離,雙方數(shù)據(jù)默認不互通,除非擁有相關(guān)的訪問權(quán)限,所以在ios手機與Android工控系統(tǒng)的連接接口連接上之后,仍然需要對兩端設(shè)備進行連接驗證。Android工控系統(tǒng)作為讀取ios手機設(shè)備參數(shù)的請求方,因此第一發(fā)送模塊10需要向ios手機發(fā)送連接信任請求,若ios手機通過該請求,則Android工控系統(tǒng)能獲取到訪問ios手機設(shè)備參數(shù)的相關(guān)權(quán)限。
第一連接模塊20,用于當檢測到ios手機基于連接信任請求的第一確認指令,建立在ios手機和Android工控系統(tǒng)之間的數(shù)據(jù)連接;
連接信任請求的作用在于獲取Android工控系統(tǒng)與ios手機之間建立數(shù)據(jù)連接,以便進行數(shù)據(jù)傳輸?shù)臋?quán)限,而該權(quán)限來自于ios手機是否允許該連接信任請求,即ios手機是否生成了允許該連接信任請求的第一確認指令。第一確認指令代表了ios手機認可了Android工控系統(tǒng)的連接信任請求,允許Android工控系統(tǒng)對自身的設(shè)備數(shù)據(jù)的連接。一般而言,第一確認指令的生成來源于Android工控系統(tǒng)的底層協(xié)議被ios手機所認證;或者用戶確認了該連接信任請求;或者Android工控系統(tǒng)曾與該ios手機進行過連接,且該Android工控系統(tǒng)屬于ios手機的信任設(shè)備等等。基于該第一確認指令,第一連接模塊20在ios手機和Android工控系統(tǒng)之間建立連接通道,以便ios手機和Android工控系統(tǒng)之間能夠進行數(shù)據(jù)傳輸。
第二發(fā)送模塊30,用于基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;
Android工控系統(tǒng)與ios手機建立數(shù)據(jù)連接之后,查詢ios手機的設(shè)備參數(shù)需要向ios手機進行請求,因此通過已建立的數(shù)據(jù)連接通道,第二發(fā)送模塊30向ios手機發(fā)送參數(shù)查詢請求。
讀取模塊40,用于當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)。
所述設(shè)備參數(shù)指代的是ios手機內(nèi)部存儲的配置參數(shù)以及一些本機設(shè)定的設(shè)置信息,如本機系統(tǒng)版本,內(nèi)存容量,屏幕分辨率,IMEI碼,賬號ID,或用戶昵稱等等數(shù)據(jù)。
ios手機對應(yīng)的ios系統(tǒng)內(nèi)對其本身的數(shù)據(jù)皆有對應(yīng)的安全守護進程,主要用于針對相應(yīng)的數(shù)據(jù)進行數(shù)據(jù)封裝,防止外部設(shè)備隨意訪問,保護數(shù)據(jù)隱私和安全。而參數(shù)查詢請求主要是獲取以上所述的安全守護進程的訪問權(quán)限,若安全守護進程通過了該參數(shù)查詢請求,則ios手機會據(jù)此生成參數(shù)查詢請求的第二確認指令。而Android工控系統(tǒng)能通過數(shù)據(jù)連接通道實時監(jiān)測到第二確認指令,從而根據(jù)第二確認指令,查找到ios手機內(nèi)相對應(yīng)的設(shè)備參數(shù),并將其讀取出來。需要說明的是,第二確認指令在給予Android工控系統(tǒng)相應(yīng)的參數(shù)查詢權(quán)限的同時,也指定了Android工控系統(tǒng)所能進行參數(shù)查詢的設(shè)備參數(shù)的存儲路徑,即Android工控系統(tǒng)只能查詢讀取該存儲路徑上的設(shè)備參數(shù),因為該設(shè)備參數(shù)對應(yīng)著相應(yīng)的安全守護進程,該安全守護進程允許的是Android工控系統(tǒng)對本安全守護進程所守護的設(shè)備數(shù)據(jù)的訪問,而不是其他設(shè)備數(shù)據(jù)的訪問,因此只提供對應(yīng)的設(shè)備數(shù)據(jù)的存儲路徑。
本發(fā)明首先通過第一發(fā)送模塊10向ios手機發(fā)送連接信任請求;接著當?shù)谝贿B接模塊20檢測到ios手機基于連接信任請求的第一確認指令,建立在ios手機和Android工控系統(tǒng)之間的數(shù)據(jù)連接;然后第二發(fā)送模塊30基于數(shù)據(jù)連接向ios手機發(fā)送參數(shù)查詢請求;最后讀取模塊40當檢測到ios手機基于參數(shù)查詢請求的第二確認指令時,讀取ios手機的設(shè)備參數(shù)本發(fā)明通過第三方授權(quán)產(chǎn)品Android工控系統(tǒng)作為媒介,在用戶添加信任的前提下實現(xiàn)了Android系統(tǒng)與ios系統(tǒng)之間的數(shù)據(jù)互通,從而通過Android工控系統(tǒng)讀取到ios系統(tǒng)對應(yīng)的ios手機里的設(shè)備參數(shù),進而方便用戶對ios手機設(shè)備參數(shù)的查詢,提高Android工控系統(tǒng)的系統(tǒng)兼容性,提升Android工控系統(tǒng)讀取設(shè)備參數(shù)的工作效率。
進一步地,在本發(fā)明Android工控系統(tǒng)第一實施例的基礎(chǔ)上,提出Android工控系統(tǒng)第二實施例,參考圖6和圖9,所述第二實施例與第一實施例之間的區(qū)別在于,所述Android工控系統(tǒng)還包括:
第三發(fā)送模塊50,用于當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求時,向ios手機發(fā)送第一授權(quán)請求,以獲取ios手機基于第一授權(quán)請求的第一授權(quán)指令;
所述讀取模塊40還用于當檢測到ios手機基于第一授權(quán)請求的第一授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
假設(shè)ios手機未通過Android工控系統(tǒng)發(fā)送的參數(shù)查詢請求,則證明當前情況下Android工控系統(tǒng)未能獲得讀取訪問ios手機的設(shè)備參數(shù)的權(quán)限,為實現(xiàn)本發(fā)明的技術(shù)方案,Android工控系統(tǒng)需要獲取到讀取ios手機的設(shè)備參數(shù)的低一級權(quán)限。
參數(shù)查詢請求與第一授權(quán)請求的區(qū)別在于,參數(shù)查詢請求的第二確認指令提供給Android工控系統(tǒng)的權(quán)限可以讀取到ios手機設(shè)備信息中非鎖定保護的所有配置信息和設(shè)置數(shù)據(jù),如本機系統(tǒng)版本,內(nèi)存容量,屏幕分辨率,IMEI碼,賬號ID,或用戶昵稱等等;而第一授權(quán)請求的第一授權(quán)指令提供給Android工控系統(tǒng)的權(quán)限只限于讀取到本機系統(tǒng)版本,內(nèi)存容量,屏幕分辨率,IMEI碼等公開化的硬件配置信息或設(shè)置數(shù)據(jù),而無法讀取到ios手機設(shè)備信息中相對私人的配置信息和設(shè)置數(shù)據(jù),例如賬號ID或用戶昵稱等參數(shù)信息。而私人的配置信息和設(shè)置數(shù)據(jù)是可編輯的,其重要性不及公開化的配置信息或設(shè)置數(shù)據(jù)。很明顯,在未能獲得ios手機完整的設(shè)備參數(shù)的前提下,忽略ios手機中的私人附屬設(shè)備參數(shù),只獲取其主要的設(shè)備參數(shù)亦能夠滿足本發(fā)明的目的。其中,第一授權(quán)請求所請求的指令權(quán)限低于參數(shù)查詢請求的指令權(quán)限,其所能讀取到設(shè)備參數(shù)的范圍相對窄一些。
相對應(yīng)的,讀取模塊40還用于當檢測到ios手機基于第一授權(quán)請求的第一授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
進一步地,在本發(fā)明Android工控系統(tǒng)第二實施例的基礎(chǔ)上,提出Android工控系統(tǒng)第三實施例,所述第三實施例與第二實施例之間的區(qū)別在于,所述第一授權(quán)請求包括驗證碼,所述驗證碼作為ios手機與Android工控系統(tǒng)實現(xiàn)授權(quán)驗證的驗證源,以獲得ios手機基于第一授權(quán)請求的第一授權(quán)指令。
第一授權(quán)請求需要在ios手機驗證通過的情況下才能獲取到第一授權(quán)指令,驗證方式可以是用戶指紋驗證確認,或者用戶向ios手機輸入權(quán)限密碼,或者驗證碼驗證確認等方式來開放賦予Android工控系統(tǒng)所請求的權(quán)限。
本實施例提供一種驗證碼,所述驗證碼能夠在第一授權(quán)請求中作為Android工控系統(tǒng)提供給ios手機進行身份認證的驗證參考源。
具體地,Android工控系統(tǒng)發(fā)送的第一授權(quán)請求中,包括了驗證碼,該驗證碼可顯示在Android工控系統(tǒng)的顯示界面上,若用戶在ios手機中輸入該驗證碼的具體內(nèi)容,從ios手機的角度來看,ios手機通過數(shù)據(jù)連接通道判斷驗證碼是否相匹配,若匹配,則證明用戶允許了本次第一授權(quán)請求,那么即意味著本機可以提供Android工控系統(tǒng)第一授權(quán)請求對應(yīng)的權(quán)限。ios手機據(jù)此生成第一授權(quán)請求對應(yīng)的第一授權(quán)指令。而Android工控系統(tǒng)通過數(shù)據(jù)連接通道可實時監(jiān)測到該第一授權(quán)指令,從而獲取到對應(yīng)的讀取權(quán)限。
進一步地,在本發(fā)明Android工控系統(tǒng)第三實施例的基礎(chǔ)上,提出Android工控系統(tǒng)第四實施例,參考圖7和圖9,所述第四實施例與第三實施例之間的區(qū)別在于,所述Android工控系統(tǒng)還包括:
第四發(fā)送模塊60,用于當檢測到ios手機對第一授權(quán)請求中的驗證碼授權(quán)驗證失敗時,更新驗證碼,并向ios手機發(fā)送第二授權(quán)請求,其中第二授權(quán)請求包括更新后新的驗證碼;
所述讀取模塊40還用于當檢測到ios手機基于第二授權(quán)請求中的驗證碼的第二授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
驗證碼在ios手機上的輸入可能出現(xiàn)錯誤,導(dǎo)致驗證碼授權(quán)驗證失敗,進而導(dǎo)致第一授權(quán)請求被拒絕,從而使得Android工控系統(tǒng)無法獲得第一授權(quán)請求對應(yīng)的第一授權(quán)指令。為防止因輸入錯誤導(dǎo)致第一授權(quán)請求被拒絕,造成重新發(fā)送第一授權(quán)請求,進而浪費系統(tǒng)資源。在檢測到驗證碼授權(quán)驗證失敗時,第四發(fā)送模塊60更新所述驗證碼,將該驗證碼連同第二授權(quán)請求發(fā)送至ios手機,進行新一輪的授權(quán)驗證,以獲得第二授權(quán)請求的第二授權(quán)指令。假設(shè)獲取到第二授權(quán)指令,則證明Android工控系統(tǒng)獲取到ios手機基于第二授權(quán)請求的權(quán)限。
若Android工控系統(tǒng)在讀取模塊40檢測到第二授權(quán)指令時,讀取ios手機的設(shè)備參數(shù)。
進一步地,在本發(fā)明Android工控系統(tǒng)第四實施例的基礎(chǔ)上,提出Android工控系統(tǒng)第五實施例,參考圖8和圖9,所述第五實施例與第四實施例之間的區(qū)別在于,所述Android工控系統(tǒng)還包括:
第二連接模塊70,用于當檢測到ios手機拒絕Android工控系統(tǒng)發(fā)送的第二授權(quán)請求時,重新在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接。
若檢測到ios手機拒絕了Android工控系統(tǒng)的第一授權(quán)請求,則證明Android工控系統(tǒng)多次獲取ios手機的設(shè)備參數(shù)權(quán)限的請求都沒有通過,也就是說,ios手機沒有通過Android工控系統(tǒng)的參數(shù)查詢請求、第一授權(quán)請求以及第二授權(quán)請求,而當前是處于數(shù)據(jù)連接狀態(tài),那么該狀態(tài)很可能已經(jīng)失效,或者Android工控系統(tǒng)與ios手機的數(shù)據(jù)連接處于異常狀態(tài)。為糾正這一可能存在的故障問題,需要將當前的數(shù)據(jù)連接狀態(tài)初始化為未連接狀態(tài),重新進行連接驗證,即重新在ios手機和Android工控系統(tǒng)之間建立數(shù)據(jù)連接。
需要說明的是,在本文中,術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含,從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素,而且還包括沒有明確列出的其他要素,或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下,由語句“包括一個……”限定的要素,并不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。
上述本發(fā)明實施例序號僅僅為了描述,不代表實施例的優(yōu)劣。
通過以上的實施方式的描述,本領(lǐng)域的技術(shù)人員可以清楚地了解到上述實施例方法可借助軟件加必需的通用硬件平臺的方式來實現(xiàn),當然也可以通過硬件,但很多情況下前者是更佳的實施方式?;谶@樣的理解,本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來,該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)(如ROM/RAM、磁碟、光盤)中,包括若干指令用以使得一臺終端設(shè)備(可以是手機,計算機,服務(wù)器,空調(diào)器,或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述的方法。
以上僅為本發(fā)明的優(yōu)選實施例,并非因此限制本發(fā)明的專利范圍,凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換,或直接或間接運用在其他相關(guān)的技術(shù)領(lǐng)域,均同理包括在本發(fā)明的專利保護范圍內(nèi)。