xing / xing-android-sdk Goto Github PK

Right now the default error class that is returned from the api client is HttpError but when error json is not matching HttpError and there is no CallSpec::errorAs defined than the api client instead of HttpException will throw JsonSerializationException.

Expected behaviour:
HttpException with String as an field error

Currently the api for com.xing.api.oauth.XingOAuth is a little bit misleading. The XingOAuthCallback implies the the response will be processed asynchronously, when in reality it's just notifying the callback based on bundle coming from the authentication activity.

An alternative solution would be to make XingOAuth#onActivityResult return a XingOAuthResponse object, similar to com.xing.api.Response.

Use Moshi for request response parsing.

• Use com.squareup.okhttp.Response to be able to access the raw response body (this will speedup parsing == no intermediate buffers between the parser and the response stream)
• Depends on #11

Provide implementation for messages calls.

Currently we are using java.util.GregorianCalendar and java.util.Calendar for dates. This creates a layer of inconvenience, adds complexity to the data models and requires more effort for support.
Since Java8 there a new Time api was introduces, also know as JSR-310. But since we are targeting the Android platform we can not leverage from this rich and simple api. ThreeTen is a backport (written by the author of JSR-310) of that api to Java 6 and Java 7 with a (semi)active repo on Github::threetenbp.

Proposal:

• Investigate the the backport library.
• Analyse how much overhead it may add.
• Replace all time related fields with ThreeTen classes?

Currently the api client sets it's own oauth callback for every attempt. But for release/production key the user needs to set it's own callback.

When we move the data module generation to AutoValue #137, we can add a companion class generator, that will allow to build a user fields array. This is useful for resources like UserProfilesResource where the spec accepts model fields that have to be returned by the api.

This will reduce the probability runtime bugs, when using accessing a resource.

Things to keep in mind:

• The api accepts nested field names as well, like field1.sub_field1.sub_sub_field2 the annotation processor will have to lookup for dependent builders.
• The generated builder like class Fields should be something like:

@GenerateFields // Name not final.
abstract class XingUser {
  abstract class Fields {
    Fields field1();
    String[] build();
  }
}

consider updating How to get Started section of the Readme.
Update gradle and maven sections with latest version number instead of x.y.z
This is a change of 2 lines on every release...

further consider that compile is deprecated in future releases of the android gradle plugin - maybe add the corresponding implementation maybe as:
For tools com.android.tools.build:gradle:3.0.0 use implementation 'com.xing.api:api-client:2.1.5'

thx in advance

Currently we are declaring all models manually. This creates an overhead for us when maintaining hashCode, equals() e.t.c. AutoValue will solve this problem for us.
Another pro is the new extension api of AutoValue which gives us a rich combination of possibilities.

Hi,

why are you removing the XingOAuthCallback and replace it with calling onActivityResult() in the calling activity? Using the XingOAuthCallback makes it easier to separate the Xing calls from the normal logic, especially if the Xing login can be done on every activity of a project

Provide implementation for network feed calls.

@serj-lotutovici

As is now
When running a Task and trying to cancel it with TaskManager.cancelExecution(...) a NetworkException is thrown, which basically makes impossible to differentiate from a real network issue (like no internet).

Should be
A different kind of exception should be thrown in order to do something specific or just ignore it.

Hi,

I tried to play around with the API client, but I can't find my OAuth-Credentials. When I go to the page described in the README under "2. Add OAuth credentials to your project" I can't create an app to retrieve my credentials. Where do I have to click? It says "You don’t have any apps, ask your XING representative if you need to create one.", but there is no contact address or whatever. How can I get the client to work?

Regards

Since the current implementation is causing crashes doe to activity and application lifecycle, we need to avoid implementing the singleton pattern for the user. The design should promote the users to create a single object of the XingController via a simple builder and use it, instead of relying on us to do that.

This means:

• No need for initialisation checks during instance access (this should be done only once by the builder during creation of the XingController). Short: If the instance was created by the builder, it is a valid one, loss of the instance will require to recreate it.
• No need for the XingController#flush(), if the user whats to drop or re-initialise the object, he will only have to null the reference.
• Allows users to inject the instance via a Dependency Injection framework, instead of loosing control of where the XingController#getInstance() is called.

We need a single callback to notify the user that there was an authentication error. This callback should be huced up to XingApi and should be invoked when, and ONLY when the server sends us an un-authorized error.

The only question that remains, is should we allow the error to pass through the callback an not be "consumed"? Or should we make the caller completely un-aware of the error?

#27.09.2016

• Add CHANGELOG.md
• Javadocs for all public apis
• Final cleanup
• Rename LegalInformation to LegalInformationPreview

The stream() method lifts the rawStream() one with OperatorMapResponseToBodyOrError<RT, ET> but this operator is currently ignoring the error type ET in case of an error:

                @Override
                public void onNext(Response<RT, ET> response) {
                    if (response.isSuccessful()) {
                        child.onNext(response.body());
                    } else {
                        child.onError(new HttpException(response));
                    }
                }

                @Override
                public void onCompleted() {
                    child.onCompleted();
                }

                @Override
                public void onError(Throwable th) {
                    child.onError(th);
                }

Therefore the problem is that whenever the backend returns any kind of error onNext won't be called but so will onError with a throwable like java.io.IOException: 401 Unauthorized thus ignoring our error type and even the JSON with the proper reason.

Please correct me if I'm wrong. I'll investigate and try to make a PR tomorrow.

XingApiClient should give the option to cache requests or not while building requests to give the caller the option to decide if it is better to cache or not.

When we use callbackUrl it fails to validate because of:
Shared.validate should call input.matches(pattern) but not in other direction. see: https://developer.android.com/reference/java/lang/String.html#matches(java.lang.String)

Please add "." to XingOAuth.Builder.CALLBACK_PATTERN. Because we want to use "https://our.domain.com" and it will not allow us with current pattern.

iOS part works fine with this callback.

Currently each resource declares a method, that returns a CallSpec, each declared method uses helper factory methods to build the resulting spec. This created multiple problems with the api flexibility, and is is not type safe. A good approach to adopt the reflection based method, to provide an implementation for each method like Retrofit does, but in a more restricted fashion:

• Allow returning only CallSpec
• Support only GET, PUT, POST and DELETE requests

We probably want to do this smart. Add common constants to the parent Resource class, and domain specific to each respective resource implementation.

@akreul @andretietz could you comment on this ticket with all your findings... I want to push this with a single pr.

Version 2.0.0 will be released with OkHttp 2.7.x. We should consider adopting the 3.x api. This will allow us to benefit form the new connection pool implementation, and a more clear api.

One concern that I have, is related to the fact, that 3.x mostly introduced api changes with minor beneficial improvements. As I know 3.1 will fully drop support for url-connection and apache clients, which will improve the library's stable factor. Should we wait till that happens?

When the api returns something like:

"geo_code":{"accuracy":null,"latitude":null,"longitude":null}

i.e. JobsResource#getJobById

the object gets created on parse time and contains -1,-1

the whole geoCode object should be null

Current version is 3.4.1 while latest is 3.9.0

In order to test clients receiving a possible exception of this type there's no way to mock HttpException since is final and the same with Response (apart from having all fields package-protected), so instead of:

HttpException mock = mock(HttpException.class);
when(mock.code()).thenReturn(...);
when(mock.message()).thenReturn(...);

There's no possible way to create a mock/testing instance.

Currently moshi does not support this. But we should try to adopt this as soon as this is implemented.
Follow square/moshi#115.

Currently, each consumer who will add the api client as a dependency will add to it's class path the "full package" of supported resources. It makes sense to put each non-primary resource (like: JobsResource, EventsResource e.t.c.) to a separate module, which will be published as as standalone artefact.

Since each resource may require a specific data module and a custom json adapter, we need to think of a way which will allow users to specify those adapter, and/or additional configuration requirements.

https://codecov.io/

An example report on a PR:

Please see the attached image, i had been completely respecting XING url format as xing had mentioned in expected input as highlighted in red circle while the actual url highlighted in green circle.

Can anyone please help resolve this error because i assume now XING sdk should not through illegal argument exception but still it does.

Thanks

It would be nice to use the latest android build tools.

• android gradle plugin 1.5.0
• compile sdk 23
• build tools 23.0.2

We need to pass optional parameters as body in DELETE requests.

Pls add them like in PUT and POST requests.

At the moment, we are duplicating some methods exposed by OkHttpClient.Builder when we construct the instance of XingApi. A better approach would be to just expose a XingApi.Builder.client() or any other method, and leave the rest on the shoulders of the library user.

This has a few benefits, as well as a few side-effects:

• [+] Separate the auth activity and classes from the core of the sdk. Because the xing app implements it's own login mechanism we carry this code as loose weight.
• [+] Possibility to provide the sdk as a jar and not an arr. This is a long shot, but what if java based application would also need to use an sdk, creating 2 separate libraries just doesn't make sense (will come back with more info on this)
• [+] Minimize the wait of the artefact. Currently the sdk 1.0.0 is 186.07 K, in comparision retrofit is only 67K
• [-/+] If we go with the java only track we lose the possibility of accessing some of android's apis, for a library that makes network calls and handles responses this may not be an issue, but what if the sdk will become something more?
• [-] The sdk will have to be semi aware of the environment its running on, which means extra support for both platforms (java and android). We will also have to keep in mind that android is still in the java 7(6?) world and this restricts us from blindly moving to a newer java version, or even using some java 7 apis like try-with-resources (seriously Google couldn't back port that >_>)
• [-] The module classes will may have to become just module classes with no awareness of some android interfaces (again adding to the plain java track)

For now it's just an idea an crazy mans head.

Users must be able to use RxJava and RxAndroid if this is there main way of handling asynchronous and data flow behaviour.

Conditions:

• Execute requests returning an Observable
• Users must provide RxJava in order to use this feature. The final aar file must not contain the actual dependency.

Provide implementation for jobs calls.

Hi,

according to https://dev.xing.com/plugins/login_with/docs the Javascript-Library has the capability to do a logout on the server side ("xing.logout(callback, consumer_key);"). Is it also possible to do this with this sdk?

Best regards,
Boris

Since starting from Android KitKat the HttpUrlConnection implementation is using the OkHttp one, it makes sense to use OkHttp directly for network requests to avoid an additional implementation layer.

The feature must consist of:

• Removing unnecessary RequestExecutor abstraction. All request manipulations must go through the request client.
• Possibility to return raw responses for additional error and custom response handling
• Consider possibility of removing the custom Request implementations
• XingController must allow initialisation with a custom (or semi-custom) OkHttpClient

Implement request interceptor that will handle request signing.

Depends on #11

For some requests with pagination, XWS returns a Content-Range header which contains the current data offset + total values.
If the header is set, there are to possible outcomes:

• Content-Range: items 2-23/130 (if the total is known)
• Content-Range: items 3-34/* (if the total is unknown)

We need to parse this on a successful response, and pass this data inside a field of com.xing.api.Resposne.

Hi,

It would be nice to be able to change the apiEndpoint from XingApi in runtime. Seems it should be possible by just providing a setter, which would set the new endpoint and invalidate the resource cache?

Provided implementation for recommendations calls.

Currently the CallSpecTest is a mess of tests with deferent scopes. Would be nice to separate the tests. For example like so:

• CallSpecBuilderTest - should contain everything related to the builder api
• CallSpecTest - should contain everything related to the CallSpec api (exept for it's reactive apis)
• CallSpecRxTest - should contain everything related to CallSpec's reactive apis.

Since OkHttp depends on it, there's no need to have them as separate dependencies.