Tag: Programming

Authentication & WebView & React Native

May 29, 2019 by Hien Nguyen·Comments Off

You have an idea. You already had a responsive web app, it works well for mobile. It leads you to the thought of having a MVP mobile app to engage users: an app is built by embedded web-view. You also know React Native can help you build a cross-platform app. Very good solution: a React Native app with few WebView screens that point to correct links. Life is so easy, right? Unfortunately, it’s not.

Problems

You are right. It’s a great solution until you need to implement the authentication. There are at least 2 problems if your app requires user login.

Firstly, “remember me” doesn’t work although it works well on web. You need to enter credential whenever the app opens (in cold start).

Secondly, 3rd party authenticators like Google, Facebook… doesn’t work. You tap on “Login by Facebook”, Facebook login page is opened inside the app. Although you already logged in on Facebook app or OS browser, you need to enter Facebook credential whenever the app opens.

The reason is that WebView doesn’t share any data with OS browser. Each time the app starts, a “fresh” browser is initiated. It means there is no cookies, token, history… are stored by default.

There is only one weird function on your app while the rest are working perfectly. Yes, only one. But it kills your whole app. Do you know anyone who is willing to type username & password anytime he opens the app? Yes, if the app relates to very sensitive personal data like personal finance. But your app doesn’t.

Solutions

There are many solutions. I will describe the simplest one with less code change in your existing web app.

Facebook login

Let’s firstly solve the problem with 3rd party authenticators. I use Facebook as an example, you could treat others in the same way. The steps could be:

Handle event in WebView to detect user tapping on Facebook login button
Open client Facebook login, get the access token
Pass token to server to authenticate user

First step is setting up the Facebook SDK, please follow here: https://github.com/facebook/react-native-fbsdk

Second step is handling user tapping on Facebook login link on app, onNavigationStateChange of WebView is the good function to work on. Passing the token to server could be simply made by GET calling from WebView.

The code looks like:

import React from 'react';
import { View, ActivityIndicator } from 'react-native';
import { WebView } from 'react-native-webview'
import { LoginManager, AccessToken } from "react-native-fbsdk";

class App extends React.Component {
  webViewRef;
  constructor(props) {
    super(props);
    this.state = {
      facebookToken: null
    };
  }

  onNavigationStateChange(navState) {
    var url = navState.url;
    var self = this;

    if (url.includes('facebook.com')) {
      webViewRef.stopLoading();
    }

    if (url.includes('https://facebook.com') || url.includes('https://www.facebook.com')) {
      LoginManager.logOut()
      LoginManager.logInWithReadPermissions(["email", "public_profile", "user_link"]).then(
        function (result) {
          if (result.isCancelled) {
            if (webViewRef.canGoBack()) 
              webViewRef.goBack();

            self.setState({
              facebookToken: null
            })
          } else {
            AccessToken.getCurrentAccessToken().then(
              (data) => {
                self.setState({
                  facebookToken: data.accessToken.toString(),
                })
              }
            )
          }
        },
        function (error) {
          if (webViewRef.canGoBack()) 
            webViewRef.goBack();

          self.setState({
            facebookToken: null
          })
        }
      );
    }
  }

  render() {
    return (
        <View>
          <WebView ref={WEBVIEW_REF => (webViewRef = WEBVIEW_REF)}
              source={{ uri: (this.state.facebookToken) ? "https://yourcompany.com/FacebookNativeLogin?accessToken=" + this.state.facebookToken : "https://yourcompany.com/Login" }}
              onNavigationStateChange={this.onNavigationStateChange.bind(this)}
            />
        </View>
    );
  }
}

export default App;

import React from 'react';

import { View, ActivityIndicator } from 'react-native';

import { WebView } from 'react-native-webview'

import { LoginManager, AccessToken } from "react-native-fbsdk";

class App extends React.Component {

webViewRef;

constructor(props) {

super(props);

this.state = {

facebookToken: null

};

}

onNavigationStateChange(navState) {

var url = navState.url;

var self = this;

if (url.includes('facebook.com')) {

webViewRef.stopLoading();

}

if (url.includes('https://facebook.com') || url.includes('https://www.facebook.com')) {

LoginManager.logOut()

LoginManager.logInWithReadPermissions(["email", "public_profile", "user_link"]).then(

function (result) {

if (result.isCancelled) {

if (webViewRef.canGoBack())

webViewRef.goBack();

self.setState({

facebookToken: null

})

} else {

AccessToken.getCurrentAccessToken().then(

(data) => {

self.setState({

facebookToken: data.accessToken.toString(),

})

}

)

}

function (error) {

if (webViewRef.canGoBack())

webViewRef.goBack();

self.setState({

facebookToken: null

})

}

);

}

render() {

return (

<View>

<WebView ref={WEBVIEW_REF => (webViewRef = WEBVIEW_REF)}

source={{ uri: (this.state.facebookToken) ? "https://yourcompany.com/FacebookNativeLogin?accessToken=" + this.state.facebookToken : "https://yourcompany.com/Login" }}

onNavigationStateChange={this.onNavigationStateChange.bind(this)}

</View>

);

}

export default App;

There are some notes:

Line 20: we should let WebView stop loading to avoid strange UI: a popup of Facebook login on app on the top of Facebook web login screen (on app). It also stops WebView being redirected from https://facebook.com to https://m.facebook.com that lets the popup show twice.
Line 24: Facebook LoginManager caches the access token, calling logOut() before logInWithReadPermissions() helps app detects if user logout the app from other Facebook areas (web etc).
Line 64: you need to implement FacebookNativeLogin on server side then setting cookies etc.

Now it works? Yes, but not really. User is still required to press Facebook login when he opens the app. If you want “auto login”, componentDidMount could be a simple solution.

componentDidMount() {
  var self = this;
  AccessToken.getCurrentAccessToken().then(
    (data) => {
      if (data && data.accessToken) {
        self.setState({
          facebookToken: data.accessToken.toString(),
        })
      } else {
        self.setState({
          facebookToken: null
        });
      }
    }
  );
}

componentDidMount() {

var self = this;

AccessToken.getCurrentAccessToken().then(

(data) => {

if (data && data.accessToken) {

self.setState({

facebookToken: data.accessToken.toString(),

})

} else {

self.setState({

facebookToken: null

});

}

);

}

Remember me

Now it’s time for “remember me” function. The common solution is using the cookies. If you already had it running for web, your hands wouldn’t be much dirty. There is a simple solution with CookieManager, you could find it here: https://github.com/joeferraro/react-native-cookies

Well, let’s combine it with componentDidMount above:

componentDidMount() {
  CookieManager.get('https://yourcompany.com').then((res) => {
    if (res['.App.ApplicationCookie']) {
      this.setState({
        loggedIn: true,
        facebookToken: null
      });
    } else {
      var self = this;
      AccessToken.getCurrentAccessToken().then(
        (data) => {
          if (data && data.accessToken) {
            self.setState({
              loggedIn: true,
              facebookToken: data.accessToken.toString(),
            })
          } else {
            self.setState({
              loggedIn: false,
              facebookToken: null
            });
          }
        }
      )
    }
  });
}

componentDidMount() {

CookieManager.get('https://yourcompany.com').then((res) => {

if (res['.App.ApplicationCookie']) {

this.setState({

loggedIn: true,

facebookToken: null

});

} else {

var self = this;

AccessToken.getCurrentAccessToken().then(

(data) => {

if (data && data.accessToken) {

self.setState({

loggedIn: true,

facebookToken: data.accessToken.toString(),

})

} else {

self.setState({

loggedIn: false,

facebookToken: null

});

}

)

}

});

}

Some notes:

Line 3: replace it with your correct cookies
Line 5: I introduce loggedIn state because Facebook login is separated with your system username/password login. It lets you update uri in WebView of render() function above with a condition combined by loggedIn and facebookToken. But it’s not difficult, right? Hmm, loggedIn isn’t a good name.

Done? Almost. You could see it works really well on Android but not on iOS. In cold start, CookieManager.get() returns value on Android but doesn’t on iOS. Then storing and restoring cookies programmatically is a solution. AsyncStorage could help https://facebook.github.io/react-native/docs/asyncstorage.html. Just add the few lines of code to onNavigationStateChange to store the cookie and set it back on componentDidMount. Fortunately, CookieManager.set() only works on iOS.

Know issues

I hope it help you overcome the common issue of web-view app. I don’t want to put the setting cookies into existing functions because they are too long now. You should refactor it after getting it run.

Is the solution simple? Yes. Is it perfect? No. There are some small issues:

We call GET to FacebookNativeLogin with accessToken. Might POST be a bit better?
What if the cookies is expired? Is it good to still keep user login? A solution is storing username/password by AsyncStorage and injecting Javascript to auto fill username/password text fields. But I don’t prefer storing any data like that.

But if you are interested in those topics, I will go into the example next post.

1,991 total views, no views today

Singleton: dùng hay không?

May 23, 2018 by Hien Nguyen·Comments Off

Nhân tiện mọi người có vẻ hào hứng về chủ đề nho nhỏ này và đang viết được, viết nôt kẻo ít hôm lại lười.

Trả lời ngắn gọn là dùng. Dùng chứ. Nhưng dùng thế nào cho đúng thì phải hiểu rõ một chút. Bài viết này cố gắng cung cấp nhiều góc nhìn để cân nhắc.

Vì sao ra đời?

Trong GoF, Singleton được đưa ra với mục đích sau: “Ensure a class only has one instance, and provide a global point of access to it.” – “Đảm bảo một class chỉ có duy nhất một instance, và cung cấp một điểm truy cập duy nhất trên toàn cục tới instance.”

Cái gì hay?

Hay thì rõ rồi, nó cung cấp ý tưởng của việc một instance duy nhất, điều mà chúng ta gặp trong nhiều bài toán thực tế: một ứng dụng được khởi tạo, một cấu hình hệ thống, một logger… Tôi cá là nhiều người không biết tới Singleton thì không biết giải quyết bài toán này thế nào.

Runtime:
- Không giống như static trong class, object và các giá trị trong đó chỉ được khởi tạo khi cần thiết. Memory và cả CPU đều được tiết kiệm.
- Cho phép chủ động quản lý life cycle, giải phóng khi cần thiết.
Design:
- Abstract hơn sử dụng static trong class;
- Có khả năng thừa kế;
- Có thể kếp hợp với những design pattern khác.

Cái gì dở?

Dở thì cũng có, bởi vậy mới có nhiều tranh luận.

Tư tưởng: Singleton trong GoF dở cơ bản về tư tưởng bởi nó giải quyết 2 bài toán khác nhau (dù có vẻ liên quan): “Ensure a class only has one instance, and provide a global point of access to it.”
- Một class có duy nhất một instance;
- Cung cấp một điểm truy cập duy nhất trên toàn cục tới instance.
- Tác giả đã vô tình kèm cả lời giải trong bài toán với giả định: để có một điểm truy cập toàn cục duy nhất thì chỉ có duy nhất một instance được tạo ra từ một class. Bài toán “một điểm truy cập” có thể được giải quyết bởi Facade, Wrapper… không nhất thiết phải là Singleton.
Design:
- Coupling: Vì là global state nên các thành phần bị gắn chặt với nhau;
- Khó / không thể viết test;
- Viết dễ sai sót, để lại lỗ hổng (xem bài trước Singleton có thực sự dễ?).
Runtime:
- Không “thân thiện” với theading.

Nên dùng thế nào?

Như vậy, ta thấy rằng đa phần những thứ dở của design pattern này là ở tư tưởng global state. Vậy nên những ai yêu thích functional programming thì sẽ rất anti-pattern này. Cũng đúng thôi, GoF sinh ra cho OOP, không phải FP. Và thời đại của GoF (1994) cũng không quan tâm nhiều tới concurrency – bài toán trở thành rất cơ bản trong thời đại này. Bởi vậy, việc sử dụng Singleton có chút thay đổi. Có 3 điều cần chú ý:

Concurrency: Global state là điều tệ hại cho concurrency. Hãy giảm thiểu tối đa nếu có thể. Global state bẻ cong cách suy nghĩ về luồng và gây mệt mỏi cho việc debug trong concurrency. Nếu bạn muốn thiết kế hệ thống tối ưu hiệu năng và concurrency thì không sử dụng Singleton cũng là một ý hay.
Memory:
1. Lưu cái gì? Global state cũng là một ý hay vì khiến việc thiết kế và lập trình dễ dàng hơn, nó chỉ không hay khi bạn không cân nhắc tới nên lưu gì. Rất nhiều thứ có thể nhìn dưới góc độ một instance nếu chúng ta không có khả năng khái quát hoá. Logger là Singleton không? Hay có errorlog, accesslog? Database là single thì lưu cả database? Hay chỉ connection? Hay chỉ connectionString? Lưu ít nhất có thể.
2. Lưu khi nào? Nhiều người hay gắn Singleton với life cycle của cả ứng dụng, kèm theo việc lưu trữ nhiều, hoặc giữ strong reference dẫn đến GC không thể hoạt động; sớm muộn gì cũng gây ra memory leak. Khởi tạo muộn nhất có thể, giải phóng sớm nhất có thể.
Language: Cần lưu ý cách sử dụng trong từng ngôn ngữ (xem bài trước Singleton có thực sự dễ? và Singleton:threading() in Java), mỗi ngôn ngữ khác nhau sẽ có vấn đề khác nhau. Dù design pattern là mức thiết kế song đừng mang nguyên cách cài đặt từ ngôn ngữ này sang ngôn ngữ khác, hãy nhìn vào diagram và đặc trưng ngôn ngữ.

Trên đây là một số góc nhìn, gợi ý để bạn dùng Singleton đúng hơn. Không có đúng hay sai khi dùng Singleton, dùng đúng hay không mới là vấn đề.

2,318 total views, no views today

Singleton.threading() in Java

May 23, 2018 by Hien Nguyen·Comments Off

Bài trước về Singleton có thực sự dễ, tôi nhận được vài comment rất chuẩn về cách cài đặt xử lý với theading. Vì bài trước tập trung nói về Singleton và các vấn đề có thể gặp phải với reflection, threading, serializable… nên tất cả những giải pháp đưa ra chỉ dừng ở mức ý tưởng không làm bạn đọc phân tâm. Bài này nói rõ hơn về xử lý theading khi cài đặt Singleton.

Tôi sẽ đi vào cài đặt “chuẩn” đã đưa cuối bài Singleton có thực sự dễ trước:

public class AppConfig {
    private static volatile AppConfig self;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

public class AppConfig {

private static volatile AppConfig self;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

Khi phân tích về threading trong bài trước bạn thấy tôi viết “Vậy nên cần phải synchronized việc tạo object.”. Nếu để ý kỹ, có 2 phần thay đổi:

synchronized được thêm vào method getInstance()
volatile được thêm vào self (phần này được tôi lờ đi)

Có mấy vấn đề ở đây liên quan tới threading bạn nên biết.

synchronized cần phải tối thiểu

Cần phải khẳng định ngay rằng cách viết trên cho hiệu năng rất thấp. synchronized sẽ thực hiện việc lock method khiến các thread không thể invoke method song song, chúng buộc phải invoke tuần tự. Nếu có 100 thread gọi getInstance(), thread thứ 100 sẽ nhận được object AppConfig sau khi 99 thread trước đã hoàn thành. Sẽ tốt hơn nếu object AppConfig được tạo ra bởi thread đầu tiên, 99 thread còn lại có thể đồng thời được nhận lại object AppConfig.

Double check locking nên được sử dụng trong trường hợp này. Double check locking là một design pattern phổ biến trong bài toán về threading, kiểm tra lock trước khi thực sự lock method (theo nguyên lý return as soon as possible).

public static synchronized AppConfig getInstance() {
    if (self == null) {
        synchronized (AppConfig.class) {
            if (self == null) {
                self = new AppConfig();
            }
        } 
    }
    return self;
}

public static synchronized AppConfig getInstance() {

if (self == null) {

synchronized (AppConfig.class) {

if (self == null) {

self = new AppConfig();

}

return self;

}

if (self == null) được thực hiện 2 lần, nên pattern này được gọi là double check. Đừng bỏ câu lệnh thứ 2 nếu bạn không muốn một hệ quả tai hại (100 object được tạo ra… tuần tự, tại sao?). Đấy là lý do tôi muốn synchronized cả method để ai đọc cũng hiểu.

Chỉ lock những statement thực sự cần thiết và không nhiều hơn mức cần thiết là nguyên lý cơ bản của threading.

synchronized vẫn chưa đủ

Ngay cả khi bạn không bỏ đi câu lệnh if (self == null) nào, vẫn có thể có hàng chục object AppConfig được tạo ra.

(http://tutorials.jenkov.com/images/java-concurrency/java-volatile-1.png)

Hãy nhớ, máy tính có đến mấy loại bộ nhớ, nên việc đảm bảo dữ liệu đồng nhất không dễ. Lan man 1 chút về kiến trúc máy tính qua hình trên:

Main memory là RAM.
CPU xử lý dữ liệu được nạp vào bộ nhớ của CPU, không phải RAM. Bởi vậy dữ liệu được sao chép theo trình tự RAM -> Lx ->… -> L2 -> L1 cache. Trong lúc đấy hàng triệu thứ đã xảy ra.
Tưởng tượng, counter là self, khi 2 thread bắt đầu, self = null, được copy vào cache. Sau đó dù có synchronized thì 2 CPU vẫn lấy giá trị trên 2 cache độc lập để ra quyết định. Kể cả sau khi xử lý xong, giá trị vẫn được giữ trên cache đến khi thực sự cần đưa xuống RAM.

Vậy là ta phải dùng volatile để giá trị của biến luôn được tham chiếu tới RAM khi thay đổi. Vậy đây là giá trị duy nhất.

Còn cách nào khác không?

Nếu để ý, bạn thấy volatile trở nên vô dụng khi ta lock toàn bộ method. Tức là cách cài đặt của tôi ở cuối bài trước là rất ngớ ngẩn. Thật ra tôi cố tình viết vậy, ai không hiểu về threading thì vẫn có giải pháp chạy đúng; người hiểu biết về threading thì có hint đi tiếp.

Tôi không muốn đi sâu vào threading vì vấn đề này phụ thuộc ngôn ngữ, nền tảng. Hy vọng bạn hiểu rằng một design pattern đơn giản như Singleton cũng cần cài đặt cẩn thận và hiểu biết sâu sắc.

Kết

Có 2 vấn đề muôn thưở của lập trình: performance và memory. Bài này đề cập tới performance. Một số comment khác về việc không quản lý tốt life cycle khi sử dụng Singleton gây ra memory leak. Tôi sẽ cố gắng viết sau.

Và đừng hỏi tại sao lập trình lại phải biết kiến trúc máy tính. Bởi vì code không chạy trên máy tính thì chạy ở đâu? Nền tảng quan trọng lắm.

1,479 total views, no views today

Singleton có thực sự dễ?

May 21, 2018 by Hien Nguyen·Comments Off

Khi nói về Design Patterns, gần 100% những người tôi tiếp xúc đều thực hành Singleton như một design pattern phổ biến và dễ nhất (nhiều người chỉ biết/nhớ mỗi Singleton trong GoF). Tôi thường có 2 câu hỏi:

Sử dụng Singleton và static trong class có gì khác nhau?
Có tự tin cài đặt đúng Singleton?

Thường thì mọi người gặp khó khăn ở câu hỏi #1, và rất chắc chắn ở câu hỏi #2. Tôi thấy, #2 khó hơn #1 nhiều, và nếu bạn không tự tin trả lời #2 thì tôi khuyên bạn nên sử dụng static trong class thay vì Singleton. Tại sao? Đọc tiếp nhé.

Sử dụng Singleton và static trong class có gì khác nhau?

Nếu bạn chưa rõ về câu hỏi thì tôi giải thích thêm một chút: Mục đích của Singleton là tạo ra một object duy nhất trên toàn ứng dụng, kéo theo các thuộc tính của nó cũng là duy nhất; điều này hoàn toàn giống / có thể thực hiện bởi thuộc tính static của class – là nơi duy nhất lưu trữ dữ liệu. Ví dụ:

// Using Singleton 
public class AppConfig { 
    public int appId;
    private static AppConfig self;

    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self; 
    } 
}

config = AppConfig.getInstance();
appId = config.appId;

// Using Singleton

public class AppConfig {

public int appId;

private static AppConfig self;

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

config = AppConfig.getInstance();

appId = config.appId;

// Using static
public class AppConfig {
    public static int appId; 
}

appId = AppConfig.appId;

// Using static

public class AppConfig {

public static int appId;

}

appId = AppConfig.appId;

Cả 2 cách cài đặt trên, appId đều chỉ có một nơi duy nhất để lưu trữ và truy xuất giá trị. Sử dụng static theo #2 gọn và tường minh hơn, vậy cần gì Singleton?

Để ý một chút, một cách cài đặt sử dụng class, một cách sử dụng object. Có 2 sự khác nhau giữa class và object trong trường hợp này:

Life-time: Life cycle của class gắn với ứng dụng, life cycle của object gắn với việc sử dụng. Sử dụng static trong class, những thuộc tính này sẽ được load theo class khi chạy ứng dụng; sử dụng Singleton, những thuộc tính này sẽ được load chỉ khi object được khởi tạo. Trong cả 2 trường hợp, thuộc tính không được tự động giải phóng cho tới khi ứng dụng kết thúc. (do object vẫn có reference được giữ bởi self, tồn tại theo class).
Abstraction: Sử dụng static trong class là concrete implement, sử dụng object cho một tầng abstraction nữa nên dễ thay đổi hơn. Ví dụ, chúng ta cần thay đổi AppConfig sang WindowsAppConfig, theo #2, tất cả mọi nơi truy cập tới appId đều phải sửa đổi; theo #1, nơi duy nhất cần thay đổi là AppConfig.getInstance() (có thể không cần thay đổi nếu áp dụng với những design pattern khác như Factory, DI).

Chẳng có gì đặc biệt, lý thuyết thôi. Chính xác, và vì thế bạn vẫn cài đặt Singleton như đã học? Nhưng thử tìm hiểu thêm nhé.

Có tự tin cài đặt đúng Singleton?

Cài đặt Singleton thế nào?

Dễ ợt, có 2 việc:

Đặt constructor là private để object không thể khởi tạo được từ bên ngoài.
Cung cấp 1 method duy nhất trả về giá trị static

Code thường được cài đặt như sau:

public class AppConfig {
    private static AppConfig self;
    public int appId; 
    
    private AppConfig() {
    } 
    
    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

// Use
AppConfig config = AppConfig.getInstance();
appId = config.appId;

public class AppConfig {

private static AppConfig self;

public int appId;

private AppConfig() {

}

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

// Use

AppConfig config = AppConfig.getInstance();

appId = config.appId;

Có một vài câu hỏi phía dưới.

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Reflection là một trong những thứ rất hay ho của một số ngôn ngữ (những ngôn ngữ khác nhau có thể có những tên gọi khác nhau: runtime reference…), và cũng là một thứ khó bởi nó nâng abstraction lên mức runtime. Những pattern như Object Mapper hay DI… không dễ cài đặt nếu không có reflection. Thử đoạn code sau nhé.

public class AppConfig {
    private static AppConfig self;
    public int appId; 
    
    private AppConfig() {
        appId = new Random().nextInt(100);
    } 
    
    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    public static void main(String[] args) {
        AppConfig config = AppConfig.getInstance();
        System.out.println(config.appId);
        
        AppConfig appConfig = null;
        try {
            Class<AppConfig> clazz = AppConfig.class;
            Constructor<AppConfig> constructor = clazz.getDeclaredConstructor();
            constructor.setAccessible(true);
            appConfig = constructor.newInstance();
        } catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException | InstantiationException e) {
            e.printStackTrace();
        }
        System.out.println(appConfig.appId);
    }
}

public class AppConfig {

private static AppConfig self;

public int appId;

private AppConfig() {

appId = new Random().nextInt(100);

}

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

public static void main(String[] args) {

AppConfig config = AppConfig.getInstance();

System.out.println(config.appId);

AppConfig appConfig = null;

try {

Class<AppConfig> clazz = AppConfig.class;

Constructor<AppConfig> constructor = clazz.getDeclaredConstructor();

constructor.setAccessible(true);

appConfig = constructor.newInstance();

} catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException | InstantiationException e) {

e.printStackTrace();

}

System.out.println(appConfig.appId);

}

Output của đoạn code trên thường sẽ là 2 số nguyên khác nhau, chính là appId. Về lý thuyết, appId chỉ được gán giá trị một lần duy nhất khi khởi tạo object. Như vậy đã có 2 object config và appConfig được tạo ra. Điều chúng ta mong muốn là config và appConfig là 2 biến cùng tham chiếu tới 1 object trong bất cứ trường hợp nào. Vậy nên giải pháp là kiểm soát constructor.

private AppConfig() {
    if (self != null) { 
        throw new UnsupportedOperationException("Use getInstance() to create object."); 
    }
    appId = new Random().nextInt(100);
}

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance() to create object.");

}

appId = new Random().nextInt(100);

}

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Threading là một trong những thứ rất hay ho nhưng cũng làm đau đầu developer vì nó không đi theo flow thông thường. Thử đoạn code sau nhé.

public class AppConfig {
    private static AppConfig self;
    public int appId; 
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    public static void main(String[] args) {
        Thread threadDownload = new Thread(new Runnable() {
            @Override
            public void run() {
                AppConfig config = AppConfig.getInstance();
                System.out.println(config.appId);
            }
        });

        Thread threadUpload = new Thread(new Runnable() {
            @Override
            public void run() {
                AppConfig config = AppConfig.getInstance();
                System.out.println(config.appId);
            }
        });

        threadDownload.start();
        threadUpload.start();
    }
}

public class AppConfig {

private static AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

public static void main(String[] args) {

Thread threadDownload = new Thread(new Runnable() {

@Override

public void run() {

AppConfig config = AppConfig.getInstance();

System.out.println(config.appId);

}

});

Thread threadUpload = new Thread(new Runnable() {

@Override

public void run() {

AppConfig config = AppConfig.getInstance();

System.out.println(config.appId);

}

});

threadDownload.start();

threadUpload.start();

}

Hãy thử chạy một vài lần vì cơ hội gặp trường hợp hai số khác nhau được in ra thấp hơn ví dụ trên. Tương tự ví dụ trên, ta có thể khẳng định: có 2 object đã được tạo ra. Sai lầm ở đâu? Hãy để ý method getInstance(), điều gì xảy ra nếu câu lệnh if (self == null) được thực thi đồng thời ở cả threadDownload và threadUpload? Chúng đều đúng, và câu lệnh tạo object và return vẫn được tiếp tục trên 2 thread độc lập, và trả ra 2 object độc lập. Vậy nên cần phải synchronized việc tạo object.

public class AppConfig {
    private static volatile AppConfig self;
    public int appId; 
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

public class AppConfig {

private static volatile AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Serializable có thể là một vấn đề. Chúng ta muốn lưu lại cấu hình AppConfig xuống file sau đó load lại khi cần. Thử đoạn code sau nhé.

public class AppConfig implements Serializable {
    private static volatile AppConfig self;
    public int appId;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    public static void main(String[] args) {
        AppConfig config = AppConfig.getInstance();
        
        try {
            // Save config to file
            ObjectOutput objectOutput = new ObjectOutputStream(new FileOutputStream("app.conf"));
            objectOutput.writeObject(config);
            objectOutput.close();
            System.out.println(config.appId);
            System.out.println(config);


            // Load config from file
            ObjectInput objectIutput = new ObjectInputStream(new FileInputStream("app.conf"));
            config = (AppConfig) objectIutput.readObject();
            objectIutput.close();
            System.out.println(config.appId);
            System.out.println(config);
        } catch (IOException | ClassNotFoundException ex) {
            ex.printStackTrace();
        }
    }
}

public class AppConfig implements Serializable {

private static volatile AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

public static void main(String[] args) {

AppConfig config = AppConfig.getInstance();

try {

// Save config to file

ObjectOutput objectOutput = new ObjectOutputStream(new FileOutputStream("app.conf"));

objectOutput.writeObject(config);

objectOutput.close();

System.out.println(config.appId);

System.out.println(config);

// Load config from file

ObjectInput objectIutput = new ObjectInputStream(new FileInputStream("app.conf"));

config = (AppConfig) objectIutput.readObject();

objectIutput.close();

System.out.println(config.appId);

System.out.println(config);

} catch (IOException | ClassNotFoundException ex) {

ex.printStackTrace();

}

Bạn sẽ thấy output có dạng này:

28
singletontester.AppConfig@55f96302
28
singletontester.AppConfig@776ec8df

singletontester.AppConfig@55f96302

singletontester.AppConfig@776ec8df

Tức là giá trị của object (các properties như appId) được giữ nguyên song object thực chất đã được tạo mới (tìm hiểu thêm về method toString()). Như vậy không đảm bảo 1 object được tạo ra duy nhất trên toàn bộ life cycle của ứng dụng. Vì cơ chế deserialize sẽ tạo mới object. Chúng ta cần sửa thành:

public class AppConfig implements Serializable {
    private static volatile AppConfig self;
    public int appId;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    protected AppConfig readResolve() {
        return getInstance();
    }
}

public class AppConfig implements Serializable {

private static volatile AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

protected AppConfig readResolve() {

return getInstance();

}

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Đáng tiếc là vẫn còn, clone thì sao?

Kết

Singleton “chuẩn” nên được cài đặt như sau:

public class AppConfig {
    private static volatile AppConfig self;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

public class AppConfig {

private static volatile AppConfig self;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

Bài viết này tôi lấy cảm hứng từ: https://medium.com/exploring-code/how-to-make-the-perfect-singleton-de6b951dfdb0, viết lại theo cách dễ đọc hơn.
Đến đây chắc bạn đã hiểu tại sao tôi khuyến nghị dùng static trong class nếu bạn không thực sự rõ về Singleton. Với class bạn không có vấn đề với serializable và reflection… Điều bạn gặp phải về threading có thể được IDE warning.
Hãy nhớ nhé, Singleton không dễ đâu.

4,090 total views, 1 views today

Anti-IF pattern

November 15, 2017 by Hien Nguyen·Comments Off

Lập trình không dùng if-else, có được không?

If-else thật xấu xí

Đối diện với một bài toán, lập trình viên (LTV) thường phải trả lời câu hỏi: Đây là bài toán đặc thù hay phổ quát? Bài toán “số ít” hay “số nhiều”? Và thông thường, câu trả lời sẽ quyết định thành quả tiếp theo. Ví dụ, con chó kêu gâu gâu?” là bài toán số ít. Ta có thể viết thế này:

if (dog.startTalking())
    return "gâu gâu";

1 2	if (dog.startTalking()) return "gâu gâu";

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo” thì sao? Vẫn là bài toán số ít thôi.

if (animal.startTalking()) { 
    if (animal == DOG)
        return "gâu gâu";
    else
        return "meo meo"; 
}

if (animal.startTalking()) {

if (animal == DOG)

return "gâu gâu";

else

return "meo meo";

}

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo, con vịt kêu quạc quạc” thì sao? Vẫn là bài toán số ít thôi.

if (animal.startTalking()) { 
    if (animal == DOG) 
        return "gâu gâu"; 
    else if (animal == CAT)
        return "meo meo"; 
    else if (animal == DUCK) 
        return "quạc quạc";  
}

if (animal.startTalking()) {

if (animal == DOG)

return "gâu gâu";

else if (animal == CAT)

return "meo meo";

else if (animal == DUCK)

return "quạc quạc";

}

Thật đơn giản. À từ từ, chuyển sang switch cho đẹp mắt.

switch (animal) {
    case DOG:
        return "gâu gâu";
    case CAT:
        return "meo meo"; 
    case DUCK: 
        return"quạc quạc";
}

switch (animal) {

case DOG:

return "gâu gâu";

case CAT:

return "meo meo";

case DUCK:

return"quạc quạc";

}

Đẹp đẽ quá rồi. Tuyệt vời.

Bạn có thấy câu chuyện trên quen thuộc trong cuộc sống hàng ngày của LTV? Khi if-else bắt đầu phát huy sức mạnh, làm ơn đừng chuyển sang switch – chẳng hay ho gì đâu. Khi if-else bắt đầu phát huy sức mạnh, chính là khi nó bắt đầu trở nên xấu xí, chính là khi chúng ta cần phải xem lại cách đánh giá bài toán của mình. Đây không phải là bài toán số ít ngay từ đoạn code #2. Các LTV cần hiểu đúng đắn rằng đây là bài toán số nhiều ngay từ khi nó có dấu hiệu là bài toán số nhiều, thay vì cứ else-if và hy vọng giữ nó là bài toán số ít.

LTV có thể sống mà không cần if-else?

Có, dùng switch thôi. Không không, tiêu đề trên để cho vui thôi. Câu hỏi thực sự là “chúng ta có thể lập trình mà không sử dụng câu lệnh rẽ nhánh (conditional statement)?”. Vâng, không dùng if-else, switch,…?

Từ thưở đầu học lập trình, ai trong chúng ta cũng biết những thứ căn bản nhất của một ngôn ngữ lập trình (NNLT): variable, array, conditional, loop statement. Lâu dần chúng ta coi đó là điều nghiễm nhiên của một NNLT. Nhưng bạn cần biết rằng, âu lệnh if-else còn nhiều điểm xấu xí khác, từ logic cho tới runtime speed, memory… nên một số NNLT hoàn toàn không có if-else.

Vậy thì sống làm sao? Làm sao để giải bài toán trên mà không dùng if-else? OOP – polymorphism là một giải pháp. Thử xem:

class Animal { 
    talk(); 
} 

class Dog : Animal { 
    talk() {
        return "gâu gâu"; 
    } 
} 

class Cat : Animal { 
    talk() {
        return "meo meo"; 
    } 
} 

class Duck : Animal { 
    talk() {
        return "quạc quạc"; 
    } 
} 

// something here
animal.talk();

class Animal {

talk();

}

class Dog : Animal {

talk() {

return "gâu gâu";

}

class Cat : Animal {

talk() {

return "meo meo";

}

class Duck : Animal {

talk() {

return "quạc quạc";

}

// something here

animal.talk();

Không có gì huyền bí cả, bạn có thể tham khảo tại blog của Martin Fowler về pattern này.

Nếu bạn muốn thực hành nhiều hơn, có thể tìm đến Anti-IF pattern tại đây.

No if-else

Về lý thuyết, chúng ta hoàn toàn có thể lập trình mà không sử dụng if-else. Tại các buổi Code Retreat thường có 1 session mà LTV nhất định không sử dụng if-else khi lập trình ngay cả khi NNLT đó hỗ trợ. Mục tiêu là luyện tập khả năng ít phụ thuộc vào conditional statement để hình thành tư duy abstract. Như ví dụ trên, câu lệnh if-else thực sự quá mạnh mẽ, đến nỗi các LTV không thể tránh được cám dỗ, giải bài toán theo “số ít” và tạo ra những thiết kế sai lầm, vi phạm nguyên tắc open-closed cơ bản.

Nếu bạn chưa biết thực hành thế nào, hãy tới một buổi Code Retreat cho biết.

1,501 total views, no views today

Design patterns

May 31, 2017 by Hien Nguyen·Comments Off

Here is my presentation for the workshop at CodeGym today about Design patterns. One of the biggest issue in training design patterns is the trainees don’t know how to apply them together in a single real world problem. I tried to create a real world problem and introduced a simple way to get it solved by combining some design patterns.

KFC. Order system

KFC is very famous fastfood brand, they have many franchises in various places that share the same hotline, menu.

When users open the menu on KFC website, they see the single menu, choose and order food by calling to the single hotline. A order center (OC) receives the order and notifies to the appropriate store by a specific criteria (now is location and can be changed in the future). A store can answer their possibility to take this order (they need to cook and deliver it on time). If a store takes this order, the process ends; otherwise, the OC will find another one.

To process a order, a store has a recipient who receives the order from OC, forwards it to the kitchen, finds the right delivery man and updates the order basing on the information from delivery man such as payment, status (accepted or declined), customer feedback… to OC. So OC has real time data of every orders but doesn’t have order’s internal note that works within the store.

When OC gets the order information from customer, they may get the extra information in some categories like food change, delivery time, special notes… If customer calls to OC to cancel the order, OC can directly cancel it by updating the order status in taken store.

Design the system by design patterns.

1,582 total views, no views today

Design patterns in real world problem

May 25, 2017 by Hien Nguyen·Comments Off

I will have a workshop at CodeGym at the end of this month about Design patterns. One of the biggest issue in training design patterns is the trainees don’t know how to apply them together in a single real world problem. Here is my example that will be used as the exercise for this workshop. Is it interesting enough? Try it out.

KFC. Order system

KFC is very famous fastfood brand, they have many franchises in various places that share the same hotline, menu.

Design the system by design patterns.

—————————————————————-

The solution will be updated later.

1,662 total views, no views today

Abstract. More abstract.

March 28, 2017 by Hien Nguyen·Comments Off

Hôm nay đồng nghiệp hỏi câu này: Tại sao nên viết như #a thay vì #b?

/* a. */ List<?> list = new ArrayList<?>();
/* b. */ ArrayList<?> list = new ArrayList<?>();

1 2	/* a. / List<?> list = new ArrayList<?>(); / b. */ ArrayList<?> list = new ArrayList<?>();

Tôi mở rộng câu hỏi thành: Sắp xếp các cách viết sau theo thứ tự “tốt dần”.

/* 1. */ ArrayList<Book> list = new ArrayList<Book>();
/* 2. */ ArrayList<?> list = new ArrayList<Book>();
/* 3. */ List<Book> list = new ArrayList<Book>();
/* 4. */ List<?> list = new ArrayList<?>();

/* 1. */ ArrayList<Book> list = new ArrayList<Book>();

/* 2. */ ArrayList<?> list = new ArrayList<Book>();

/* 3. */ List<Book> list = new ArrayList<Book>();

/* 4. */ List<?> list = new ArrayList<?>();

Khá khó để nói #3 và #4, cách nào tốt hơn; nhưng có thể dễ dàng khẳng định #1 và #2 không tốt bằng #3, #4. Tại sao?

Nguyên tắc chung của lập trình hướng đối tượng là trừu tượng hoá và cố gắng tối đa việc trừu tượng hoá. Trừu tượng (không phải là giải pháp toàn vẹn nhưng) là một phần trong cách tư duy về Open / Closed principle. #1 rất trực quan và dễ hiểu: tạo một danh sách lưu trữ sách dưới dạng ArrayList. Nhưng những thứ cụ thể rất khó để sửa đổi và thay thế. Ví dụ, sau khi implement, chúng ta phát hiện ra đoạn code phía sau sử dụng rất nhiều thao tác thêm phần tử vào list thay vì lấy phần tử ra; do đó lưu trữ dưới dạng Stack cho hiệu suất tốt hơn; chúng ta phải sửa đổi các đoạn code phía dưới với implement cụ thể của Stack (thay cho ArrayList). Một thời gian sau, nhu cầu lấy phần tử từ list đủ nhiều để sử dụng ArrayList cho hiệu suất tốt hơn, chúng ta phải sửa lại đoạn code phía dưới với implement cụ thể của ArrayList. (Tham khảo: hiệu suất các implement của List). Khổ chưa?

Một cách thông minh hơn là sử dụng #3, khi đó, đoạn code phía dưới chỉ sử dụng những method được định nghĩa cho interface List. Khi cần thay đổi implement cụ thể thành Stack, LinkedList…, chúng ta chỉ đơn giản thay new List<Book>() bởi new Stack<Book>() hay new LinkedList<Book>().

Và theo cách tư duy đó, #4 tốt hơn #3? Không hẳn, nếu chúng ta đã xác định list chỉ chứa Book, việc khai báo list chứa Object khiến chúng ta có thể mất công cast những object này trong trường hợp sử dụng những method cụ thể của Book (và thường là vậy). Nên dùng #4 thường là bất lợi hơn #3 (trừ trường hợp list chữa những object khác ngoài Book).

Do đó, sử dụng #3 (khai báo interface và khởi tạo bằng class (đương nhiên)) thường là cách viết nên được “quen tay”.

Thật ra #3 còn nên viết theo 1 cách khác tốt hơn như sau. Tại sao nhỉ?

List<?> list = factoryBookList();

// another place
List<?> factoryBookList() {
    return new ArrayList<?>();
}

List<?> list = factoryBookList();

// another place

List<?> factoryBookList() {

return new ArrayList<?>();

}

1,450 total views, no views today

GURUnH

Guru's notes

Tag: Programming

Authentication & WebView & React Native

Problems

Solutions

Facebook login

Remember me

Know issues

Singleton: dùng hay không?

Vì sao ra đời?

Cái gì hay?

Cái gì dở?

Nên dùng thế nào?

Singleton.threading() in Java

synchronized cần phải tối thiểu

synchronized vẫn chưa đủ

Còn cách nào khác không?

Kết

Singleton có thực sự dễ?

Sử dụng Singleton và static trong class có gì khác nhau?

Có tự tin cài đặt đúng Singleton?

Cài đặt Singleton thế nào?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Kết

Anti-IF pattern

If-else thật xấu xí

LTV có thể sống mà không cần if-else?

No if-else

Design patterns

Design patterns in real world problem

Abstract. More abstract.

Tag: Programming

Problems

Solutions

Facebook login

Remember me

Know issues

Vì sao ra đời?

Cái gì hay?

Cái gì dở?

Nên dùng thế nào?

synchronized cần phải tối thiểu

synchronized vẫn chưa đủ

Còn cách nào khác không?

Kết

Sử dụng Singleton và static trong class có gì khác nhau?

Có tự tin cài đặt đúng Singleton?

Cài đặt Singleton thế nào?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Kết

If-else thật xấu xí

LTV có thể sống mà không cần if-else?

No if-else

If-else thật xấu xí