02 facebook退出登錄在哪里(登錄移動wlan如何退出)

（例如，通過Facebook，Twitter或Google+登錄），用戶可能會忘記他們之前用來注冊的服務是哪一個，會猶豫該選擇哪個登錄方式或者干脆放棄登錄。更糟糕的是，如果用戶選擇了錯誤的登錄服務提供商，而不是他們曾經注冊的服務，他們可能會再次注冊，從而創建了第二個賬戶。

雖然網站和APP會盡力去匹配來自不同服務提供商的賬戶，但是不能100%保證Twitter和Facebook賬戶是否屬于同一個人。所以，為了解決多賬號登錄問題，你應該保持用戶的登錄狀態直到他們主動選擇登出。需要登錄的用戶越少，登錄問題就越少。

另一個好的解決方案就是記住用戶。Quora在用戶重新登錄時，不需要用戶輸入密碼。用戶只需要點擊他的個人資料圖片或者用戶名，就可以登錄進網站。

設計“忘記密碼”流程

和人們有時候會忘了把錢包或鑰匙放在哪里一樣，用戶會忘記密碼。因此，登錄過程需要很好地處理這種情況。登錄表單中需要提供“忘記密碼”的入口讓用戶重置密碼。

不要僅在用戶點擊密碼輸入區域或者輸入了錯誤的密碼之后才出現“忘記密碼”入口。當用戶已經輸入電子郵件地址，然后使用“忘記密碼”功能，不要讓用戶在“忘記密碼”頁面重新輸入他們的電子郵件地址。不要通過電子郵件發送當前或者臨時密碼。

正確的做法是向用戶注冊的電子郵件地址發送重置密碼鏈接。此外，確保重置密碼的郵件盡快發送給用戶。（如果用戶不得不等很長時間才能收到重置密碼鏈接，他們會感覺沮喪和不耐煩）

如果用戶不能訪問他們注冊的郵箱，那么接下來能做的取決于你提供的服務類型：你可以前置一些安全問題，以此作為登錄憑證。總的來說，如果用戶忘記了密碼，讓“忘記密碼”的流程簡單點。

在鎖定賬戶之前告知用戶

為了防止暴力攻擊，用戶的賬戶通常會在多次登錄失敗后被暫時鎖定。這當然是一個必要的安全措施，但是一定要在鎖定賬戶前告知用戶。

Mailchimp在用戶第3次登錄失敗后，會告知用他們的賬戶再有9次登錄失敗后會被鎖定30分鐘。

總結

即使已經是很常見的網頁和APP的登錄功能，也可以通過巧思和設計來進行優化。但是，不要把這些解決方案當成救星，用來處理各種錯誤情況。最好的解決方案是，設計你的用戶界面和交互方式來避免錯誤的發生。

Medium

譯文地址：紫豆子設計站（買粉絲）

Android中判斷app何時啟動和關閉的技術研究

Android開發中不可避免的會遇到需要檢查app何時進入前臺，何時被用戶關閉。奇怪的是，要達到這個目的并不容易。檢查app第一次啟動并不難，但要判斷它何時重新打開和關閉就沒有那么簡單了。

這篇文章將介紹一種判斷app打開，重新打開和關閉的技術。

讓我們開始吧

判斷一個app打開和關閉的關鍵在于判斷它的activities是否正在前臺顯示。讓我們先從簡單的例子開始，一個只有一個activity的app，而且不支持水平模式。這樣想要判斷app是打開還是關閉只需要檢查activity的onStart和onStop方法即可：

[Java] 純文本查看 復制代碼

@Override

protected void onStart() {

super.onStart();

// The Application has been opened!

}

@Override

protected void onStop() {

super.onStop();

// The Application has been closed!

}

上面例子的問題在于當需要支持水平模式時該方法就失效了。當我們旋轉設備時activity將會重建，onStart方法將被再次調用，這時將會錯誤的判斷為app第二次被打開。

為了處理設備旋轉的情況，我們需要增加一個校驗步驟。當activity退出時啟動一個定時器，用于判斷短時間內app的這個activity是否又被啟動，如果沒有，說明用戶真的退出了這個app，如果重新啟動了這個activity，說明用戶還逗留在這個app中。

這種校驗方式也適用于擁有多個activities的app，因為從app的一個activity跳轉到另一個activity也可以用這種校驗方式來處理。

使用這個技術我創建了一個管理類，所有的activities在可見和不可見時都會通知這個管理類。這個管理類為每個activity處理上述的校驗步驟，從而避免錯誤的檢測。它也提供了發布訂閱（觀察者）模式，任何對app啟動和關閉感興趣的模塊都可以通過它來得到對應的通知。

這個管理類的使用分為三個步驟：

1）把它添加到你的工程中

2）Activities在可見性改變的需要發送通知

app中所有activities都要增加下面的代碼，用于可見性改變時通知管理類。最好的實現方式是把這段代碼加到工程的BaseActivity中。

[Java] 純文本查看 復制代碼

@Override

protected void onStart() {

super.onStart();

AppForegroundStateManager.getInstance().onActivityVisible(this);

}

@Override

protected void onStop() {

AppForegroundStateManager.getInstance().onActivityNotVisible(this);

super.onStop();

}

3）訂閱app的前臺可見性改變事件

在感興趣的模塊中訂閱app前臺可見性改變事件，application類的onCreate函數是一個不錯的地方，它可以保證每次app啟動和關閉，你都能得到通知。

public class MyApplication extends Application {

@Override

public void onCreate() {

super.onCreate();

AppForegroundStateManager.getInstance().addListener(this);

}

@Override

public void onAppForegroundStateChange(AppForegroundStateManager.AppForegroundState newState) {

if (AppForegroundStateManager.AppForegroundState.IN_FOREGROUND == newState) {

// App just entered the foreground. Do something here!

} else {

// App just entered the background. Do something here!

}

}

}

進一步的思考

有一些細節需要進一步討論，下面討論的幾點針對具體的應用可以做微調。

校驗時間

校驗定時器檢查app是否真的進入后臺的時間間隔是多少合適呢？上面的代碼設置為30秒，原因如下。

當你的app在運行時，可能存在第三方的activities會覆蓋全屏幕，一些常見的例子是Google應用內購買和Facebook登錄注冊頁面。這些情況下你的app都會被迫進入后臺，前臺用于顯示這些第三方頁面。如果把這種情況當做用戶離開了你的app，顯然是不對的。30秒超時設置就是用來避免這種情況的。例如當用戶在30秒內完成應用內購買，大部分用戶都可以做得到，那么就不會當做用戶突然離開app了。

如果你的app不存在上述這種情況，我建議可以把你的校驗時間設置為4秒，這樣對于低配設備當屏幕旋轉重新創建activity的時間間隔是合適的。

CPU休眠

可能存在的問題是當用戶關閉app或者app仍處于前臺時用戶鎖屏了，這時CPU可能不會等到定時器檢測就休眠了。為了保證這種情況下定時器能夠正常檢測用戶退出app，我們需要持有wakelock防止CPU休眠直到app關閉事件被確認。實踐中相比使用wakelock，這種情況并不算問題。

判斷app是如何啟動的

現在我們已經知道如何檢測app何時啟動和關閉，但我們不知道app是如何啟動的。是用戶點擊通知欄消息？還是點擊一個鏈接？亦或是他們直接通過桌面圖標或最近使用啟動？

跟蹤啟動機制

首先我們需要知道在哪里檢測app是如何啟動的。基于前面一個例子我們可以打印出app何時啟動，以及如何啟動。

public class MyApplication extends Application {

public final String TAG = MyApplication.class.getSimpleName();

public enum LaunchMechanism {

DIRECT,

NOTIFICATION,

URL;

}

private LaunchMechanism mLaunchMechanism = LaunchMechanism.DIRECT;

public void setLaunchMechanism(LaunchMechanism launchMechanism) {

mLaunchMechanism = launchMechanism;

}

@Override

public void onCreate() {

super.onCreate();

AppForegroundStateManager.getInstance().addListener(this);

}

@Override

public void onAppForegroundStateChange(AppForegroundStateManager.AppForegroundState newState) {

if (AppForegroundStateManager.AppForegroundState.IN_FOREGROUND.equals(newState)) {

很赞哦!（9242）