Redirecionamento para portal da Vivo com acesso ao 3G

Mobile
#1

Pessoal, bom dia.

Eu fiquei na dúvida se este tópico deveria ser criado aqui. Mas como se trata de um problema com desenvolvimento que estou tendo, apesar de entender que se trata do péssimo serviço oferecido pelas operadoras em nosso país.

Seguinte:

Eu tenho um plano de internet vivo empresarial com limite de 300MB.

E notei diversos problemas que não sei como contornar, por exemplo.
O meu aplicativo se comunica com um web service.

E quando o 3G estoura o limite de 300MB ou a vivo impõe qualquer tipo de redirecionamento para o seu site. Aquele portal-sva.com.br ou mesmo para o site meuvivo.com.br o que acontece é que o acesso ao web service é barrado, enquanto eu não acessar o navegador e selecionar uma opção.

Fiz um teste agora, não estava conseguindo acessar o web service pelo aplicativo, eu tive que abrir o navegador selecionar uma opção do site da vivo, ai tentei utilizar o aplicativo novamente e não funcionou, voltei no navegador abri o web service pelo navegador e ai então o aplicativo conseguiu fazer as requisições ao web service.

Criei este tópico aqui para saber se há algum tipo de tratamento, pois aplicativos como Gmail e alguns outros conseguem atualizar mesmo com isso. Outros dão erros como Instagram, já o aplicativo do Facebook por exemplo dá erros ocasionais de Erro de Rede, mas se você insistir diversas vezes ele acaba atualizando.

Isso já me custou noite de sono rs, uns dias atrás a primeira vez que isso ocorreu o aplicativo parou de se comunicar com o web service de repente e passei horas tentando descobrir o que era sem notar que era o redirecionamento para o site da vivo.

Alguém já teve problema com isso ou conseguiu tratar de alguma forma?

Se o tópico não deveria ser criado aqui para tratar deste assunto me desculpem.

Obrigado desde já.

#2

Bom, você nunca parou para pensar por que é que há alguns planos em que as operadoras dão o acesso ilimitado ao Facebook para pré-pagos?

De fato, deve haver várias exceções nas regras que as operadoras usam para a medição dos pacotes.

#3

Entendo, mas então não há uma maneira de contornar isto?

Um usuário que está utilizando meu aplicativo e utiliza tal operadora, pode um belo dia tentar utilizar o aplicativo e não conseguir? Brincadeira isso…

Para falar a verdade já é um erro ter de responder todo mês se quero continuar com velocidade reduzida ou continuar com a velocidade normal pagando excedentes, isso deveria ser configurado apenas uma vez e se eu quisesse alterar eu iria no site ou ligaria lá.
Bom mas de qualquer forma aqui não é o reclame aqui rs…

#4

O problema é achar alguém na operadora que ensine o que deve ser feito nesse caso :frowning:

#5

Na verdade não há muito o que ser feito. O que ocorre é um redirecionamento pros sites da vivo no próprio gateway deles. Você pode tratar a resposta pra ver se houve redirecionamento e informar ao usuário ou mostrar a resposta.

O Trillian vivia dando erro de comunicação quando eu estourava o limite. Aí eles atualizaram a versão pra mostrar o html retornado se houvesse redirecionamento. Aí pelo menos eu podia resolver direto no aplicativo.

O que acontece nos aplicativos onde você consegue acesso é que eles não são redirecionados por alguma regra (protocolo utilizado, gratuidade do serviço, etc.).

Ah! E não se esqueça dos ambientes onde o usuário precisa se autenticar via página web num proxy. Vai acontecer o mesmo problema. (Não sei se o seu caso se enquadra aqui, mas é bom ter isso em mente.)

#6

[quote=Ataxexe]Na verdade não há muito o que ser feito. O que ocorre é um redirecionamento pros sites da vivo no próprio gateway deles. Você pode tratar a resposta pra ver se houve redirecionamento e informar ao usuário ou mostrar a resposta.

O Trillian vivia dando erro de comunicação quando eu estourava o limite. Aí eles atualizaram a versão pra mostrar o html retornado se houvesse redirecionamento. Aí pelo menos eu podia resolver direto no aplicativo.

O que acontece nos aplicativos onde você consegue acesso é que eles não são redirecionados por alguma regra (protocolo utilizado, gratuidade do serviço, etc.).

Ah! E não se esqueça dos ambientes onde o usuário precisa se autenticar via página web num proxy. Vai acontecer o mesmo problema. (Não sei se o seu caso se enquadra aqui, mas é bom ter isso em mente.)[/quote]

Entendi.

Sim cara esse caso que você citou se enquadra perfeitamente nisto.

A primeira vez que ocorreu isso, foi na hora do Login. Fui implementar mais coisas no aplicativo e um processo de login com usuário e senha que estava funcionando normalmente não funcionava mais. Perdi muito tempo tentando entender o que estava acontecendo, até por não esperar que isso pudesse ocorrer a última coisa que fui verificar foi acessar o web service pelo navegador, só nisso ai foi um bom tempo perdido…

Eu vou ver se coloco algum tratamento, nem que for para informar para o usuário que o problema é no 3G dele e até uma orientação ou coisa do tipo.

#7

Aboult, conseguiu resolver esse problema?

Estou na mesma situação e não consigo encontrar uma solução.

http://www.guj.com.br/java/310134-http-android

#8

Ataxexe, tem alguma ideia que possa me ajudar a dar uma solução para esse problema?

Como você resolve direto no aplicativo?

Eu consegui contornar a situação com o codigo abaixo:

	URL url = new URL(url);
			connection = (HttpURLConnection) url.openConnection();
			connection.setInstanceFollowRedirects(false);
			HttpURLConnection.setFollowRedirects(false);
			connection.setReadTimeout(10000); 
			connection.setConnectTimeout(30000);
			connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
			connection.setDoInput(true);  
			connection.setDoOutput(false);  
			connection.setUseCaches(false);  
			connection.setRequestMethod("GET");

O problema esta resposta do servidor.
No codigo abaixo, aguardo uma resposta mais nao me retorna nada, ai, o return do meu metodo indica que a houve problema na autenticação .

Se eu deixar esse codigo desse jeito e colocar no return do metodo que a resposta da autenticação foi um sucesso, roda tudo legalzinho.

O unico problema que estou tendo é isso, preciso pegar a resposta do servidor para tratar a autenticação.

	InputStream is = connection.getInputStream();
			int ch;
			StringBuffer sb =new StringBuffer();
			while((ch = is.read()) != -1){
				sb.append( (char)ch );
			}
			is.close();

Obrigado.

#9

[quote=leandrooooo]Ataxexe, tem alguma ideia que possa me ajudar a dar uma solução para esse problema?

Como você resolve direto no aplicativo?

Eu consegui contornar a situação com o codigo abaixo:

	URL url = new URL(url);
			connection = (HttpURLConnection) url.openConnection();
			connection.setInstanceFollowRedirects(false);
			HttpURLConnection.setFollowRedirects(false);
			connection.setReadTimeout(10000); 
			connection.setConnectTimeout(30000);
			connection.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
			connection.setDoInput(true);  
			connection.setDoOutput(false);  
			connection.setUseCaches(false);  
			connection.setRequestMethod("GET");

O problema esta resposta do servidor.
No codigo abaixo, aguardo uma resposta mais nao me retorna nada, ai, o return do meu metodo indica que a houve problema na autenticação .

Se eu deixar esse codigo desse jeito e colocar no return do metodo que a resposta da autenticação foi um sucesso, roda tudo legalzinho.

O unico problema que estou tendo é isso, preciso pegar a resposta do servidor para tratar a autenticação.

	InputStream is = connection.getInputStream();
			int ch;
			StringBuffer sb =new StringBuffer();
			while((ch = is.read()) != -1){
				sb.append( (char)ch );
			}
			is.close();

Obrigado.[/quote]

Então Leandro, na realidade ocorreram duas coisas.

Não consegui pelo menos não na época resolver de uma maneira que possa se chamar de resolução realmente.

Pois eu fiz o que me sugeriram acima, tratei com Try Catch nos lugares da requisicao, então ele identifica que tem internet e executa a requisição ai na requisição ele vai dar erro porque ele está conectado, mas não tem plano de dados suficiente, então nesse momento eu trato em um Try Catch e dou uma mensagem genérica avisando o usuário.

Como aqui eu lido com aplicativo comercial nós damos o suporte aos clientes, então fica fácil pela mensagem já avisar o que é e dar uma solução.

Um outro ponto também que ocorreu é que apenas um cliente usava plano de dados que caía nessa situação e ele acabou por trocar um tempo depois. Então não tive mais problemas com isso, mas havia resolvido mais ou menos dessa forma que detalhei.

Cheguei a ver também uma solução na internet, onde os caras criaram um método no ws só para testar realmente se o plano de dados está conseguindo fazer uma requisição e pegar o retorno. Então na própria checagem de internet além de checar se tem internet ele chama esse método para validar a internet, não sei até onde é viável. Eu preferi não fazer dessa forma para não ficar fazendo requisições constantes a cada checagem de internet.

#10