以前答應你們的畢業答辯以後把全部文檔貢獻出來,如今答辯已過,LZ信守承諾,把全部文檔開源到了GitHub(這個地址包含全部的代碼和文檔以及PPT,外層爲簡單的代碼)。還望喜歡的朋友們,不要吝嗇你的星星,多多Star。git
簡單演示:(這裏只演示部分,詳情去移步GitHub)github
四川師範大學本科畢業設計web
基於Android的家校聯繫平臺開發數據庫 |
學生姓名api |
劉世麟安全 |
院系名稱服務器 |
計算機科學學院微信 |
專業名稱網絡 |
軟件工程架構 |
班 級 |
2013級 4班 |
學 號 |
2013110424 |
指導教師 |
夏羽 |
完成時間 |
2017年 5 月 10 日 |
基於Android的家校聯繫平臺開發
學生:劉世麟 指導教師:夏羽
內容摘要:學校教育與家庭教育的不一致,容易產生教育斷層的局面,而現有的校訊通等家校互動平臺,又存在教師與家長單向溝通等方面的問題。現在信息技術的飛速發展爲家校共育的健康發展提供了強有力的保障,「互聯網+」已成趨勢。學校和教師要一改過去傳統的溝通交流方式,借用互聯網與手機短信相結合的家校互動信息平臺,擴展溝通交流渠道,架起家校溝通的橋樑,從而讓家校教育造成協力,提升教育的時效性,促進學生健康成長。所以,本文就目前「互聯網+教育」的新趨勢進行了說明,以明確進行研究的目的。隨後,將對本平臺實現的過程和原理進行一一探討,以讓讀者能瞭解實現其的具體方法。最後,爲了實現這個軟件平臺,本文對這個軟件做了系統分析和系統設計,最終實現了該軟件。經過測試,該平臺能正常運行在Android系統下的智能設備,也驗證了本文所探討的設計正確性和重要性。
關鍵詞:互聯網、家校互動、家校協做、功能應用
Development of home school contact platform based on Android
Abstract: Nowadays, the inconsistency of school education and family education may easily result in education gap. And the existing home-school interactive platforms like School Paper still have some problems including the issue of one-way communication between teachers and parents. The rapid development of information technology has provided a strong guarantee for the healthy development of home-school coeducation. Currently, the」 Internet+」 mode has become a trend, which requires the schools and teachers update the traditional communication ways with parents. They can combine the internet with mobile phone text message to establish a home-school interaction information platform, expanding the communication channel, setting up the bridge of communication so as to produce a unified strength of home-school education, improving the efficiency of education and promote the healthy growth of students. Therefore, This paper puts forward the aim of this research by describing the current trend of 「Internet +Education」. In addition, It explores the process and principles of the new platform to make the readers understand the specific methods. Finally, in order to achieve this software platform, this paper makes a systematic analysis and system design. Through the test, the platform can run in the intelligent equipment of Android system, thus verifying the correctness and importance of the design discussed in this paper.
Key words: Internet; home school interaction; home school cooperation; Function Application
目 錄
1 概述. 1
1.1 研究背景和意義. 1
1.2 國內現狀. 1
1.3 論文的思路和結構. 2
2 研究方案和架構概述. 3
2.1 預計花費時間設計方案. 3
2.2 軟件開發設計方案. 3
2.3 本課題的設計目標. 3
2.4 架構概述. 4
3 需求分析. 5
3.1 軟硬件需求. 5
3.2 功能需求. 5
3.3 用戶需求. 6
3.4 用例圖. 6
3.4.1 登陸板塊. 6
3.4.2 班圈板塊. 7
3.4.3 消息板塊. 8
3.4.4 發現板塊. 9
3.4.5 個人板塊. 10
3.5 用例說明. 10
3.5.1 UC1用戶登陸. 10
3.5.2 UC2用戶註冊. 11
3.5.3 UC3找回密碼. 12
3.5.4 UC4發佈信息. 12
3.5.5 UC5查看全部信息. 13
3.5.6 UC6查看信息詳情. 14
3.5.7 UC7點贊評論回覆. 14
3.5.8 UC8查看聯繫人和會話. 15
3.5.9 UC9聊天. 15
3.5.10 UC10音視頻通話. 16
3.5.11 UC11修改我的信息. 16
3.5.12 UC12修改孩子信息. 17
3.5.13 UC13退出登陸. 18
4 概要設計. 19
4.1 系統功能整體設計圖. 19
4.1.1 Android端功能整體設計圖. 19
4.1.2 服務器端功能整體設計圖. 20
4.2 數據庫E-R圖設計. 21
4.3 系統類圖. 22
4.3.1 APP端登陸板塊. 22
4.3.2 APP端主頁板塊. 22
4.3.3 APP端班圈板塊. 23
4.3.4 APP端發佈板塊. 24
4.3.5 APP端消息板塊. 25
4.3.6 APP端發現板塊. 25
4.3.7 APP端個人板塊. 26
4.4 界面設計. 26
5 詳細設計. 33
5.1 數據庫詳細設計文檔. 33
5.1.1 用戶表設計(aiya_user). 33
5.1.2 班級信息表設計(aiya_class). 33
5.1.3 主貼表設計(aiya_main). 34
5.1.4 評論表設計(aiya_comment) 34
5.1.5 點贊表設計(aiya_praise). 35
5.1.6 主貼圖片表設計(aiya_pic). 35
5.2 CS協議通訊文檔. 35
5.2.1 用戶系統. 35
5.2.2 信息系統. 37
5.3 時序圖. 38
5.3.1 登陸時序圖. 38
5.3.2 發佈時序圖. 39
5.3.3 圈子信息時序圖. 40
5.3.4 聊天時序圖. 41
6 系統實現. 43
6.1 開發工具簡介. 43
6.2 開發界面總覽. 43
6.2.1 Android開發界面總覽. 43
6.2.2 PHP開發界面總覽. 46
6.2.3 數據庫操做頁面總覽. 47
6.3 核心功能代碼. 47
6.3.1 圖片壓縮處理. 47
6.3.2 相機適配處理. 51
7 軟件測試. 57
7.1 功能模塊測試. 57
7.1.1 用戶登陸註冊模塊測試. 57
7.1.2 信息發佈模塊測試. 58
7.1.3 信息交流模塊測試. 59
7.1.4 即時通信模塊測試. 60
7.3 性能測試. 60
7.4 安全測試. 61
7.5 交叉事件測試. 61
7.6 兼容性測試. 61
8 結論. 62
9 謝辭. 63
參考文獻. 64
基於Android的家校聯繫平臺開發
社會的發展,智能手機的普及讓各類各樣的手機應用APP成爲咱們生活中必不可少的一部分,教育行業也搭上了這趟車,走上了「互聯網+」教育,爲了方便學生、家長、學校三體互動,讓家長和學生能及時收到學校發送的消息,知足用戶以前的實時交流,「愛吖校推」應運而生。
「愛吖校推」是一款基於Android的家校互動平臺。隨着社會的發展,各類APP在手機行業發展的助推下應用愈來愈普遍。某權威調研機構表示,2016年,Android系統已經佔領市場份額高達81.3%,而大名鼎鼎的iPhone屈居第二,僅佔17.8%,更使人驚奇的是,Android的市場份額還在持續增多。
社交是人類社會性羣體的基本屬性。而「愛吖校推」就是一款基於教育行業的社交類APP。它支持全部的即時通信應該包含的功能,文件發送、位置發送、音視頻通話、圖片、視頻等,一樣也支持校方和教師發送公告做業並推送到相應羣體的Android智能終端。在當前微信用戶如日中天的基礎上,「愛吖校推」採用微信朋友圈的方式,支持消息發送、點贊、評論、拍照、秒拍、微視頻等羣體社交,真正進入微社交時代。這是一件很是有意義的事情。
家校互動的需求長期已有,它的研究和設計從本世紀初就開始了,並且也取得了不小的成效。但在早期因爲技術的限制,因此存在信息的單項溝通,好比早期的「校訊通」。它就是單純的經過收發短信來達到家校信息交流,教師得不到任何的反饋。以後隨着移動互聯網的發展,微信平臺如魚得水,其雙向溝通性讓一線教師感受是雪中送炭,但其信息篩選性一直爲人詬病。雖然微信等即時通信軟件必定意義上解決了家校互動的問題,但這樣的處理,無疑是增長了教師的工做量。
近年來,有 「愛上學」、「和校園」、「愛學習」、「校訊通」等已經運行的家校互動支持平臺20多個,這些平臺主要實現信息發佈查看等功能,對於信息的及時推送功能匱乏,加之在校大學生多用QQ羣或者微信羣做爲溝通平臺,經常使得通知公告信息錯過,致使了學生之間的信息不對等,而國內超高量的外出打工家長,想看到沒有手機的孩子實在困難。因此「愛吖校推」在操做簡單的基礎上,優化了拍照和微視頻,讓老師能夠把學生的學校狀況實時地分享給你們。消息的離線推送也使得信息的準確到達率迅速提高,而附帶音視頻通話的及時通信板塊,也是拉近了學生、家長、教師之間的距離。
該論文分十個部分進行逐一講解:
首先把概述做爲了第一部分,該系統平臺的研究背景和意義以及國內現狀做爲主要講述內容。
第二部分是研究方案和架構概述,主要闡述了本課題預計花費時間的設計方案、軟件開發設計方案以及設計目標,最後作了架構概述。
第三部分是需求分析,主要從用戶需求、性能需求和功能需求三方面闡述了需求板塊須要具有的東西。本部分還用了用例圖、用例說明增長相關人員的理解。
第四部分是概要設計,主要從Android端和服務器端分別闡述了功能整體設計,而後畫了數據庫E-R圖,最後是系統類圖和界面設計。
第五部分是詳細設計,主要從數據庫設計、CS協議通訊、時序圖三個方面闡述。
第六部分是系統實現,主要介紹了本次系統實現所用到的開發工具,並展現了開發界面總覽和核心功能代碼的講解。
第七部分是軟件測試,分版塊進行功能、性能、安全、交叉事件以及兼容性板塊進行測試並修改系統bug。
第8、九部分是本次畢業設計中的收穫和結論以及本身的感想。
最後是本文所參考的各類有價值的資料列表。
1)花費7天查閱了關於即時通信的資料以及小米推送的官方文檔,並對其進行分析整理。
2)花費10天查閱了一些技術博客和相關論壇以及GitHub上比較火的框架和項目。
3)花費15天進行數據庫設計,並對系統框架作一個全局性思考;
4)花費10天編寫後臺API數據接口,並作簡單測試;
5)花費1個月編寫Android端代碼,並對後臺數據可行性進行驗證修改;
6)最後進行常規測試,並在各大機器上運行,以保證不會出現致命Bug。
採用MVC開發模式,按照功能可劃分爲:發通知,發做業,互評點贊,圖片並茂,即時通信,小米推送等模塊。
功能模塊細化:
1)班級圈:班級圈包含教師可發放通知、做業,基本支持圖文並茂社區化和微視頻上傳。家長可查看本身班級的每一條信息,以及進行互評回覆點贊。
2)即時通信:即時通信板塊主要依賴於環信,在環信SDK的大前提下,引入基本的即時通信和音視頻通話。
3)社區板塊:社區板塊是用戶只要在一個班級便可進行相似朋友圈的交流,依然能夠進行互評點贊回覆。
4)發現板塊:發現板塊主要是爲加載一些廣告和活動。
5)個人板塊:個人板塊主要是提供用戶信息的更改設置等。
6) 推送板塊:當前推送繼承了Google推送、華爲推送和小米推送,以最大的可能提升推送接收率。
模塊功能實現的目標:
1)班級圈:保證班級圈數據的正常顯示,非本班人員應該不具有查看該班信息權限的能力。採用廣播、接口回調及其其它方式完成數據的傳遞和更新。
2)即時通信:保證音視頻通話的離線呼起,保證長鏈接的引用,保證用戶能正常收發消息。
3)社區:同班級圈。
4)發現:保證廣告的通暢性和可行性。
5)個人板塊:保證用戶信息的修改處理正常,作到信息不泄漏。
6)推送:保證推送成功率與正確率。
7)交互性良好:採用material design 風格設計,以及動畫效果的引用,使用戶和軟件具備更加青睞的交互體驗,並經過信息圈子推送,增長了用戶粘性。
8)代碼風格佳:在編碼過程當中,嚴格要求分包邏輯,採用模塊化分包,並對代碼進行合理的封裝處理,使代碼更加模塊化,讓其餘人能更易上手。
9)實用性:經過不斷的更新產品功能和接收用戶反饋,讓該產品更加地符合消費者思惟。
本系統採用C/S架構,分爲客戶端和服務器端。
客戶端被分爲了表現層、業務邏輯層和數據訪問層三個層面。
1.表現層:主要經過Android應用頁面來展現數據,以及一系列事件響應的UI控件。
2.業務邏輯層:主要用於業務邏輯的處理。一般由業務服務Service類和業務實體類Entity組成。
3.數據訪問層:本系統採用的數據庫是MySQL,採用XAMPP進行服務器搭建,採用PHP做爲後臺數據接口編寫,用花生殼作域名解析,以達到Android客戶端與服務器之間的訪問。
需求分析是「愛吖校推」應用分析的必要階段,下面分軟硬件需求、功能需求和用戶需求三方面作介紹,
本系統的軟硬件需求以下:
(1) 在Android平臺上運行,系統在4.0以上;
(2) 後臺數據庫:MySQL
(3) 開發環境:Java JDK1.7 ,Windows 10
(4)開發工具:Android Studio、Eclipse For PHP、XAMPP、
(5) 我的計算機:華碩飛行堡壘筆記本
「愛吖校推」做爲一款功能性軟件,其功能需求至關重要。如下爲「愛吖校推」的功能需求:
1)發通知、發做業
發通知和發做業,是學校教師特有的功能,教師能夠經過「愛吖校推」平臺進行通知和做業的發放,每當發一條信息,該班的全部人員即可以收到來自服務器的信息推送,提醒家長打開APP查看。每一條通知和做業家長均可以點贊和互評和回覆。這樣讓家長和學校的關係更貼切,也增長了信息篩選機制,從而避免了QQ羣、微信羣等多餘信息的影響。
2)傳視頻、傳照片
傳視頻是在社區和通知做業板塊均具有的功能,緊跟微視頻的時代步伐,教師能夠把孩子在學校的精彩表演,錄製下來發到班羣裏,家長即可以看到。家長也能夠把孩子在家裏作的有意義的事情放到社區,讓同一個班級的家長朋友們借鑑。良好的圖文並茂社區化,不只增進了家長和學校的交流,還增進了家長之間的聯繫和友誼。
3)即時通信
即時通信板塊是一個總體的板塊,基本包含QQ微信的全部功能,依然能夠發圖片、發消息、發語音、發定位、音視頻通話等。意在增長朋友之間的聯繫和家長和學校教師的一對一交流和多對多交流。
4)發現板塊
發現板塊主要是輪播的一些優秀且有利於教師家長的APP功能板塊,而且會組織一些活動,邀請你們參加。
5)離線推送
離線推送在家校互動平臺軟件中是一個必備功能,也算是一個核心功能,有它才能保證用戶真正收到來自教師發放的信息,以及即時通信過來的消息。同時音視頻通話等即時性要求較高的功能,也得依賴它。而且,推送信息到通知欄的方式向用戶傳遞信息,也是能夠增長用戶粘性。
在「愛吖校推」應用的開發過程當中,爲了儘可能知足學校老師和家長用戶的要求。目前獲得的需求有:
1) 圖片顯示清晰,但不能太大,以避免浪費流量;
2) 微視頻的壓縮要處理好,不能太浪費流量;
3) 即時通信要通暢;
4) 要具有離線推送,確保家長用戶能收到教師發送的做業和通知;
5) 要有權限管理,不能讓外班人員看到本班的消息;
6) 公告和做業不能插廣告;
7) 應用不能常常閃退;
8) 應用不能太大,也不能太佔內存;
9) 運行要流暢,不能出現卡頓現象;
圖1 登陸模塊用例圖
圖2 班圈模塊用例圖
圖3 消息模塊用例圖
圖4 發現模塊用例圖
圖5 個人模塊用例圖
表1 UC1用戶登陸用例
UC1用戶登陸 |
|
參與者 |
全部用戶、管理員能夠登陸 |
觸發條件 |
用戶點擊登陸按鈕 |
前置條件 |
用戶打開了APP |
後置條件 |
登陸到主頁,進入APP各大功能使用 |
正常流程 |
一、 打開APP; 二、 輸入帳號密碼開始登陸; 三、 登陸成功則進入主頁面 |
擴展流程 |
2a.輸入信息有誤
|
表2 UC2用戶註冊用例
UC2用戶註冊 |
|
參與者 |
全部用戶 |
觸發條件 |
用戶點擊註冊帳號 |
前置條件 |
用戶打開了APP,並點擊註冊帳號 |
後置條件 |
註冊成功,能夠登陸。 |
正常流程 |
1. 打開APP; 2. 點擊用戶註冊; 3. 輸入手機號; 4. 驗證成功,進入註冊頁面; 5. 輸入註冊信息 6. 註冊成功; |
擴展流程 |
3a.輸入信息有誤
4a.驗證碼驗證失敗
5a.輸入信息不正確
|
表3 UC3找回密碼用例
UC3找回密碼 |
|
參與者 |
全部使用APP的教師和家長 |
觸發條件 |
該用戶忘記了本身的密碼並但願能找回 |
前置條件 |
用戶在登陸頁面或者個人頁面點擊了找回密碼按鈕 |
後置條件 |
新密碼成功上傳服務器,找回密碼成功,能夠用新密碼登陸 |
正常流程 |
|
擴展流程 |
2a.輸入信息不符合產品提供的正確的邏輯規範
4a.驗證碼輸入不匹配;
|
表4 UC4發佈信息用例
UC4發佈信息 |
|
參與者 |
教師和發佈公告和做業,其餘用戶只能夠發佈圈子 |
觸發條件 |
用戶點擊發布信息按鈕 |
前置條件 |
用戶已經登陸成功 |
後置條件 |
發佈信息到對應的班級,而且班級的用戶都能收到信息,信息類型包括公告、做業、社區。其中教師發佈的公告和做業會推送到家長的手機上。 |
正常流程 |
|
擴展流程 |
6a.輸入信息有誤
|
表5 UC5查看全部信息用例
UC5查看全部信息 |
|
參與者 |
全部用戶、管理員 |
觸發條件 |
用戶滑動tab |
前置條件 |
用戶已經登陸成功 |
後置條件 |
當前班級的用戶能夠查看到該班級的公告做業和社區 |
正常流程 |
|
擴展流程 |
暫無 |
表6 UC6查看信息詳情用例
UC6查看信息詳情 |
|
參與者 |
全部用戶、管理員 |
觸發條件 |
用戶點擊一條信息 |
前置條件 |
|
後置條件 |
用戶查看到指定信息詳情 |
正常流程 |
|
擴展流程 |
4a.信息訪問錯誤,不存在,提示用戶該條信息不存在。 |
表7 UC7點贊評論回覆用例
UC7 點贊評論回覆 |
|
參與者 |
全部用戶、管理員 |
觸發條件 |
用戶點擊點贊或者輸入信息評論或回覆 |
前置條件 |
|
後置條件 |
|
正常流程 |
|
擴展流程 |
3a. 該信息不存在; 一、該信息已經被做者刪除,但前段未下拉刷新,彈出相應提示; |
表8 UC8查看聯繫人和會話用例
UC8 查看聯繫人和會話 |
|
參與者 |
全部用戶、管理員 |
觸發條件 |
用戶點擊消息 |
前置條件 |
用戶已經登陸成功; |
後置條件 |
無 |
正常流程 |
|
擴展流程 |
3a.獲取消息或聯繫人失敗,提示用戶數據獲取失敗,請稍後再試。 |
表9 UC9聊天用例
UC9 聊天 |
|
參與者 |
全部用戶、管理員 |
觸發條件 |
用戶點擊會話或者聯繫人 |
前置條件 |
|
後置條件 |
發起聊天,聊天對象收到本身發送的消息 |
正常流程 |
|
擴展流程 |
暫無 |
表10 UC10音視頻用例
UC10 音視頻通話 |
|
參與者 |
全部用戶、管理員 |
觸發條件 |
用戶發起音視頻通話 |
前置條件 |
|
後置條件 |
發起音視頻通話,聊天對象能接收到本身的音視頻呼起,對象能夠選擇接聽或者拒絕。 |
正常流程 |
|
擴展流程 |
4a.用戶可能收不到;
|
表11 UC11修改我的信息用例
UC11 修改我的信息 |
|
參與者 |
全部用戶 |
觸發條件 |
用戶點擊個人頁面的頭像或者點擊個人信息按鈕 |
前置條件 |
該教師或者家長已經登陸成功; |
後置條件 |
修正後的信息成功同步更新到服務器,提示用戶信息更改爲功。 |
正常流程 |
|
擴展流程 |
11a.數據更新失敗,提示用戶稍後再試。 |
表12 UC12修改孩子信息用例
UC12 修改孩子信息 |
|
參與者 |
全部用戶 |
觸發條件 |
用戶點擊個人頁面的孩子信息入口 |
前置條件 |
用戶已經登陸成功; |
後置條件 |
孩子信息修改爲功,並同步更新到服務器。 |
正常流程 |
|
擴展流程 |
5a.更新失敗,提醒用戶稍後再試。 |
表13 UC13退出登陸用例
UC13 退出登陸 |
|
參與者 |
全部用戶 |
觸發條件 |
用戶點擊個人頁面再點擊退出登陸 |
前置條件 |
用戶已經登陸成功; |
後置條件 |
用戶退出登陸,回到登陸頁面; |
正常流程 |
|
擴展流程 |
3a.退出登陸失敗,提醒用戶。 |
圖6 Android端功能整體設計圖
圖7 服務器端功能整體設計圖
圖8 數據庫設計E-R圖
圖9 APP端登陸類圖
圖10 APP端主頁類圖
圖11 APP端班圈類圖
圖12 APP端發佈類圖
圖13 APP端消息類圖
圖14 APP端發現類圖
圖15 APP端個人板塊類圖
圖16 圖片選取界面設計
圖17 登陸界面設計
圖18 手機號驗證界面設計
圖19 主界面設計
圖20 課程表界面設計
圖21 聯繫人列表界面設計
圖22 聊天界面設計
圖23 音頻呼叫界面設計
圖24 發佈信息界面設計
圖25 發現界面設計
圖26 個人板塊界面設計
圖27 按住拍界面設計
本軟件的數據庫爲MySQL數據庫,主要是搭建在XAMPP上結合PHP存在。主要分爲如下幾個數據表:
表14 用戶表設計
字段 |
屬性 |
備註 |
username |
varchar(20)(主鍵) |
帳號(手機號) |
password |
varchar(20) |
密碼 |
nickname |
varchar(20) |
用戶暱稱 |
type |
int(1) |
用戶類型 (1教師、2 家長、3管理員) |
classid |
int(10)(外鍵) |
班級id |
avatar |
Varchar(100) |
用戶頭像地址 |
birthday |
date |
生日,實際存儲爲時間戳 |
address |
text(null) |
用戶地址 |
child_name |
varchar(20) (null) |
孩子姓名 |
child_avatar |
text(null) |
孩子頭像地址 |
表15 班級信息表設計
字段 |
屬性 |
備註 |
classid |
int(10)(主鍵自增) |
班級id |
classname |
varchar(50) |
班級名稱 |
schoolname |
text |
學校名稱 |
表16 主貼表設計
字段 |
屬性 |
備註 |
mainid |
int(10)(主鍵自增) |
帖子id, |
classid |
int(10)(外鍵) |
班級id |
username |
varchar(20)(外鍵) |
用戶名 |
time |
timestamp |
發佈時間,實際存儲至關於long型時間戳 |
infotype |
int(1) |
主貼類型(1 表明公告 2 表明做業 3 表明動態) |
content |
text |
帖子內容 |
表17 評論表設計
字段 |
屬性 |
備註 |
infoid |
int(11)(主鍵自增) |
信息id |
mainid |
int(10)(外鍵) |
主貼id,用於識別隸屬於哪一條帖子的評論 |
username |
varchar(20)(外鍵) |
用戶名,用於識別發佈人信息 |
time |
bigint(20) |
發佈時間,long型時間戳 |
content |
text |
發佈內容 |
reply |
varchar(20)(外鍵) |
用戶表username做爲外鍵,用於回覆@功能 |
表18 點贊表設計
字段 |
屬性 |
備註 |
praiseid |
int(10)(主鍵自增) |
點贊信息id |
mainid |
int(10)(外鍵) |
主貼表外鍵,用於識別讚的是哪一條主貼 |
username |
varchar(20) |
用戶表外鍵,用於識別是誰點讚了 |
表19 用戶表設計
字段 |
屬性 |
備註 |
picid |
int(10)(主鍵自增) |
圖片id |
mainid |
int(10)(主貼表外鍵) |
主貼id |
url |
text |
圖片存放地址 |
說明:返回格式爲code,msg,data三個字段,code爲0是表明請求邏輯正確,-1爲請求異常;
一、獲取用戶是否註冊APP
接口地址: /user/usable_mobile.PHP
方式和返回: GET JSON
請求參數:
表20 獲取用戶是否註冊APP接口
名稱 |
類型 |
說明 |
mobile |
string |
用戶手機號 |
二、註冊
接口地址: /user/register.PHP
方式和返回: POST JSON
請求參數:
表21 註冊APP接口
名稱 |
類型 |
說明 |
username |
string |
用戶手機號 |
password |
string |
用戶密碼 |
nickname |
string |
暱稱 |
birthday |
string |
生日,傳遞long型時間戳 |
avatar |
string |
頭像上傳的地址 |
三、登陸
接口地址: /user/login.PHP
方式和返回: POST JSON
請求參數:
表22 登陸接口
名稱 |
類型 |
說明 |
username |
String |
用戶手機號 |
password |
string |
用戶密碼 |
四、重置密碼
接口地址: /user/reset_pwd.PHP
方式和返回: POST JSON
請求參數:
表23 重置密碼接口
名稱 |
類型 |
說明 |
username |
string |
用戶手機號 |
password |
string |
用戶新密碼 |
五、上傳頭像
接口地址: /user/avatar.PHP
方式和返回: POST JSON
請求參數:
表24 上傳頭像接口
名稱 |
類型 |
說明 |
file |
File |
須要上傳的文件 |
六、更新頭像url:
接口地址: /user/update_avatar.PHP
方式和返回: GET JSON
請求參數:
表25 更新頭像URL接口
名稱 |
類型 |
說明 |
username |
string |
用戶名 |
iconUrl |
string |
頭像地址 |
type |
int |
類型 1 爲本身 2 爲孩子 |
一、異步獲取主貼等信息
接口地址: /info/info_main.PHP
方式和返回: GET JSON
請求參數:
表26 異步獲取主貼接口
名稱 |
類型 |
說明 |
|
classid |
int |
班級id,用於識別可見度 |
|
infotype |
int |
信息類型 1公告2做業3動態 |
|
count |
int |
信息起始數,默認一次獲取10條,須要更改聯繫後臺 |
|
二、獲取發佈信息人的信息
接口地址: /info/get_user.PHP
方式和返回: GET JSON
請求參數:
表27 獲取發佈信息人的信息接口
名稱 |
類型 |
說明 |
username |
string |
用戶名 |
三、評論信息
接口地址: /info/insert_comment.PHP
方式和返回: POST JSON
請求參數:
表28 評論信息接口
名稱 |
類型 |
說明 |
mainId |
int |
主貼id |
username |
string |
用戶名 |
content |
string |
評論內容 |
reply |
string |
回覆人用戶名 |
四、更新點贊信息
接口地址: /info/praise.PHP
方式和返回: GET JSON
請求參數:
表29 更新信息接口
名 |
類型 |
說明 |
mainId |
int |
主貼id |
username |
string |
用戶名 |
該時序圖是實現用例UC1用戶的登陸。
1.用戶進入LoginActivity登陸界面後按照提示輸入帳號名(必須爲正確的手機號)和密碼(很多於6位)。
2.先採用StringUtil工具類對輸入數據進行驗證,再把LoginPresenter把輸入的數據傳遞給網絡交互類AppService,讓其與服務器進行數據交互並返回給LoginPresenter,經過回調機制讓View層顯示相關信息,如果登陸成功則正確跳轉到應用主頁面,不然顯示相關錯誤信息。
圖28 登陸時序圖
該時序圖是實現用例UC4發佈信息。
1.用戶進入發佈頁面,能夠輸入相關話題信息,也可上傳附件(微視頻和圖片不共存)。
2.若是上傳附件,則調用壓縮相關的工具類進行附件壓縮,若是壓縮失敗,則顯示相關錯誤信息。
3.未輸入信息沒法點擊發布,若是點擊發布按鈕,則讓ReleasPresenter處理相關邏輯,並把發佈話題的信息傳遞給AppService類作網絡訪問處理,服務器返回相關信息,採用回調機制讓View顯示出相關信息。
4.若是發佈成功,則返回到主頁面,併發送廣播提示主頁面進行數據刷新。
圖29 發佈時序圖
該時序圖是實現用例UC6查看信息詳情。
1.用戶在主頁面能夠看到話題相關信息(包括通知、做業、社區)。
2.若是點擊任何一條信息,則能夠跳轉到詳情頁面,能夠查看到相關點贊信息和評論信息。
3.點擊評論能夠對該條話題信息進行評論,點擊評論人可對該用戶進行回覆。
圖30 圈子信息時序圖
該時序圖是實現用例UC9聊天。
1.用戶能夠從會話頁面或者聯繫人頁面進入聊天頁面ChatActivity。
2.能夠發送任何的文本消息,也能夠點擊下方「加號」按鈕進行語音圖片視頻等文件的發送。
3.能夠直接調用音視頻通話,向對方發起通話。
4.任何的與服務器交互邏輯均交給EMClient類進行處理。
5.被呼叫的用戶能夠選擇拒絕音視頻通話並把相關信息返回給EMClient類。
6.監聽類收到EMClient返回的信息後處理相應回調,顯示相關信息。
圖31 聊天時序圖
Android Studio :Android Studio 是Google推廣的一款全新的Android開發工具,採用全新的Gradle方式進行編譯,同時對原有的Eclipse開發的項目進行了支持。在2016年年末,Google宣佈中止對Eclipse的支持與維護,完全地宣佈了Android Studio做爲「Google親兒子」的地位。其強大的市場佔有率成爲了使用趨勢,咱們不能墨守成規,須要向着新趨勢看齊。
XAMPP: XAMPP(Apache+MySQL+PHP+PERL)原來的名字叫 LAMPP,但最新的幾個版本被改名爲XAMPP,主要是爲了不誤解。它做爲一款建站集成軟件包,功能很是完善,其強大的兼容性更是征服了用戶,不只提供了Windows、Mac等主流操做系統,更是對Linux、Solaris等其它操做系統作了支持。更完美的是,它還支持包含簡體中文、繁體中文、英文、韓文等多國語言包。但XAMPP最著名的仍是它的便捷性,使用XAMPP只須要下載、解壓、啓動三個步驟就能讓Apache服務器運行在機器上,而且還支持讀取PHP文件以及集成了MySQL的使用。 Eclipse For PHP:這款軟件是Eclipse分支下專用於開發PHP的一款IDE,支持PHP5和PHP7,在這裏,咱們主要用它來開發後臺接口板塊。
圖32 Android 源碼分包預覽
圖33 Android 資源文件預覽
圖34 PHP端代碼總體預覽
圖35 數據庫操截圖
項目中的圖片壓縮來源於我GitHub已經開源的一個開源庫,目前項目已經獲得超 700 Stars,主要採起BitmapFactory的內部類Options以及Bitmap下的createScaleBitmap方法對圖片進行質量壓縮和尺寸壓縮。
思路:
1)Bitmap是一個至關大的對象,特別容易致使OOM,因此咱們在壓縮的時候並不能直接採用Bitmap,而採用BitmapFatory.Options。它有一個至關強大的屬性:inJustDecodeBounds,當這個屬性爲true的時候,調用decode前綴的方法返回的就不是一個完整的Bitmap對象,而是null。由於它禁止這些方法爲Bitmap分配內存,當設置這個屬性爲true時,便會複製Options的三個屬性,它們分別是outWidth,outHeight和outMimeType。至關於不讀取這個圖片,卻獲取到了它的參數,的確很厲害。
2)另一個不得不說的屬性就是inSampleSize了,能夠理解爲壓縮比率,設置好這個比率,就能調用decodeXXXX方法得到縮略圖了,若是圖片大小都一致,則能夠定死它。可問題是咱們的圖片大小一般是不一致的,那咱們壓縮的重中之重就是得到這個正確的比率。所以,我們徹底可以通過咱們想要的長寬,經過屢次循環比對,從而達到等比例壓縮。
3)然而, inSampleSize官方註釋告訴咱們一個必須注意的點:由於inSampleSize只能是2的整數次冪,意味着如何咱們經過循環算出來inSampleSize爲6的話,這時候只能向下取得整數次冪,也就是4。這樣明顯是達不到咱們想要求的標準的。
4)Bitmap的createScaleBitmap這個方法成功消除了咱們的焦慮,咱們能夠借用這個方法把咱們以前獲得的較大的縮略圖進行二次縮小,直到徹底符合咱們的要求。
核心代碼爲:
【圖片太長,這裏不截圖,請異步GitHub】
圖片選取來自於我維護的一個開源庫ImagePicker,目前GitHub Star數超過1300+,主要經過從數據庫讀取全部圖片信息並返回到一個List中,該List將把全部圖片的path存儲在一塊兒,而後把這些圖片放在RecyclerView中顯示,項目UI徹底仿照微信作處理。爲了解決Intent傳值限制,我在項目中採用單例加鎖的方式得以解決。
針對Android的適配上也是下了很多功夫,主要表如今Android 6.0 的動態權限處理,以及Android 7.0的相機打開限制,固然還有必不可少的MIUI系統坑和三星機器的圖片旋轉問題。
下面談下解決方案:
1) 6.0動態權限處理:在Android 6.0 (API 23)開始,Android開始引入動態權限處理,即除了在以前的AndroidManifest.xml文件中申明權限,還須要在使用到權限的時候彈出用戶是否受權的框。只須要重寫onRequestPermissionsResult方法便可。示例代碼以下:
【圖片太長,這裏不截圖,請異步GitHub】
2) 對於調用系統相機拍照後圖片旋轉:
常常會遇到一種狀況,拍照的時候看到照片是正的,可是當APP獲取到這張圖片的時候,卻發現旋轉了90度(也有多是180,270,不過90度比較多見,這應該是手機傳感器致使的)。爲了解決這種不必定在全部機器上都出現的問題,咱們能夠引入Android系統提供的ExifInterface類來解決各個屬性的操做。ExifInterface能夠不用加載圖片就獲取到圖片的長寬、旋轉角度等多種屬性,咱們能夠經過ExitInterface獲取圖片的旋轉角度degree來進行處理,當知足degree不爲0的時候,調用Matrix的postRotate進行角度旋轉,核心代碼爲:
【圖片太長,這裏不截圖,請異步GitHub】
3)對於部分機型調起相機會回不去APP的適配處理(拍完照閃退問題):
這也是相機適配中必須處理的地方,因爲Android系統廠商的ROM不一致,會讓一些ROM對自帶相機應用作優化,當某個APP經過Intent進入相機拍照界面時,系統會把這個APP最上層的Activity銷燬回收,只須要重寫onSaveInstanceState和onRestoreInstanceState方法對數據進行恢復和保存便可,核心代碼爲:
【圖片太長,這裏不截圖,請異步GitHub】
4)Android 7.0調用系統相機的處理:
因爲Android 7.0 手機開始推廣,因此咱們也不得不處理7.0的權限問題。在Android 7.0 之後,file://不被容許做爲一個附件的Uri的意圖,不然會拋出FileUriExposedException,在這樣的狀況下,咱們只須要用FileProvider便可解決。核心代碼以下:
<provider
Android:authorities="${APPlicationId}.provider"
Android:name=".ImagePickerProvider"
Android:exported="false"
Android:grantUriPermissions="true">
<meta-data
Android:name="Android.support.FILE_PROVIDER_PATHS"
Android:resource="@xml/provider_paths"/>
</provider>
【圖片太長,這裏不截圖,請異步GitHub】
基於Android等移動終端平臺的APP軟件測試與傳統的軟件測試不一樣,它不只要求兼容性良好,並且要求響應時間要在必定的限制範圍。好比用戶的操做響應時間通常不能超過3-5秒,APP啓動時間也不能太長。而對於Android操做系統,龐大的第三方廠商定製,致使Android系統各有差別。一個APP軟件必須知足不用的屏幕分辨率都能正常顯示,而且可以正確的完成相應功能。若是在某個環境下,界面功能顯示不全,則會致使軟件功能沒法正確使用,也就失去了安裝此軟件的意義,因此對其兼容性的要求也是很重要的一個方面。
功能模塊的測試是最基本的測試。我經過找出APP的測試點,而後採用兩款手機,小米3S(Android 5.0)和小米5S(Android 7.0)以及Windows抓包工具Fidder分別對「愛吖校推」的功能模塊和網絡接口進行完整測試,在測試過程出現了幾個小問題。
1)圖片選擇頁面出現選擇異常,然後得以解決,由於導包錯誤,致使指向了另一個文件。
2)發佈信息後沒有刷新頁面的Bug,後面採用廣播提醒UI刷新得以解決。
在解決完相關bug後,進行了新一輪的測試,下面是簡單的測試狀況:
該模塊測試主要是驗證用戶的註冊登陸是否能正常使用,任何不正確邏輯都應該給出相應的提示。在註冊時,手機號必須符合規範,密碼不得少於6位,不然提示輸入不規範。註冊時須要輸入兩次密碼,而且密碼相同,驗證碼輸入必須正確,不然提示相應錯誤。登陸板塊,第二次登陸應該自動登陸。
表30 用戶登陸註冊模塊測試
測試項目 |
測試方法 |
預期結果 |
結論 |
用戶註冊 |
在註冊界面輸入用戶名,密碼,其餘信息(符合要求) |
註冊成功 |
與預期結果一致 |
用戶註冊 |
在註冊界面不輸入內容或者輸入信息不符合要求 |
註冊失敗 |
與預期結果一致 |
用戶登陸 |
在登陸界面輸入用戶名,密碼,且用戶名和密碼匹配 |
登陸成功 |
與預期結果一致 |
用戶登陸 |
在登陸界面不輸入內容或者輸入信息不正確 |
登陸失敗 |
與預期結果一致 |
用戶登陸 |
沒有退出當前帳號,第二次進入該系統 |
自動登陸成功 |
與預期結果一致 |
該模塊測試主要是驗證可否正常發佈信息和上傳圖片及微視頻,當沒有輸入信息時候應當不能點擊發送按鈕。附件上傳前要注意壓縮,而且上傳後應該在班圈信息中獲得正常顯示,中間有任何出錯須要提示相應錯誤。並且在6.0以上系統的手機應該動態申請權限。在發佈通知或者做業頁面,應當發起推送到該班級圈子下的家長手機中。
表31 信息發佈模塊測試
測試項目 |
測試方法 |
預期結果 |
|
結論 |
信息發佈 |
不輸入任何文字點擊發布 |
發佈按鈕不能點擊 |
|
與預期結果一致 |
信息發佈 |
輸入信息點擊發布 |
發佈成功,班圈顯示刷新顯示本條內容 |
|
與預期結果一致 |
信息發佈 |
點擊圖片上傳,進入圖片選擇頁面,選擇後點擊肯定返回 |
選擇圖片後在信息發佈頁面能顯示正常的圖片信息,而且首次使用該功能應該彈出申請權限的對話框 |
|
與預期結果一致 |
信息發佈 |
點擊微視頻上傳,進入微視頻錄製頁面,點擊上傳後返回 |
信息發佈頁面正常顯示該條微視頻的縮略圖,點擊縮略圖能正常播放視頻,首次使用該功能應該彈出動態申請權限的對話框 |
|
與預期結果一致 |
信息發佈 |
發佈信息,查看Fidder抓包狀況 |
Fidder抓包信息應當顯示和接口預期一致 |
|
與預期結果一致 |
信息發佈 |
發佈班級通知或者做業的時候,查看Fidder抓包狀況和該班級圈子的家長用戶手機狀況 |
Fidder抓包信息應該和接口預期一致,而且該班級圈下的家長應該收到信息推送 |
|
與預期結果一致 |
該模塊測試主要是測試信息可否正常地點贊評論回覆,在該功能中,若是本用戶以前未點贊(灰色),應當把點贊按鈕置爲點贊狀態(紅色),點贊數+1。點擊班圈某條信息,能夠正常進入到該信息的詳情頁面,並能夠評論,返回後正常顯示相關信息。
表32 信息交流模塊測試
信息交流 |
測試方法 |
預期結果 |
結論 |
信息交流 |
點擊班圈的某條信息 |
應該能正常進入詳情頁面 |
與預期結果一致 |
信息交流 |
點擊點贊按鈕 |
在未點讚的時候應該爲灰色,點贊後應該爲紅色,能夠取消點贊,相應數目應該變化 |
與預期結果一致 |
信息交流 |
點擊評論按鈕 |
進入信息詳情頁面,而且彈出鍵盤 |
與預期結果一致 |
信息交流 |
點擊評論的人 |
應該直接開始彈出軟鍵盤,而且置爲回覆該用戶的狀態 |
與預期結果一致 |
信息交流 |
點擊返回 |
若是該條信息詳情有所更新,應當提醒班級圈正常顯示點贊狀況和評論數目狀況 |
與預期結果一致 |
即時通信模塊測試主要是測試添加好友,音視頻通話,聊天,發送附件,好友列表等可否正常顯示,以及APP置於後臺可否正常收到離線推送的即時通信消息。
表33 即時通信模塊測試
即時通信 |
測試方法 |
預期結果 |
結論 |
即時通信 |
點擊消息Tab |
能查看到最近聯繫人 |
與預期結果一致 |
即時通信 |
點擊聯繫人Tab |
能正常顯示聯繫人相關信息 |
與預期結果一致 |
即時通信 |
點擊某條會話或者聯繫人 |
能正常進入聊天頁面,並能正常顯示信息和聊天 |
與預期結果一致 |
即時通信 |
點擊音視頻通話 |
進入音視頻通話頁面,被呼叫用戶應當能正常收到此信息,並可選擇掛斷,發起者能夠收到用戶B接受或者拒絕的反饋,如果接受,應當正常進行音視頻聊天 |
與預期結果一致 |
即時通信 |
用戶B應用置於後臺,用戶A給用戶B發送文本消息 |
用戶B手機能收到信息推送 |
與預期結果一致 |
即時通信 |
用戶B應用置於後臺,用戶A向用戶B發起音視頻呼叫 |
用戶B應當直接呼起音視頻通話頁面,並能選擇接受或者拒絕 |
與預期結果一致 |
性能測試須要驗證APP在各類外界壓力下是否能正確響應;在執行單一操做時候的響應時間;重複操做一功能,系統資源佔用狀況;咱們在項目中採用了LeakCanary開源框架,並把它移植到項目中檢查內存泄漏狀況。而且使用Android內存泄漏分析工具(MemoryAnalyzer)檢測內存使用狀況,最終經過分析優化了下面兩個方面:
1)圖片壓縮不要將整個圖片以Bitmap讀入內存,防止OOM的發生,替換爲ExitInterface類獲取圖片信息,並採用BitmapFatory的decodeXXX方法以及Bitmap的createScaleBitmap進行尺寸壓縮,最後再進行質量壓縮得以解決。
2)項目中有些地方採用了static靜態對象,持有Context等致使內存久久不能釋放,後面替換了ApplicationContext得以解決。
3)測試過程當中發現啓動白屏現象較爲嚴重,因此增長閃屏頁得以緩解。
隨着移動互聯網的飛速發展,而做爲產業模式下的移動平臺,天然備受關注,依託此平臺的APP的安全性進而成爲人們的焦點。因此我對軟件權限等進行了細緻檢查,獲得如下結果:
1)沒有任何的泄密權限或者非法訪問狀況;
2)沒有出現任何的自啓動,沒有捆綁其餘任何軟件;
3)數據加密均正常,不存在泄密危險。
交叉事件測試,又叫事件或者衝突測試。意思是當APP在運行中,與此同時被另外的事件干擾,好比接入電話,查看短信後是否會致使APP崩潰或者數據丟失等異常。若是執行干擾的衝突事件後,應用APP依然能正常運行,不會出現崩潰、終端死機或者丟失數據等問題,則視爲咱們的交叉事件測試經過。
在交叉事件測試中,我着重檢查了幾個方面:
APP運行時,前臺後切換或者橫豎屏切換出現了數據的丟失,通過修改後得以解決;
APP運行時,能正常接收電話和短信;
運行「愛吖校推」,並不會影響其餘功能的使用,依然能正常的查看QQ消息、微信消息等。
在Android衆多的第三方定製系統的大背景下,各類各樣奇葩的兼容性問題必定存在,雖然在咱們開發中採用的測試真機是公認最容易出問題的MIUI手機,但依然不能以偏概全,在兼容性測試階段,我採用騰訊雲真機租用作了基本全部定製系統的兼容性測試。在兼容性測試中,我着重處理了:
Android 7.0 後不能直接經過Uri調用系統相機,檢查出問題後,採用了文件FileProvider得以解決。
在三星手機的測試中,出現了拍照後旋轉問題,最後在代碼中經過ExitInterface等操做解決了這個問題。
8 結論
本次畢業設計針對愈來愈被看好的「互聯網+」教育,着眼於促進教育現代化發展,增強學校與家長的溝通交流。設計過程當中採用較多的Design美學理念和動畫效果,增長用戶粘性。提供推送服務,極大的知足了用戶不丟失重要班級信息。社區化的設計,幫助用戶羣體更好的交流。
因爲各方面的緣由和經驗匱乏等問題,本應用的一些細節處理還不那麼完美,但我依然會完善下去。開發這款應用,讓我學到不少,好比不少當前Android火熱的框架,Retrofit、Rx、即時通信、推送以及圖片壓縮等,尤爲是後臺板塊的學習,PHP做爲當前比較熱門的語言,我直接從零學習到一步一步搭建起本身的後臺,收穫巨大。
9 謝辭
感謝本身最近一學期來的努力與付出,讓本身按時完成了畢業設計和畢業論文的撰寫。
感謝個人指導老師夏羽老師,夏羽老師一貫嚴謹認真的工做態度深深的影響了我,是他,在百忙中還與我從論文選題就開始共同討論,最後咱們共同選擇了家校互動這個項目。夏老師的成熟穩重把我從遇到問題就如熱鍋上的螞蟻引入到本身冷靜分析問題。在畢業設計的編寫中,在我遇到難題遲遲不能解決的時候,又是夏羽老師的自告奮勇爲我答疑解惑,併爲我提供相關資料。
感謝四年來全部教過個人老師,感謝大家的不辭勞苦,辛勤教誨,讓我從計算機文盲走到如今。
同時,感謝個人同窗們,四年同學,終身爲友,今天咱們在此同窗,明天咱們團結向上!
參考文獻
[1] 明日科技.Android從入門到精通[M].北京:清華大學出版社,2012.9
[2] 郭霖.第二行代碼[M].北京:清華大學出版社,2016.11
[3] 李剛.瘋狂Android講義(第3版)[M].北京:電子工業出版社,2015.
[4] 郭金尚.Android經典項目案例開發實戰寶典[M].北京:清華大學出版社,2013.9
[5] 劉金橋. 基於web的貝佳寵物醫院管理系統設計與實現 2015-06-03
[6] 許瑾.第一次開發Android程序的歷程[J]. 科技資訊,2014.29.20
[7] 丁麗萍.Android操做系統的安全性分析[J].信息網絡安全,2012.3:58-60
[8] 王珊.數據庫系統概論.北京:電子工業出版社,2015
[9] (美)贊德斯徹.深刻PHP:面向對象、模式與實踐(第3版)[M].機械工業出版社,2009.4
[10] 楊宇.PHP典型模塊與項目實戰大全[M].清華大學出版社,2012.1
[11] (美)林恩.貝伊利,邁克爾·莫里森着蘇金國,徐陽譯O’Reilly:HeadFirst PHP & MySQL(中文版)中國電力出版社2010 386
[12] 馬千里. 基於安卓手機的「視界」應用程序的設計和實現2016-05-31