Do you plan to support self signed Ssl certificates?

[pommedeterresautee]

I have my own certificate on my server and I want to use this one. For now I do it using lots of code. And I m using the ugly asynctask. Do you think you can add a kind of sslfactory setter? Or even better you ask me my keys tore ressource and the pwd and the lib managed everything, would be super cool.

[stephanenicolas]

Hi pommedeterresautee,

would you mind to give some sample code. we are pretty open to new features but would like to get a clear idea of what you need.

Just provide a sample asynctask of yours.

s.

[pommedeterresautee]

Hi, thank you for your answer.

I ve searched a lot yesterday and it is managed at the spring level... There is already a setter for httprequestfactory.

Thank you anyway for this library.

Ps:did you think about simplify the sample? By example in Sherlock actionbar there is one function only per activity... In yours there are several function, injection... A real user doesnt need to make the request in xml AND in json too. It's just a suggestion.

[stephanenicolas]

Hi Patateo,

in robospice motivations we tried to limit the size of the examples :

• one activity for json
• one activity for xml + orm lite (that is maybe too much)
• one activity for binary requests.

If you have a suggestion to make it lighter, tell us. We would be interested.

Thanks for your comments. Thanks also for ShowCaseView. It inspired me a lot for RoboDemo btw.

Stéphane

2012/11/2 El Potaeto notifications@github.com

Hi, thank you for your answer.

I ve searched a lot yesterday and it is managed at the spring level... There is already a setter for httprequestfactory.

Thank you anyway for this library.

Ps:did you think about simplify the sample? By example in Sherlock actionbar there is one function only per activity... In yours there are several function, injection... A real user doesnt need to make the request in xml AND in json too. It's just a suggestion.

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/6#issuecomment-10007425.

[pommedeterresautee]

Oh, I just noticed you are the author of RoboDemo! Well done.

About the simplification, here https://github.com/octo-online/robospice/blob/master/robospice-sample/src/com/octo/android/robospice/sample/SampleContentActivity.java there is some injection.

A good simplification would be to remove all of them.

I've implemented in the past Roboguice in my app (a big one), it made my application very slow at the launch and add the injection layer complexity (complexity to understand when you want to do something a little bit special, even if at the end it simplifies the code). Is it not possible to get rid off it? Because right now, it looks like you need it to make to make your lib work.

For the sample, I would make one activity per function, and use only the libraries absolutely needed to make it work. Look here: https://github.com/octo-online/robospice/blob/master/robospice-sample/src/com/octo/android/robospice/sample/SampleContentActivity.java too much things I think...

If an activity needs several particular class, I would made different package, one per activity, and one folder for the shared classes. The idea is like : I want to use this lib, I need this function, I search my case in the packages, I copy past, I make it work and finally I personalize and make things more optimal.

I think sherlockactionbar is a good start point for that. There is a listview pointing to each activity, you search the effect you want on your phone, and finish on your computer.

I understand you want to limit the size of the sample but if you divides the complexity in independent packages, it's not anymore an issue. You will have the simplicity and give a complete information.

Another thing I've seed which is a good idea also, is to include the main part of the code for a particular request in the documentation displayed in the application. You have already some description text. It won't be a big change to add some code in the description. You know you are in the subway, and you are thinking about the REST layer... It can help...

And finally you should improve your website documentation.

Lots of comments I know, it's already very well done, but you ask for some remarks, and to make it short your lib looks like... too much professional :-)

++

[stephanenicolas]

Hello Patateo,

thanks for all your feedback. I will get into all that this week.

Actually, you are right, the robospice motivations app may be too big. But it's meant to explain why RoboSpice fills a need in Android. It's also a sample, but not only a sample.

I now code all my apps using roboguice and abs and some other libs. So, it would be difficult to get a satisfactory code for me without using all these.

About the code, it's really a good idea to put it inside, I have thinking about it. What I would like would be to let the user browse the real source code of the app, but I couldn't find a way to do it. Maybe the best option would be to redirect the user to the right page of the git hub repo and let it see the source code, prettyfied by git hub. What do you think ?

2012/11/2 El Potaeto notifications@github.com

Oh, I just noticed you are the author of RoboDemo! Well done.

About the simplification, here https://github.com/octo-online/robospice/blob/master/robospice-sample/src/com/octo/android/robospice/sample/SampleContentActivity.javathere is some injection.

A good simplification would be to remove all of them.

I've implemented in the past Roboguice in my app (a big one), it made my application very slow at the launch and add the injection layer complexity (complexity to understand when you want to do something a little bit special, even if at the end it simplifies the code). Is it not possible to get rid off it? Because right now, it looks like you need it to make to make your lib work.

For the sample, I would make one activity per function, and use only the libraries absolutely needed to make it work. Look here: https://github.com/octo-online/robospice/blob/master/robospice-sample/src/com/octo/android/robospice/sample/SampleContentActivity.javatoo much things I think...

If an activity needs several particular class, I would made different package, one per activity, and one folder for the shared classes. The idea is like : I want to use this lib, I need this function, I search my case in the packages, I copy past, I make it work and finally I personalize and make things more optimal.

I think sherlockactionbar is a good start point for that. There is a listview pointing to each activity, you search the effect you want on your phone, and finish on your computer.

I understand you want to limit the size of the sample but if you divides the complexity in independent packages, it's not anymore an issue. You will have the simplicity and give a complete information.

Another thing I've seed which is a good idea also, is to include the main part of the code for a particular request in the documentation displayed in the application. You have already some description text. It won't be a big change to add some code in the description. You know you are in the subway, and you are thinking about the REST layer... It can help...

And finally you should improve your website documentation.

Lots of comments I know, it's already very well done, but you ask for some remarks, and to make it short your lib looks like... too much professional :-)

++

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/6#issuecomment-10018596.

Stéphane NICOLAS, OCTO Technology Développeur & Consultant Android / Java .......................................................... 50, Avenue des Champs-Elysées 75008 Paris +33 (0)6.26.32.34.09 www.octo.com - blog.octo.com www.usievents.com ...........................................................

[pommedeterresautee]

About the documentation, look at how AndroidQuery is doing: https://play.google.com/store/apps/details?id=com.androidquery&feature=nav_result#?t=W251bGwsMSwxLDMsImNvbS5hbmRyb2lkcXVlcnkiXQ..

The author only includes the main part of the code. I think it's sufficient. Moreover your library have not to change its interface every day, so you don't really need Github. And finally by using Github you make the code consultation only possible with Internet. It's not a big deal but it's better to be operational without.

About RoboGuice really, I hate it and I am not the only one. The sample is here to make a use like me to understand how your code is working. But right now you are showing how you program. About the documentation point it's very subjective (you may like the github complete doc or a shorter version one) but about including tons of librarie things to explain only one thing... for sure it's a bad idea. You know what, the first time I saw your lib, I noticed the activity extended and say, Ok not for me. I did'nt take the time to understand why and what it was. After I came back because I was too much curious and I understood it was because of the use of Roboguice.

Imagine a new programmer, he wants to use: the sample is here to explain, and before finding how it works, he will learn what is injection, how to include it in its project, how works Spring... too much in my opinion. You will loose lots of people in the process.

Another thing (I know I love to complain), you should hide the Spring complexity behind your own interface.

Spring may be cool but it has its own concepts. An Android user like me (means not pro) knows about the Apache class, may be the the URLConnection class and how to make them work. Why adding a new layer of complexity?

In my own project I can request whatever I want in 2 or 3 lines. I have several factories for the request. They all implement the same interface. I inject the factory inside a requestClass. Each request class extends an abstract one (template pattern). The template (abstract class) includes one hooker before the execution of the REST request (to transform a POJO in JSON), after the request is build with the factory injeted in the constructor, the request is executed and finally a last hooker make possible to transform the result in a POJO.

Nothing complicated.

If you want to hide the complexity of Spring, I would copy the interface (function names...) of Apache lib as everybody already knows about it.

In a perfect world, you hide all the complexities and at the end you would have something like:

'''java GetObject obj = new GetObject("www.blabla"); Executor exec = new Executor(obj); exec.start(); '''

If you want to transform the final result from JSON to POJO:

'''java GetObject obj = new GetObject("www.blabla"); JSONTrans json = new JSONTrans < MyClassType > (); Executor exec = new Executor(obj, json); MyClassType blabla = exec.start().get(); '''

The point is that if you want your library to be widely and get lots of contribution it should be super easy to use. Right know, for me, it is not. Again, I am not a pro and it may explains that.

Anyway, I think I ll meet you soon I will probably go to the Meetup next week where I assume it's you who will present your own lib!

[stephanenicolas]

Hi pomme de terre sautée,

sorry for the delay. It took me quite a lot of time to read your mail. Thanks for taking time to write it.

Actually, you convinced me. I'll talk about this to other co-authors and come back to you. But I believe we will get rid of roboguice, abs and other librairies in a simpler and more complete sample. Motivations can remain as it is I believe and we shall now focus on a simple sample program. A better version of the sample.

In RoboSpice, there is no obligation to use any module like the Spring Android Module or the new comer Goole Http Java Client to be released in 1.3.0. We provide those modules as proof of concepts, more robust and usable but they are just examples of good usage of RoboSpice.

We never thought about using an HttpUrlConnection in a sample. This technology as drawbacks. The biggest one is maybe that it doesn't work well on older versions of Android. And we don't want to encourage people to use a tech that we wouldn't use.

From this perspective, we made modules for Spring Android and Google Http Java Client as they provided a reliable and backward compatible REST Client with parsing of JSON (using other specialized, more efficient technologies than the built-in ones).

We even think of extending those experiments to other technologies we would like to test like restfix of Square or jersey client for android. Again, these are experiments and proofs of concepts and show how far we can go using RoboSpice.

On an different perspective, the kernel of RoboSpice is completely REST agnostic and we even worked on it to make it network agnostic. It can now be used to execute any ind of long running background task with caching capabilities. In that meaning, the kernel of RoboSpice will not try to provide a unified abstraction layer for all REST clients.

We prefer this diversity and let people who are familiar with a tech play directly and freely with it. If you know Spring Android, you will fill confortable with the RoboSpice Spring Android Module, same for Google Http Java Client. If you don't, just keep the cache and core modules and DIY. That's our philosophy and up to now we see a lot of benefit to include new technologies as modules only.

This degree of freedom in RoboSpice allows for other refinement. One of them is as simple as : you can do what you usually do (I mean within the example you gave in your comment), using robospice. Nothing prevents you from doing that. We don't think it's the easiest and more robust way to it, but if you like it, do it this way. All we want, in the kernel of RoboSpice, is that devs can get their hand on a lib that makes it easy to use a service for networking. That's a good practice and we want to contribute to widespread it.

Other modules are extensions, plugins. We added a new page in the wiki to talk about this idea.

BTW, did we meet finally ? I need some refresh, I met far too many people last month..

[stephanenicolas]

I pomme de terre sauté, our discussion samples was quite off topie. I have searched a lot where we talked about that to answer you. Release 1.4.0 of RoboSpice will include a lot of new samples, all of them have been refactored to be more simple, they are even in a new repo. We will have a more flexible release live cycle as well, and the library is now more modular and more tested. Thanks for your feedback, it was tough but we adopted a lot of your recommandations now.

About the initial topic of self signed certificates, I don't know how to tackle that. If you or someone else does know, a fork and a pull request would be appreciated. Otherwise, I will close the issue in a few days now.

[pommedeterresautee]

Hi Nicolas,

It is very funny as I followed your advice to not use directly HttpUrlConnection (I switched to the Google Lib).

About the SSL thing, what do you need exactly? The code to create a SSL factory?

[stephanenicolas]

Our libs are better now :)

About SSL, really, feel free to do you best to answer your own question. I just don't know this topic at all but some people told me it would be interesting to allow a feature like this, so if you want to contribute to a sample, or modify RoboSpice, go ahead.

Stéphane

2013/1/5 El Potaeto notifications@github.com

Hi Nicolas,

It is very funny as I followed your advice to not use directly HttpUrlConnection (I switched to the Google Lib).

About the SSL thing, what do you need exactly? The code to create a SSL factory?

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/6#issuecomment-11919684.

Stéphane NICOLAS, OCTO Technology Développeur & Consultant Android / Java .......................................................... 50, Avenue des Champs-Elysées 75008 Paris +33 (0)6.26.32.34.09 www.octo.com - blog.octo.com www.usievents.com ...........................................................

[ohdonpiano]

Any news on supporting SSL certificates within robospice?

[stephanenicolas]

Hi Daniele,

we used RS in a couple of professional applications since last year and we found different ways to verify SSL certificates by ourselves. For instance, using spring android, you can set the connection factory to use URLConnection more than the apache http client and then use SSLContext to pass it a keychain and accept certificates or not. If you use Retrofit, there are also differerent possibilities to do that, same for Google Http Java Client.

RS has been designed to be protocole agnostic. The extensions of RS (Spring Android, Google Http Java Client, or Retrofit) have their own way to handle SSL certificates. We don't plan to support, and most probably never do it, SSL certificates in RS directly. It's really yours to customize any library you use within RS to accept or not SSL certificates.

Stéphane

2013/10/30 Daniele Poggi notifications@github.com

Any news on supporting SSL certificates within robospice?

— Reply to this email directly or view it on GitHubhttps://github.com/octo-online/robospice/issues/6#issuecomment-27423747 .

Stéphane NICOLAS, OCTO Technology Développeur & Consultant Android / Java .......................................................... 50, Avenue des Champs-Elysées 75008 Paris +33 (0)6.26.32.34.09 www.octo.com - mobilite.octo.com blog.octo.com - www.usievents.com ...........................................................

[Lingviston]

Can anyone provide an example of implementing SSL connection in Google Http Client Robospice extension without "breaking" Robospice a lot? I've tried to use code from http://stackoverflow.com/a/7447273/1897423 but it doesn't work (for now I agree to trust all certificates). I still get java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.

[rciovati]

I would try something like this, which is a modified version of the google http client sample

package com.octo.android.robospice.sample.googlehttpclient;

import android.app.Application;
import android.util.Log;

import com.google.api.client.extensions.android.AndroidUtils;
import com.google.api.client.extensions.android.http.AndroidHttp;
import com.google.api.client.http.HttpTransport;
import com.google.api.client.http.apache.ApacheHttpTransport;
import com.google.api.client.http.javanet.NetHttpTransport;
import com.octo.android.robospice.GoogleHttpClientSpiceService;
import com.octo.android.robospice.persistence.CacheManager;
import com.octo.android.robospice.persistence.exception.CacheCreationException;
import com.octo.android.robospice.persistence.googlehttpclient.json.JacksonObjectPersisterFactory;

import java.security.GeneralSecurityException;

/**
 * Simple service
 *
 * @author sni
 */
public class SampleSpiceService extends GoogleHttpClientSpiceService {

    @Override
    public void onCreate() {
        super.onCreate();

        try {

            if (AndroidUtils.isMinimumSdkLevel(9)) {

                NetHttpTransport.Builder builder = new NetHttpTransport.Builder();

                httpRequestFactory = builder
                        .doNotValidateCertificate()
                        .build()
                        .createRequestFactory();
            } else {

                ApacheHttpTransport.Builder builder = new ApacheHttpTransport.Builder();

                httpRequestFactory = builder
                        .doNotValidateCertificate()
                        .build()
                        .createRequestFactory();
            }

        } catch (GeneralSecurityException e) {

            Log.e("SampleSpiceService", "Error: " + e.getMessage());

            httpRequestFactory = createRequestFactory();
        }
    }

    @Override
    public CacheManager createCacheManager(Application application) throws CacheCreationException {
        CacheManager cacheManager = new CacheManager();

        // init
        JacksonObjectPersisterFactory jacksonObjectPersisterFactory = new JacksonObjectPersisterFactory(application);

        cacheManager.addPersister(jacksonObjectPersisterFactory);
        return cacheManager;
    }
}

Don't have the time to test it, let us know if it works.

[Lingviston]

Well, now I'm getting Unsupported Media Type exeption.

But this is another issue. Your solution seems to work, thanks!

[menklab]

I got https with a self signed cert to work following this posts suggestions: http://forum.spring.io/forum/spring-projects/android/117381-trying-to-acess-an-ssl-resource-fail

I have included the basics below for easy copy and paste. Note the port 8443 and 8080. These will need to set to 443 and 80 if you are talking over default protocols.

[stephanenicolas]

Hi @Menkveldj, RS is protocole agnostic. It doesn't relu on neither on http nor hppts.

We offer extensions for common use cases, including networking. Spring Android is one of them. If you want more than the default we offer, customize a RS service to achieve it. It's easy for you to build your own service to get support for this kind of feature.