Thank you so much, my mentor, for encouraging and helping me a lot.
I will keep working hard, implement more functions ASAP and try my best to
make this project better and better.
Thanks,
Fitz
On Fri, May 6, 2016 at 11:43 AM, Thomas Mortagne
<
[hidden email]> wrote:
> Hi Fitz,
>
> First I'm quite impressed by the dedication you put in this project,
> great work !
>
> Let me answer quickly the simple questions and then I will take more
> time to think more about the design issues :)
>
> On Thu, May 5, 2016 at 6:45 PM, fitz <
[hidden email]> wrote:
>> Hi our dear community,
>>
>> I have tried to implement most of the functions for
android-authenticator in
>> these
>> days(
https://github.com/xwiki-contrib/android-authenticator/tree/feature-auth).
>> But there are still a lot of detailed issues that need to be handled,
like
>> security, volume, bad network state, cache and so on. I will try to deal
>> with these problems as soon as possible.
>>
>> Here, this time, first I would like to discuss whether my implementation
is
>> feasible enough, and second there are some other problems which need my
>> mentor and our community to help me. Thanks first of all.
>>
>> 1. *First introduce my design* and implementation of the synchronization
and
>> authenticator.
>>
>> 1.1 *Synchronization:*
>>
>> 1.1.1Server->Client
>> There are two choices, including synchronizing all users or synchronizing
>> the users of selected groups. We use the same method for these two cases.
>> 1) Add Update
>> Each time while calling the method SyncAdapter.onPerformSync, we get data
>> from server that has been modified since the last modified time. The data
>> that we get must be updated or added to the local contact2 database. Also
>> only these data need to be updated or added.
>> 2) Delete
>> What data should be deleted from the local database? Because the server
>> does not return data that needs to be deleted, or maybe I don not know
how
>> to query the deleted objects? :). Therefore now I just get all the user
>> IDs(HashMap<id,Ojbect>), traverse every user of the local database, find
the
>> data that are not in the IDs map, and then delete it.
>>
>> 1.1.2 Detail:
>> For synchronizing all users:
>> 1) Get all users as List<SearchResult> searchResults
>> 2) Add Update: SearchResults include the last modified time. So
according to
>> the time, we can filter what data should be updated or added. Then call
the
>> function ContactManager.UpdateContacts to update local db.
>> 3) Delete: searchResults already have user ids, so we can get the
>> IDs(HashMap<id,Ojbect>), then traverse the local database to find what
data
>> should be deleted.
>>
>> For synchronizing users of selected groups:
>> 1) Get all selected group ids from local sharepreference xml, as
>> List<String> groupIds
>> 2) Get the users’simple information(ObjectSummary) of each group one by
one.
>> The ObjectSummary only has the user’id without the last modified time.
>> 3) Add Update: According to the user ids, we get the last modified time
for
>> each user, if before the given last sync time, continue; if after, we
update
>> the user (but we need first get the detailed information of the user).
>> 4) Delete: at second step, we get ObjectSummarys which include all the
user
>> ids. So with these ids, we can find the data that should be deleted.
>>
>> 1.1.3 Client->Server
>> For this part, As we will first request and update the data in server
while
>> editing the contact, Therefore, unnecessary synchronization mechanism is
not
>> required. If the server’s response is that the editor has no permission,
we
>> just return; if has been updated in the server, we will update the local
>> database at the same time.
>>
>> 1.2 *Authenticator:*
>>
>> 1.2.1 How to grant the permission for third party apps when they calling
>> getAuthToken? (Here, AuthToken is equal to Cookie.JessionId).
>>
>> Basically, only 3 useful interfaces, like AddNewAccount, getAuthToken,
>> invalideAuthToken, are available for other third party android apps. The
>> most widely used is getAuthToken. How should we grant permission for
>> third-party apps? And when we grant? If adding XWiki account from one
app,
>> then we can trust this app and grant the getAuthToken permission. But if
>> not, we should check the permission for every getAuthToken request of
>> third-party apps. So the checking logic code should be in the function
>> getAuthToken. But XWikiAuthenticator.getAuthToken will never be called if
>> AcountManager has cached the authtoken corresponding to AuthTokenType.
>> Therefore for first granting permission to third-party apps, the app
should
>> not pass the same authTokenType when calling getAuthToken function. Or
the
>> authToken value will be directly returned by AcountManager according to
the
>> same AuthTokenType and the method getAuthToken will never be called. So
>> different apps should use the different AuthTokenType param to call the
>> function getAuthToken so that the <AuthTokenType, AuthToken> will not be
>> cached before granting permission for this app.
>> AuthTokenType=FULL_ACCESS+PackageName. So in
XWikiAuthenticator.getAuthToken
>> function, if we check that the third-party app has not been granted, we
>> startActivity(GrantPermissionAcvivity) to grant permission for this
package
>> by checking the user’s input password. And in addition the packageName
can't
>> be forged because we can use the bundle option.getCallUID from binder to
>> verify the pakageName.
>>
>> 1.2.2 How to maintain authToken consistency for different third-party
apps
>> with different AuthTokenType?
>>
>> When will appear inconsistent? There are mainly two key cases, the
authToken
>> is expired or the third-party app calls the invalideAuthToken function.
Now,
>> I use the following solution to these problems.
>> 1) When the authToken is expired, xwiki authenticator app will login
again
>> and refresh all the cached authToken for every AuthTokenType.
>> 2) When the third-party app calls the invalidAuthToken function, then
>> corresponding cache will be clear and getAuthToken will be called, then
>> XWikiHttp.login will be called to get a new token and refresh all the
cached
>> authToken for every AuthTokenType.
>> 3) So if any one finds the authToken has been expired, then login and
>> refresh all the cached authToken to maintain consistency. In addition, I
>> suggest that if the third-party app find the authToken is expired after a
>> period of time, then first call getAuthToken again. If the token is
>> different, then maybe authenticator has already update the token. If the
>> token is the same, just call invalidAuthToken and getAuthToken again.
>>
>
>
>> 2. *There are also some questions* that need help.
>>
>> 1) Is the above methods ok?
>
> I need to spend more time to anwer the first question (I simply don't
> much about some of the things you talked about :)). What I can say
> right away is that what I read looks well tough and whatever I could
> came up with will most probably be minor.
>
>> How should I test effectively.?
>
> You talk about Jenkins below so I guess you already started to look at
> how to write unit tests. I would add that as soon as you have a
> testable beta you should oficially release it and ask for tester in
> the community. I need to finish setting up an Android Play dev account
> for the XWiki project and will give you access ASAP.
If your question was about the XWiki instance you can easily get a
jetty/hsqldb distribution from Maven repository, unzip it and start
it. That what we do in other integration tests that need a running
instance of XWiki.
>
>> Or Maybe these
>> implementations exist more problems that I have overlooked?
>
>>
>> 2) Gradle or maven in Jenkins CI?
>> Now gradle is the default, great and perfect tool for building android
app.
>>
http://gradle.org/maven_vs_gradle/. And It's convenient for us to
develop
>> android apps in android studio. Also it's very easy to integrate with
>> jenkins and maven repository, And I have already tried it and
successfully
>> build my android apps in jenkins with
>> gradle.(
https://github.com/xwiki-contrib/android-authenticator/blob/feature-auth/document/CI.md).
>> However If we use maven to build apps, it's not conducive to our
>> post-maintenance and integrated development for android developers. So
could
>> I use gradle instead of maven to build our android apps? and can I use
it in
>> the jenkins? or I have to use maven?
>
> This is an independent project and will stay like this, I don't think
> we need to integrate it in the xwiki-platform build. Android community
> seems to have strongly choosen Graddle and is building around it now
> and Graddle is not an issue for Jenkins so I would be for keeping to
> use it.
>
> I will look at your documentation as quickly as possible and setup a
> job for you on ci.xwiki.org. By the way I think you can move your work
> to master branch, no need to keep working on a feature branch. Frankly
> given the state of the current master branch there is no reason to
> spare it...
>
>>
>> 3) Should I create issues in JIRA? Should I include the JIRA issue when
I
>> commit something ?
>
> You don't need to have a different JIRA issue for each commit but it
> would be nice in each commit a reference to the JIRA issue covering
> the feature this commit is about.
>
> For the Android authenticator project, 2 issues (authenticator,
> account synchronizer) should be enough IMO.
>
>>
>> 4) HttpClient or HttpUrlConnection? Or OkHttp/Volley library?
>> HttpClient(org.apache.http.client) has been deprecated and
HttpUrlConnection
>> is a recommended way. So now I use this UrlConnection and write a simple
>> request library to communicate with server. Maybe I can use
okhttp/volley
>> in the future as the way of http request to efficiently process data,
but it
>> may increase the size of the application. But maybe it has more features
>> like cache, spy, connection pool and so on. The cache should be very
useful
>> if large volume of users’ data have to be synchronized, Especially when
>> network is not very good and we request server again and again. Should I
use
>> the okhttp library instead of my custom implementation of http library?
Or
>> other serializable library like gson/xstream instead of the
XmlPullParser?
>
> I agree that using HttpClient is not a good idea if it's deprecated. I
> know nothing about so I could not relly tell you if it's better to use
> this or HttpUrlConnection. What I can tell you is that if you find it
> there things that would really makes things a lot easier/better then
> go for it, I'm sure we can live with an extra 320kB.
>
>>
>> 5) Other ideas and contributions?
>> Maybe after completing this authenticator app, I could rewrite the
>> android-client app with android studio and update the application
interfaces
>> and something out of date. Maybe I can do some translation in Chinese ?
>> Maybe I can update some document?
>> Or maybe I can solve some useful bugs in JIRA for XWiki platform or
>> extension? You know, now I'm not very familiar with such a huge code and
>> even do not know how to start after looking at some of the code. I still
>> need some time to explore. I think now maybe I should first well finish
the
>> android-authenticator. :) And then be familiar with the entire code
>> architecture as soon as possible, and try to find and solve a small
problem.
>> What do you think? Could anyone give me some tips?
>
> For now you should probably concentrate on the GSOC and maybe improve
> things that this project directly depend on (REST API, etc.) if you
> have time and we will be very happy to discuss with you what you could
> work on after that if you want to continue as member of this great
> community :)
>
> Don't worry there is plenty of things that you could do on XWiki
> project as a contributor and we can discuss that depending on what you
> like to work on. One idea maybe would be to lead Android (and other
> mobile) related projects (maintaining Android Authenticator,
> improve/create libraries or final applications like you said,
> improving the REST API, etc.) for example if you want to keep working
> on Android because you will quickly become THE expert (if it's not
> already the case, at least you already know more about Android
> development than me or any XWiki committer I think) in XWiki community
> about those projects anyway ;)
>
>>
>>
>> Thanks,
>> Fitz Lee
>>
>>
>>
>>
>> --
>> View this message in context:
http://xwiki.475771.n2.nabble.com/Design-and-questions-about-Android-authenticator-tp7599355.html--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Locked
