登錄注冊(cè)邏輯梳理
登錄主要就是考慮幾個(gè)
UI控件的聯(lián)動(dòng)反應(yīng)尾组，至于如何船體聯(lián)動(dòng)信息，不就是靠RAC來(lái)處理么示弓，首先說(shuō)一下所有的UI空間包括讳侨，用戶名輸入框、密碼輸入框奏属、登錄按鈕跨跨。登錄界面最核心的元素就三個(gè)，如何處理三個(gè)
UI元素的聯(lián)動(dòng)就是RAC信號(hào)需要考慮的囱皿。-
聯(lián)動(dòng)反應(yīng)總共包括：
用戶名輸入框的輸入內(nèi)容每輸入一個(gè)字符就判斷一次歹叮，判斷的標(biāo)準(zhǔn)包括字符最低數(shù)量和字符最高數(shù)量、首位字符是否是
1铆帽。如果首位字符不是1，那么立馬提示用戶德谅，請(qǐng)輸入電話號(hào)碼爹橱，或者說(shuō)根本第一個(gè)數(shù)字就只能輸入1，其它的數(shù)字都輸入不了窄做，接下來(lái)愧驱，在輸入第2位數(shù)字到第10位數(shù)字的時(shí)候發(fā)送的信后都過(guò)濾掉，不發(fā)送椭盏，一旦輸入第11位字符组砚，立馬假設(shè)用戶輸入的就是電話號(hào)碼，開(kāi)始進(jìn)入RAC的map遍歷掏颊，驗(yàn)證輸入的這11個(gè)字符是否是一個(gè)合法的電話號(hào)碼糟红。如果合法返回
YES信號(hào)，如果不合法返回NO信號(hào),那么都有誰(shuí)訂閱這個(gè)用戶名輸入框的信號(hào)呢乌叶，自然首先就是輸入框的背景顏色屬性與這個(gè)用戶名輸入框的信號(hào)做了綁定盆偿，一旦返回YES信號(hào)，立馬通過(guò)三目運(yùn)算符改變用戶名輸入框的顏色准浴，表示用戶名輸入的電話號(hào)碼是合法有效的事扭，同時(shí)將密碼輸入框作為鍵盤(pán)的第一響應(yīng)者，這樣就不用用戶手動(dòng)撤銷(xiāo)鍵盤(pán)乐横，然后在點(diǎn)擊密碼輸入框重新開(kāi)啟這個(gè)鍵盤(pán)了求橄，大大優(yōu)化用戶體驗(yàn)今野。如果在控制器直接就map遍歷用戶名輸入框的信號(hào)，這樣確實(shí)很簡(jiǎn)單罐农，但是条霜，這就沒(méi)有體現(xiàn)出使用MVVM最大化程度上優(yōu)化控制器的目的。限定用戶名輸入框最高輸入
11位數(shù)啃匿，含很簡(jiǎn)單蛔外，一旦超過(guò)11位數(shù)，立馬就不允許輸入溯乒，獲取說(shuō)輸入后置是顯示前11位數(shù)夹厌，后面的自動(dòng)刪除。
StoryBoard
為了不破壞
StoryBoard的完整性裆悄，決定按鈕點(diǎn)擊后立馬跳轉(zhuǎn)控制器矛纹，但是驗(yàn)證碼輸入是否正確將沒(méi)法判斷，最好的解決方案就是想搜索那樣光稼，只要輸入了6個(gè)數(shù)字或南，就進(jìn)行驗(yàn)證碼的校正請(qǐng)求。storyBoard跳轉(zhuǎn)之前執(zhí)行判斷艾君，判斷是否驗(yàn)證碼合乎身份采够，如果合法，繼續(xù)跳轉(zhuǎn)冰垄，如果不合法蹬癌，就停止跳轉(zhuǎn)，問(wèn)題是不論驗(yàn)證碼合不合法虹茶，怎么都條控制器呀逝薪，這就不科學(xué)了，盡管即將跳轉(zhuǎn)時(shí)蝴罪，可以給控制器傳遞點(diǎn)數(shù)據(jù)董济，但是，依然不能解決跳轉(zhuǎn)中止要门。當(dāng)我用代碼校驗(yàn)驗(yàn)證碼成功跳轉(zhuǎn)
Login的StoryBoard的控制器虏肾，出現(xiàn)的問(wèn)題是，居然控制器上什么也沒(méi)有暂衡，這是什么鬼询微？難道我創(chuàng)建了一個(gè)新的控制器么，這可咋整狂巢，一定是的撑毛，不然怎么會(huì)什么也沒(méi)有？對(duì)比了，以為是沒(méi)有在使用StoryBoardID前打上勾藻雌，但是發(fā)現(xiàn)雌续，打上勾依然沒(méi)用。原本以為是沒(méi)有創(chuàng)造了新的控制器胯杭，但是我看控制器的背景
View驯杜，又真的是一點(diǎn)疑問(wèn)也沒(méi)有，只是輸入框這些玩意兒不知道去哪里了做个，簡(jiǎn)直了鸽心，問(wèn)題出在哪里呢坞琴？什么線索燕锥。原來(lái)是ID重復(fù)了，換了一個(gè)獨(dú)一無(wú)二的ID就什么問(wèn)題沒(méi)有了圆兵。
請(qǐng)求頭的意義太闺？
傳入
UserId是因?yàn)榉?wù)器想要知道這個(gè)請(qǐng)求是誰(shuí)發(fā)的傳入
Token是想判斷當(dāng)前UserID用戶是否有資格來(lái)發(fā)送這個(gè)請(qǐng)求傳入設(shè)備的唯一
ID是為了通知推送密碼必須
MD5加密糯景，否則反饋參數(shù)錯(cuò)誤
猿題庫(kù)網(wǎng)絡(luò)請(qǐng)求設(shè)置BaseUrl無(wú)效？
無(wú)論
BaseUrl最后有沒(méi)有/字符省骂，三方庫(kù)都會(huì)構(gòu)造一個(gè)/字符蟀淮，所以detailUrl的前面一定不能有/字符.三方庫(kù)沒(méi)有對(duì)
DetailUrl的首字符/判斷，只要出現(xiàn)兩個(gè)//字符钞澳，直接就忽略了后面的detailUrl
登錄
判斷登錄狀態(tài)怠惶。在
BaseViewModel里面聲明并實(shí)現(xiàn)judgeWhetherLogin判斷用戶是否已經(jīng)登錄的方法，本質(zhì)通過(guò)[UserManager currentUser]全局用戶管理類(lèi)的isLogin屬性來(lái)判斷轧粟。往往真相就是這么簡(jiǎn)單甚疟，用戶是否登錄這個(gè)信息竟然是以BOOL屬性值的形式存儲(chǔ)在[UserManager currentUser]，因?yàn)?code>[UserManager currentUser]全局單例類(lèi)模型對(duì)象存儲(chǔ)于沙盒之中逃延，這樣即使APP退出后依然記錄該用戶的登錄狀態(tài)。跳轉(zhuǎn)登陸控制器轧拄。
BaseViewModel里實(shí)例化LoginViewModel繼而跳轉(zhuǎn)到LoginViewController之中揽祥，把judgeWhetherLogin方法寫(xiě)在BaseViewModel里面帶來(lái)的好處可見(jiàn)一斑。判斷用戶是否登錄和跳轉(zhuǎn)到登錄控制器是綁定到一起的檩电，問(wèn)題在于跳轉(zhuǎn)控制器是需要導(dǎo)航控制器和目標(biāo)控制器的拄丰，如果說(shuō)目標(biāo)控制器可以通過(guò)類(lèi)名字符串轉(zhuǎn)類(lèi)
Class來(lái)實(shí)現(xiàn)，那么持有導(dǎo)航控制器的類(lèi)則成了綁定登錄控制器跳轉(zhuǎn)的最好選擇俐末，在MVVM結(jié)構(gòu)之中料按，控制器ViewController和ViewModel都可以實(shí)現(xiàn)控制器的跳轉(zhuǎn)，但是ViewModel持有的BaseNav是經(jīng)過(guò)加工的導(dǎo)航控制器卓箫，因此可以給控制器的跳轉(zhuǎn)封裝一些自定義的內(nèi)容载矿，比如說(shuō)可以把目標(biāo)普通控制器的構(gòu)造代碼統(tǒng)一封裝到我們加工過(guò)的BaseNav里面，如此一來(lái)烹卒，就可以通過(guò)傳入目標(biāo)控制器的類(lèi)的字符串名稱(chēng)來(lái)構(gòu)建目標(biāo)控制器了闷盔。還有弯洗，既然決定了通過(guò)
BaseViewModel操作BsaeNav屬性來(lái)跳轉(zhuǎn)控制器，那么把登錄控制器的跳轉(zhuǎn)寫(xiě)到BaseViewModel里面逢勾，如此輕松實(shí)現(xiàn)BaseViewModel的所有子類(lèi)直接調(diào)用父類(lèi)的方法跳轉(zhuǎn)登錄控制器牡整。既然跳轉(zhuǎn)登錄控制器通常和判斷登錄狀態(tài)始終綁定到了一起，干脆把這兩個(gè)方法封裝成一個(gè)方法
judgeWhetherLogin聲明并是實(shí)現(xiàn)在BaseViewModel里溺拱。如此一來(lái)逃贝，BaseViewModel的所有子類(lèi)都可以調(diào)用父類(lèi)判斷用戶是否登錄的方法，同時(shí)跳轉(zhuǎn)到登錄控制器的也不用寫(xiě)了迫摔。
