微信小程式之啟動頁的重要性
啟動頁在APP中是個很常見的需求,為什麼對於小程式來說也非常重要呢?首先我描述一下我在開發過程中遇到的一些問題以及解決的步驟,到最後為什麼要加啟動頁,看完你就明白了。
小程式的首頁需要展示使用者關注的小區資訊,意味著一開啟小程式我就得先執行登入的邏輯,只有登入了之後才能獲取使用者關注的小區資訊。
在小程式啟動的時候自動登入,目前沒獲取使用者資訊,所以不需要使用者授權,這個邏輯放在根目錄下的app.js的onLaunch方法中。只要啟動小程式就會執行onLaunch方法。
做完之後發現了一個很嚴重的問題,就是app.js的onLaunch方法確實會在小程式啟動的時候執行,但是首頁也會是在app.json檔案的pages中第一個頁面也會同時執行,它不是阻塞的。會導致一個問題就是首頁獲取關注資訊執行完了,登入的邏輯還沒完,獲取不到正確的資料。
於是把登入的邏輯放到首頁的onLoad方法中執行,在登入成功之後再去獲取關注的資料,這樣就能解決上面說的問題了。
後面又有一個需求,就是分享功能,分享出去的頁面中也需要用到使用者資訊,這個就尷尬了,分享出去的頁面,使用者進入的時候還是進入的這個頁面,不會執行首頁的邏輯,是拿不到使用者資訊的。
後面想了下,還是增加一個啟動頁來做中轉吧,登入的邏輯還是放到app.js中,只要小程式啟動了就可以執行,無論是第一次進入還是通過分享的頁面進入,都可以自動登入。
問題是如何實現阻塞功能,就是登入之後再去跳轉到其它的頁面,思路就是通過定時器的方式去檢測登入狀態,成功了之後再跳轉。
分享也是一樣,分享出去的地址不再是本頁面的地址,而是啟動頁的地址,帶一個引數,這個引數才是本頁面的地址,當用戶點選分享的小程式進入之後會先進入啟動頁,啟動頁中獲取引數,等待登入邏輯執行完成之後,再根據引數跳轉到分享的頁面。
啟動頁程式碼:
當檢查超過10秒鐘,登入資訊還獲取不到的時候就會給出提示,後續會加上一個讓使用者手動授權登入的頁面。
這種方式勉強能實現需求,但不是最好的方式,問題一看就知道了,如果加了啟動頁,意味著所有的入口都變成了啟動頁,就沒有必要通過定時去檢測了,直接將登入的邏輯放到啟動頁中來執行,在success中在做跳轉的邏輯,這樣的方式才是最好的,具體程式碼我就不貼出來,大家明白就好。
具體的分享頁面程式碼:
重點關注isshare=1這個引數,當直接開啟分享的頁面時,使用者點選左上角的返回按鈕,基於現有的邏輯會退回到啟動頁,因為是從啟動頁中轉過來的,這是有問題的,要麼就去掉這個返回按鈕,要麼就返回到首頁。
所以對於分享的頁面帶了一個引數識別,當是從分享頁面進來的時候返回就到首頁面。具體邏輯在頁面的onUnload函式中,在頁面解除安裝的時候進行跳轉:
以上就是啟動頁的作用以及需要啟動頁的一些背景,第一次開發小程式,總會碰到很多問題。
總結+分享=積累。