Wiki source code of GSoC 2018 Proposal
Last modified by Vincent Massol on 2024/02/26 17:54
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | In this proposal I will try to make a plan for this GSoC for work on a project [[Android-Authenticator>>url:https://github.com/xwiki-contrib/android-authenticator||title="Github"]]. | ||
2 | |||
3 | = Step by step = | ||
4 | |||
5 | * --Update dependencies and tools-- | ||
6 | * --Support as many Android versions as possible-- (now supported all versions from API 16) | ||
7 | * Add "XWiki authenticator is not installed" | ||
8 | * Document as more as possible | ||
9 | * Test as more as possible | ||
10 | * Add application (or, may be, just make **AuthenticatorActivity** to be default) | ||
11 | * Rewrite **lint** and **proguard** options to minimize size of APK | ||
12 | * [[Improve OpenId Connect provider and authenticator>>doc:dev:GoogleSummerOfCode.ImproveOpenIdConnectproviderandauthenticator]] | ||
13 | * [[Finish and improve Android XWiki authenticator and contact synchronization>>doc:dev:GoogleSummerOfCode.Androidcontact2018]] | ||
14 | |||
15 | ((( | ||
16 | == A little bit about AndroidAuthenticator == | ||
17 | |||
18 | [[Here>>url:https://developer.android.com/training/sync-adapters/creating-authenticator]] you can read abut creating androidauthenticator. In two words: | ||
19 | |||
20 | 1. Extend AbstractAndroidAuthenticator by some class | ||
21 | 1. Some methods must return Bundle. In this case you can return bundle with Intent object to edit/create account an other actions | ||
22 | 1. getAuthToken await that you will return bundle with auth token | ||
23 | |||
24 | ((( | ||
25 | As you see, any method which need Bundle as a result - must return some set of parameters (intent, authToken or something else) | ||
26 | |||
27 | == Changing of authenticator architecture == | ||
28 | |||
29 | === Offers === | ||
30 | |||
31 | * Add auth methods abstraction. It will help to include different ways to auth | ||
32 | * Replace boilerplate with work with HTTP requests by some library usage and API interfaces/realisations (it will remove redundant handiwork with requests). It can increase size of APK, but this can be fixed by lint/proguard setting up). Besides, in future realises it can help to avoid redundant work with new protocols or something else which will be resolved on library level. Now I know //Retrofit//, //Volley// | ||
33 | ))) | ||
34 | ))) | ||
35 | |||
36 | ((( | ||
37 | ((( | ||
38 | == Tests and documentation == | ||
39 | |||
40 | === Documentation === | ||
41 | |||
42 | I'd like to write all documentation in Java Docs (**/~*~*...*/** blocks), but also I think that better documentation will be tests - they are always actual and true tests must cover all usage cases. | ||
43 | |||
44 | === Tests === | ||
45 | |||
46 | ==== Instrumentation ==== | ||
47 | |||
48 | Next instruments will be used for standard unit-tests which can need or need not in android-environment: | ||
49 | |||
50 | |||
51 | * Robolectric (emulate android-environment and can be useful in cases when instrumentation of class/object/method is java-clear but have some dependencies from android-environment) | ||
52 | * JUnit | ||
53 | * Mockito (mocking objects in tests) | ||
54 | * Power-Mockito (extended mocking of objects, can be useful in different tests where, for example, need to mock instantiating objects) | ||
55 | |||
56 | ((( | ||
57 | Next instruments will be used for UI tests: | ||
58 | |||
59 | |||
60 | * Espresso | ||
61 | ))) | ||
62 | ))) | ||
63 | ))) |