Musihoven

everyday Quran
(eQ)
A new way to tadarus Al-
Quran Al Karim
Main features

personal

group

gathering
Detailed Main Features
ID Main Scenario
M-1: Personal A user reads Quran and translation within a chosen rythm, for example, one juz a day. User
can read part or whole of his assignment. When all are done, (s)he marks the progress of
the day. His/her progress is displayed, and he/she is given a timeliness score to motivate
him read on time. The user can read past due Quran but is given less timeliness score. The
user can not read future assignments. App can also send notification or add an event in
calendar – at scheduled time, for example, after Maghrib or multiple times a day – to
remind him to read. Note that M-1, M-2, M-3 can run simultaneously, however, only one M-1
session is allowed per user.
M-2: Group Users can make group to read Quran and translation, each a piece of Quran, so that in total
the whole Quran is read. Every user can see each other daily progress (does he/she
complete the assigned part, yes or no), timeliness score, and which part is his/her
assignment per day. A user can send a reminder and encouragement to finish his part. A
user can read parts that are skipped by other user, if the originally assigned user agrees. A
user can mark his / her favorite ayah, which is also visible to other users. A user can add
note or question to an ayah for discussion within the group or can bring this up in the next
face to face meeting with an Ustadz. Note that M-1, M-2, M-3 can run simultaneously,
however, only one M-2 session is allowed per user.
3
Detailed Main Features
ID Main Scenario
M-3: Gathering Users can join a short term / temporary tadarus during gathering, for example,
while waiting for Ifthar. Larger number of users can join, up to maximum of 50 at
the same time. A leader can start, others can join via shared weblink or by
touching each other phones. The leader defines the rhythm, e.g. every 2 ayah or
1 page, which is changeable after the round starts. All users will get highlight
which part is being read, so they will find it easier. When the assigned user is
done with his part, he submits (or click ‘Done’) and new section for next assignee
is highlighted. All users can see this change. When a session is finished, the
leader can save it for next rounds, or delete it. Note that M-1, M-2, M-3 can run
simultaneously, however, only one M-3 session is allowed per user.

4
Use Cases

5
Use cases

ID Use case
UC-1: Joining eQ User download eQ app from App Store. User can either register or login using
third-party login services (like Facebook, Google, LinkedIn, Twitter, etc.)
UC-2: Starting a User start a reading routine by setting up the load, for example, one page a
personal reading day. The assignment setup engine split Quran into tasks that contain the
routine sequence number and exact portion – starting and ending ayah – to read. The
load setting and task list are synced to the server.
UC-3: Reading User reads Quran and translation in the app. User can switch between Quran
Quran / translation and translation(s). Supported facility are zoom in and out both the Quran and
translation, change font and color.
UC-4: Making User select action to finish an assignment, either for the current period or
progress on unfinished tasks of previous periods. The Quran reading window is opened on
personal and group the assigned section. When reading is done, user marks the progress ‘done’ and
assignment syncs the status to the server.

6
Use cases

ID Use case
UC-5: Monitoring User is shown dashboard of progress of previous assignments and the
own progress timeliness score of the past 5 periods. (+1) score if on time, (+0.5) score if late.
UC-6: Scheduling User setup a recurrent reading task in calendar, either by time, or by proximity
reading task in to shalat times, single or multiple times a day (e.g. 10 min before magrib and
calendar isya).
UC-7: Starting a User setup a reading group with the load (for example, one page a day) by
group reading invitation (sharing a link to others via whatsapp, email, or rooster within app).
routine The other users accepted. When there is enough users (min 2 max 30), the user
can officially start the routine. The assignment setup engine split Quran into
tasks that contain the sequence number and exact portion – starting and ending
ayah – to read divided by number of users. The load setting and task list are
synced to the server and distributed to users.
UC-8: Monitoring User is shown own dashboard and dashboard of other people progress.
group member
progress

7
Use cases

ID Use case
UC-9: Reminding From the group dashboard, user can select a user and send reminder messages.
and motivating The receiving user can receive messages in ‘Inbox’ and reply.
others
UC-10: Sharing From the Quran reading, user can share favorites and notes (or questions) of
notes and favorites ayah(s). Other users can see the notes and favorites from the ‘Home’ wall, and
of ayah(s) they are able to add comments and likes.
UC-11: Starting User setup a reading event with the load (for example, 2 ayah per person) and
gathering event starting ayah by invitation (sharing a link to others via whatsapp, email, or
rooster within app). Other users join by clicking on the link. When there is
enough participant, the user can officially start the event, the server notify all
registered users of this event
UC-12: Making All registered users of an event will see the Quran reading window opened on
progress during the current task. A user (typically on site) reads the task, and when finishes the
gathering user click ‘Done’. The server is notified, and the next task is informed to all
registered users of this event.

8
Use cases

ID Use case
UC-13: Ending The user who starts the gathering event can stop the event anytime, or it will
gathering event be stopped by server automatically after 2 hours of non-activity à atau sengaja
di save oleh si pembuat
UC-14: Managing Admin can add, remove, block and unblock user via admin only site
users
UC-15: Managing In the admin only site, admin can start personal, group, or gathering sessions
sessions manually – using assignment startup engine. Admin can make also add or
remove users from the group, restart the assignment list, regenerate the
assignment list with new rhythm, and stop the session.
UC-16: Resigning User can resign from eQ. When he/she chooses to do so, all the data associated
from eQ with him/her will be erased after 30 days.

9
Quality Attributes

10
Quality Attributes

ID Quality Attribute Scenario Associated Use

Case
QA-1 Performance User sends request to server during peak period and receive UC-1, 2, 4, 7, 8, 9,
the response within 1 minute 10, 11, 12, 13, 14,
15
QA-2 Performance App UI response rate during normal operation shall be within UC-1, 2, 4, 7, 8, 9,
2 seconds per click/tap on 3 years old device 10, 11, 12, 13
QA-3 Availability Whenever the server code needs to be updated, the update All
cannot cause downtime of more than 30 minutes
QA-4 Availability When server is unresponsive, app will notify the user once, UC-1, 2, 4, 7, 8, 9,
save the operation in the operation stack, retry operations in 10, 11, 12, 13
the stack every minute until the server is available again, or
when the app is re-opened, the operation will be tried again

11
Quality Attributes

ID Quality Attribute Scenario Associated Use

Case
QA-5 Availability App upgrade, crash, re-installation shall not cause registered All
user to lose data, achieved by mirroring the internal app
state to server
QA-6 Usability The user downloads a new app and using it productively UC-1, 2, 4, 7, 8, 9,
after 5 minutes of experimentation 10, 11, 12, 13
QA-7 Modifiability When developer needs to modify existing functionality, the All
changes shall be realizable and tested within 20 working
hours (half man week) per app platform or server platform
QA-8 Interoperability When app initiate information exchange to the server using All
incompatible API version, the request shall be rejected by the
server, and the app displays a message to user to update
app version to the latest version

12
Quality Attributes

ID Quality Attribute Scenario Associated Use

Case
QA-9 Testability A set of tests is executed either automatically via continuous All
integration or manually before merging of the code that
produces test results of 80% coverage within 12 hours
QA-10 Security A user performs any operation on the system, at any All
moment, and 100% of the operations performed by the user
are recorded by the system in the operations log, which
includes time stamp, app API version, user id, ip address,
device id where the operations are performed from

13
Constraints

14
Constraints

ID Constraint
CON-1 The server shall be able to support at least 100 active users for all features (personal, group,
gathering) during normal month. During month of Ramadhan, it shall support 10x as much.
CON-2 The app language of implementation is native, Kotlin for Android and Swift** for iOS (choice will
be determined after Android version is released)
CON-3 Server communication is done via REST interface
CON-4 App download size from app store is less than 50 MB. Auxiliary downloads, for example, voice or
high-quality pictures from external sources, if needed, is not included in this constraint
CON-5 Feature differences between platform, e.g. Android vs. iOS, shall be kept within less than 10%**
(this constraint is valid from end of 2020)
CON-6 The app shall support minimum English, Indonesian, Dutch
CON-7 GDPR shall be followed

15
Architectural Concerns

16
Architectural Concerns

ID Constraint
CRN-1 Establishing an initial (zeroth order) overall structure as this is a green field system, although
previous implementation existed in older Android, React or other forms
CRN-2 Detailed architecture will be detailed out later due to limited resources. For the same reason,
modification to existing architecture shall be minimized

17
High level architecture

18
Architecture Style: Interpreter
Mobile App

Interpreter parses and executes input commands, updating

the state maintained by the interpreter

○ Components: Command interpreter, program/interpreter

state, user interface.

○ Connectors: Typically very closely bound with direct

procedure calls and shared state.

○ Highly dynamic behavior possible, where the set of

commands is dynamically modified. System architecture
may remain constant while new capabilities are created
based upon existing primitives.

○ Superb for end-user programmability; supports

dynamically changing set of capabilities

Server
19
 Architecture (Overall)
Group1 Group2

App1 App2 App3 App4

Admin Console
Stream Stream Stream Stream Stream Stream Stream Stream
Post(uid, Get(uid, Post(uid, Get(uid,
gid, data) gid, since) gid, data) gid, since)
Server
DAO, user registration
and access auth,
invitation, push notif

Addressed:
QA-1. QA-3. QA-5 Document-oriented Database
QA-8, QA-10 Group1 streams Group2 streams
yymmddHHMMSS.SSS Data1 yymmddHHMMSS.SSS Data1 User details
yymmddHHMMSS.SSS Data1 yymmddHHMMSS.SSS Data1
yymmddHHMMSS.SSS Data2 yymmddHHMMSS.SSS Data2 Logs

20
Event definition (example)
Personal reading

○ Event1 [key: yyyymmddHHMMSS.sss]

• { uid: aa, aid: A001 [initiate personal read], data: {seq: 1-102, 103-204, …}}

○ Event2 [key: yyyymmddHHMMSS.sss]

• { uid: server, aid: A002 [personal read created], data: {gid:gid}}

○ Event3 [key: yyyymmddHHMMSS.sss]

• { uid: server, aid: A004 [personal read started], data: {}}

○ Event4 [key: yyyymmddHHMMSS.sss]

• { uid: aa, aid : R001 [read finished], data: {done: 1-102}}

○ Event5 [key: yyyymmddHHMMSS.sss]

• { uid: aa, aid : R001 [read finished], data: {done: 103-204}}

21
Event definition (example)
Group reading

○ Event1 [key: yyyymmddHHMMSS.sss]

• { uid: aa, aid: B001 [initiate group read], data: {invitees: aa@email.com, uid3, uid5, bb@email.com}}

○ Event2 [key: yyyymmddHHMMSS.sss]

• { uid: server, aid: B002 [group read created], data: {gid:gid}}

○ Event3 [key: yyyymmddHHMMSS.sss]

• { uid: uid3, aid: B003 [group read accepted], data: {name: uid3_name}}

○ Event4 [key: yyyymmddHHMMSS.sss]

• { uid: uid5, aid: B003 [group read accepted], data: {name: uid5_name}}

○ Event5 [key: yyyymmddHHMMSS.sss]

• { uid: aa, aid: B005 [group read started], data: {{uid: aa, seq: 1-102, 103-204, …}, {uid: uid3, seq: 1-102, 103-204,
…}, {uid: uid5, seq: 1-102, 103-204, …}}}

22
Event definition (example)
Group reading

○ Event6 [key: yyyymmddHHMMSS.sss]

• { uid: aa, aid : R001 [read finished], data: {done: 1-102}}

○ Event7 [key: yyyymmddHHMMSS.sss]

• { uid: uid3, aid : R001 [read finished], data: {done: 103-204}}

23
 Architecture (App Side)
○ Model
Model represents the data and business logic of
the app. One of the recommended implementation
Objective: Separation between information, strategies of this layer, is to expose its data
presentation and user interaction. through observables to be decoupled completely
from ViewModel or any other observer/consumer

○ ViewModel
ViewModel interacts with model and also prepares
observable(s) that can be observed by a View.
ViewModel can optionally provide hooks for the
view to pass events to the model.
One of the important implementation strategies of
this layer is to decouple it from the View, i.e,
ViewModel should not be aware about the view
who is interacting with.

Addressed: ○ View
QA-2, QA-4, QA-5 Finally, the view role in this pattern is to observe
(or subscribe to) a ViewModel observable to get
data in order to update UI elements accordingly.
24
Rationale for Android
○ Android may decide to destroy or re-create a UI controller in response to
certain user actions or device events that are completely out of your
control.

○ If the system destroys or re-creates a UI controller, any transient UI-

related data you store in them is lost.

○ For simple data, the activity can use the onSaveInstanceState() method
and restore its data from the bundle in onCreate(), but this approach is
only suitable for small amounts of data that can be serialized then
deserialized.

○ Another problem is that UI controllers frequently need to make

asynchronous calls that may take some time to return. The UI controller
needs to manage these calls and ensure the system cleans them up after
it's destroyed to avoid potential memory leaks.

○ Reduce responsibility of UI controllers to handle only user interactions à

Example of Events during screen improve testability
rotation
25
Architecture (App Side)

async async

Interpreter
async

Server

26
References

○ https://developer.android.com/topic/libraries/architecture/viewmodel

○ https://proandroiddev.com/mvvm-architecture-viewmodel-and-livedata-part-1-604f50cda1

○ https://medium.com/flawless-app-stories/how-to-use-a-model-view-viewmodel-architecture-for-ios-
46963c67be1b

○ https://www.raywenderlich.com/34-design-patterns-by-tutorials-mvvm

○ https://www.wintellect.com/model-view-viewmodel-mvvm-explained/

○ https://blogs.msdn.microsoft.com/johngossman/2005/10/08/introduction-to-modelviewviewmodel-pattern-
for-building-wpf-apps/

27
Continuous Integration

28
 Continuous Integration Model

http://github.com/musihoven http://eq.dafinda.com:9090/

• Building
Repos: • Testing
• eq-android • Deploying (later)
• eq-ios
• eq-server

Addressed:
QA-7 (partially)
QA-9 (partially)

29
Git flow
(https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
The overall flow of Gitflow is:

○ A develop branch is created from master

○ A release branch is created from develop

○ Feature branches are created from develop

○ When a feature is complete it is merged into

the develop branch

○ When the release branch is done it is merged

into develop and master

○ If an issue in master is detected a hotfix

branch is created from master

○ Once the hotfix is complete it is merged to

both develop and master

30
Example: Creating feature branch
### One-time setup

○ git flow init

○ git checkout develop ○ git flow feature start feature_branch

○ git checkout -b feature_branch ○ ### Working on code

○ ### Working on code

○ git checkout develop

OR ○ git flow feature finish feature_branch

○ git merge feature_branch

Tip: use SourceTree for nicer git GUI

31
Admin details: github Branch protection

○ Ensure branches are protected by pull request

reviews

○ Ensure branches are successfully tested before

merged

32
Admin details: Setting up Jenkins and Github

○ Create Personal Access Token in Github

• repo (All)
• admin:repo_hook(All)
• admin:org_hook
• user (All, altho only user:email is required)

○ Install Blue Ocean Plugin

○ Manage Jenkins à Configure System à Github Server

• Add Github server
• Add credential, Kind: secret text, Secret: Personal access token from Github
• Select this credential
• Enable “Manage hooks“

○ https://resources.github.com/whitepapers/practical-guide-to-CI-with-Jenkins-and-GitHub/
33
Test Strategy
QA-7
QA-9

34
Automatic Test (Pull request - Frontend)

Checkout, build,
test setup

Pull request
Or merge
To develop Status

eq-android Unit tests Jen

(70%)

JENKINS 35
Automatic Test (Pull request - Backend)

Jen
Status

Pull request Checkout, build,

Or merge test setup
To develop

eq-server Unit tests

(90%) JENKINS 36
Unit testing
○ Aim to have 70 - 90% of test coverage here

○ Run fast without emulator

○ Guard against accidental change

○ Working codes keep working

○ Run these tests locally in developer laptop before commit / pull request à chance to fix problems earlier

○ Junit4

○ Mockito

○ Roboelectric

○ https://developer.android.com/training/testing/unit-testing/local-unit-tests

37
 Automatic Test (Daily test)

Checkout, build,
test setup

eq-android Unit tests Jen (UI)

Instrument
Status if failed
(70%) tests (20%) Integration
Trigger daily tests (10%)
Checkout, build,
test setup

eq-server Unit tests

(90%) JENKINS 38
Instrumentation Testing
(Run on multiple emulators, from Marshmallow to Pie)
○ Find all available emulators ○ emulator –list-avds

○ For each emulator ○ for

• Start emulator • start emulator @Pixel_3a_API_28
• While true • while
• Wait one second • timeout /t 1
• Check if device is available • adb devices –l | findstr /R /C:"product:"
• Run test • gradlew.bat connectedAndroidTest
• Kill emulator • taskkill /im emulator.exe
• Zip: app\build\reports\androidTests\connected

○ Mail the zip file

39
Actual Instrumentation Testing Batch
@ECHO OFF
FOR /F %%I IN ('emulator -list-avds') DO (call :emulate %%I)

:emulate
start emulator @%1 -no-snapshot

if '%1' == '' goto :eof

:isup
timeout /t 1 /NOBREAK
set alive=Q
for /f "USEBACKQ" %%G IN (`"adb devices -l | findstr /R /C:""product:"""`) DO (set alive=%%G)
if '%alive%' == 'Q' GOTO isup

call gradlew.bat connectedAndroidTest

taskkill /f /t /im emulator.exe

:isdown
timeout /t 1
set dead=Q
for /f "USEBACKQ" %%H IN (`"adb devices -l | findstr /R /C:""product:"""`) DO (set dead=%%H)
if '%dead%' NEQ 'Q' GOTO isdown

40
Release process (Develop à Master)

○ Based on develop branch on eq-server and eq-android/eq-ios

○ Passed integration / daily tests

○ Human tester will test on actual phone on test server

○ Bug fixes on release branch

○ When testing done à made into master à released to Play Store

○ Bug fixes on release branch are merged into develop

41
Example code and references

○ Combined unit testing and instrumentation testing examples:

• https://github.com/yyudhistira/testing-samples/tree/master/runner/AndroidJunitRunnerSample

○ More conceptual read:

• https://developer.android.com/training/testing
• https://github.com/android10/Android-KotlinInTests

42
Sprint 1 - Goal

43
Next Sprint Goal: UC-1 (Joining eQ)
○ User story:
• User download eQ app from App Store. User can either register or login using third-party login services (like Facebook,
Google, LinkedIn, Twitter, etc.)

○ Success criteria
• A new user is able to register via OpenID à a new user entry is available in database
• A new user is able to login

○ Work
• Design app UI
• Design server technology stack
• Design server handling with new user and response with authenticated user
• Setup Oauth
• Ensure tests (unit, instrumentation, integration) for all above

44
 User known,
Activity States Application start
token OK

User unknown User known, token expired

Social login Social login

cancelled failed
User is logging
in via social
login Social login
Social login (SocialLogin) successful
selected
User is not Email login
User is in the
registered / not successful
lobby
logged in
(LobbyActivity)
(LoginActivity) User logged out

Email User is
registration registering via
selected Email
Email login (RegisterActivit
failed y)
User registered
45
 Social Login Flow* (1st time, not logged in)
1. User selects ‘Login with
<SocialMedia>’
3
2. App opens social media login site
3. User fills in username and password
on social media site
2*
4. If ok, returns access token to app
5. App sends access token, device id to
4 6 eq-server
1
6. eq server confirms validity of access
5 token to social media site and asks for
email and (if available) full name and
picture.
7

* potentially unsecure situation:

Social Media app id and secret key are compiled in APK
46
 Social Login Flow* (1st time, not logged in)
7. Return message back to app based on
social media validation
a) If valid:
3 1) Check if email, social media type, and
tokens available in database. If not,
add in database. If available, check if
token still the same, if not update
2* database
2) Generate a new eq-server access
token and add into database
1 4 6 3) eq server return a new eq-server
access token, email and full name
5 and picture back to app
b) If nok return rejected login message to
app
c) If nok for 3 times, app block next login
7 for 10*(n^2) seconds, where n is the n-
th time of failure. So 3rd time failure
delays for 90 seconds, 4th time 160
* potentially unsecure situation: seconds etc. App display waiting time
Social Media app id and secret key are compiled in APK
47
For next iteration
Social Login Flow (1st time, not logged in)
1. User selects ‘Login with
<SocialMedia>’
4
2. Get the SocialMedia id and secret
from server
3. App opens social media login site
3
4. User fills in username and password
on social media site
5
7 5. If ok, returns access token to app
1
2 6. App sends access token, device id to
eq-server
7. eq server confirms validity of access
6
token to social media site and asks for
email and (if available) full name and
8 picture.
8. Same as step 7 – previous slide

48
Social Login Flow (next time, logged in)
1. User starts app

2. App sends known eq-server access

token to eq-server

3. eq server confirms validity of social

media access token

4. Return message to app

1. If valid, Generate a new eq-server
1 3 access token and add into database
2. If expired, ask for a new social media
2 access token using refresh token.
Generate a new eq-server access token,
save in database, send a new token to
app
4
3. If not valid, go back like 1st time login,
ask for user authorization

49
Email Registration Flow
1. User click register, fill in form, full
name, email, password, picture
2. App send username, salt + hash
password, device id, form content to
server
3. Return message to app. Server also
send email for verification

50
Email Login Flow (1st time, not logged in)
1. User type in email and password
2. App send username, salt + hash
password, device id to server
3. Return message to app
a) If ok:
1) Generate a new eq-server access
token and add into database
2) eq server return a new eq-server
1 access token, email and full name
and picture back to app
2
b) If nok return rejected login message to
app
c) If nok for 3 times, app block next login
3 for 10*(n^2) seconds, where n is the n-
th time of failure. So 3rd time failure
delays for 90 seconds, 4th time 160
seconds etc. App display waiting time

51
Email Login Flow (next time, previously logged in)
1. User starts app

2. App sends last known eq-server

access token to eq-server

3. Return message to app

a) If ok:
1) Generate a new eq-server access
token and add into database
2) eq server return a new eq-server
1 access token
2 b) If nok return rejected login message to
app, back to unloggin state

52
Server interface during login (1)

○ App à eq-server:
• POST authorize, data in JSON
• “social_token”: string, [optional] à access token from social media
• “eq_token”: string, [optional] à last known token from eq-server
• “email”: string, [optional] à email address, if using email login
• “password”: string, [optional] à hashed + salted, email address, if using email login
• “login_type”: enum (“facebook”, “google”, “email”)
• “device_id”: string

53
Server interface during login (2)

○ Eq-server à app, responds in JSON

• “status”: enum, (“ok”, “nok”)
• “device_id”: string
• “eq_token”: string [optional], if status ok, new eq_token is received for next access
• “email”: string [optional], if this is first time login
• “fullname”: string [optional], if this is first time login
• “picture”: string [optional], picture in base64, if this is first time login

54
Server interface during login (3)
○ Eq-server à social media for token verification
• Facebook (Reference: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow#checktoken)
• GET graph.facebook.com/debug_token? input_token={token-to-inspect} &access_token={app-token-or-admin-
token}
• Return in JSON
• { "data": { "app_id": 138483919580948, "type": "USER", "application": "Social Cafe", "expires_at": 1352419328, "is_valid": true,
"issued_at": 1347235328, "metadata": { "sso": "iphone-safari" }, "scopes": [ "email", "publish_actions" ], "user_id": "1207059" } }

• Google (reference: https://developers.google.com/identity/sign-in/web/backend-auth)

• https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123
• Return in JSON
• { // These six fields are included in all Google ID Tokens. "iss": "https://accounts.google.com", "sub": "110169484474386276334",
"azp": "1008719970978-hb24n2dstb40o45d4feuo2ukqmcc6381.apps.googleusercontent.com", "aud": "1008719970978-
hb24n2dstb40o45d4feuo2ukqmcc6381.apps.googleusercontent.com", "iat": "1433978353", "exp": "1433981953", // These seven
fields are only included when the user has granted the "profile" and // "email" OAuth scopes to the application. "email":
"testuser@gmail.com", "email_verified": "true", "name" : "Test User", "picture": "https://lh4.googleusercontent.com/-
kYgzyAWpZzJ/ABCDEFGHI/AAAJKLMNOP/tIXL9Ir44LE/s99-c/photo.jpg", "given_name": "Test", "family_name": "User", "locale":
"en" }

○
55
Server interface during login (4)
○ Eq-server à social media for token verification
• Twitter:
• https://api.twitter.com/1/account/verify_credentials.json?oauth_consumer_key=XXX&oauth_nonce=XXX&oauth_sign
ature_method=HMAC-
SHA1&oauth_token=XXX&oauth_timestamp=123456789&oauth_version=1.0&oauth_signature=YYY
• oauth_timestamp is current UNIX timestamp (in UTC)
• oauth_signature is your generated signature (which twitter will verify by reproducing)

○ See details of creating signature here

• https://stackoverflow.com/questions/6378573/what-does-a-twitter-verify-credentials-look-like

56
References

• https://hackernoon.com/adding-oauth2-to-mobile-android-and-ios-clients-using-the-appauth-sdk-f8562f90ecff
• https://medium.com/@113408/implementing-social-login-in-android-without-sdks-64a1c49e0bfd
• https://github.com/openid/AppAuth-Android
• https://github.com/openid/AppAuth-iOS

• https://stackoverflow.com/questions/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server
• https://tools.ietf.org/html/rfc6749
• https://www.sans.org/reading-room/whitepapers/application/attacks-oauth-secure-oauth-implementation-33644
• https://medium.com/@taylorhughes/the-right-way-to-implement-facebook-login-in-a-mobile-app-57e2eca3648b

57
Thank
You
Yasri Yudhistira
References

○ https://fossbytes.com/most-popular-android-versions-always-updated/

○ https://www.quora.com/What-are-some-pros-and-cons-of-the-Kotlin-programming-language

○ https://stackoverflow.com/questions/3745491/emulate-samsung-galaxy-tab

○ https://developer.android.com/training/basics/supporting-devices/platforms

○ https://developer.android.com/distribute/best-practices/develop/target-sdk
Setting up Jenkins and Gitlab

○ https://stackoverflow.com/questions/55693706/gitlab-jenkins-webhook-integration

○ https://medium.com/@teeks99/continuous-integration-with-jenkins-and-gitlab-fa770c62e88a
• https://github.com/jenkinsci/gitlab-plugin/issues/375#issuecomment-295761116

60
More Jenkins settings

○ https://plugins.jenkins.io/github-oauth

61
OAuth setup

Google

○ https://support.google.com/cloud/answer/6158849?hl=en#installedapplications&android

○ https://stackoverflow.com/questions/27609442/how-to-get-the-sha-1-fingerprint-certificate-in-android-studio-
for-debug-mode

○ https://support.google.com/cloud/answer/6158849?hl=en#userconsent

○ https://medium.com/@113408/implementing-social-login-in-android-without-sdks-64a1c49e0bfd

○ https://medium.com/google-cloud/understanding-oauth2-and-building-a-basic-authorization-server-of-your-
own-a-beginners-guide-cf7451a16f66

62