Podríamos definir a los influencers como personas con gran presencia y credibilidad en redes sociales gracias a su conocimiento en cierto sector.

La llegada de la web 2.0 presentó un panorama en el que la opinión de cualquier usuario podía generar una corriente de opinión. Desde hace tiempo en las facultades de periodismo se pone el ejemplo del escándalo Clinton-Lewinsky (1998) como una de las primeras noticias que se difundió antes por internet que en los medios tradicionales.

Hoy, ese es nuestro día a día y rara es la noticia que no se propaga más (y no necesariamente mejor…) por internet.

Eso es una oportunidad y a la vez un riesgo para cualquier marca o personaje preocupado por su éxito corporativo o personal.

Oscar del Santo, experto en reputación online defiende la siguiente fórmula:

Éxito Online = (Nº de promotores de tu marca) x (Nivel de influencia de los promotores)

Podríamos diferenciar dos tipos de influencers:

• El nativo digital: es teóricamente imparcial. A menudo es influencer de forma espontánea e inconsciente; le gusta una marca y la recomienda. Otras veces es contactado por las propias marcas para probar sus productos puesto que aportan credibilidad.

• La celebrity online: es básicamente eso, alguien influyente offline que en un momento dado extrapola esa popularidad a internet. Para las marcas, puede ser tan efectivo como la publicidad convencional y más barato.

Según un estudio de Movistar, el 56% de las mujeres y el 54% de los hombres han tenido en cuenta alguna vez las recomendaciones de personas a las que siguen en entornos sociales.

Por lo tanto podríamos concluir que un influencer es un gran altavoz.

Tengamos en cuenta algunas consideraciones, las peticiones http deben ejecutarse de una manera asíncrona, el motivo es porque a partir de la versión 4 de android dará un error si estas peticiones se ejecutan en el hilo principal, y esto tiene sentido, pues este tipo de sentencias pueden ralentizar la aplicación, aún así, en las versiones 2.x de android funcionará si lo ejecutamos en el hilo principal. Para evitar errores usaremos un proceso Asynctask para comunicarnos con el servidor.

Veamos, primero necesitaremos el diseño de la actividad principal, algo simple, no se necesita pintar la capilla sixtina, el xml del diseño principal quedaría así.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:orientation="vertical" >
    <TextView
        android:id="@+id/textView1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/usuario"
        android:textAppearance="?android:attr/textAppearanceLarge" />
    <EditText
        android:id="@+id/txtUsuario"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:ems="10" >
        <requestFocus />
    </EditText>
    <TextView
        android:id="@+id/textView2"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_marginTop="@dimen/margTop"
        android:text="@string/pass"
        android:textAppearance="?android:attr/textAppearanceLarge" />
    <EditText
        android:id="@+id/txtPass"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:ems="10"
        android:inputType="textPassword" />
    <Button
        android:id="@+id/button1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_horizontal"
        android:layout_marginTop="@dimen/margTop"
        android:padding="@dimen/padGeneral"
        android:text="@string/send" />
    <TextView
        android:id="@+id/LblMensaje"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_horizontal"
        android:padding="20dip"
        android:textColor="#FF0000"
        android:textSize="20sp"
        android:textStyle="bold" />
</LinearLayout>

Bien, ahora dentro del java de la actividad principal, en el evento onCreate, asignamos un listener al botón para enviar el formulario, quedaría así:

Button boton = (Button) findViewById(R.id.button1);
boton.setOnClickListener(new OnClickListener() {
	@Override
	public void onClick(View arg0) {
		//Instanciamos y ejecutamos el proceso Asnyctask
		new usersJson().execute();
	}
});

Una vez presionado el botón, se ejecuta un segundo hilo que se encargará de hacer una petición http a un json alojado en un servidor externo, para ello usaremos Asynctask, ya he hablado de ello en mi anterior post, en él usaremo la clase Gson, pero antes deberemos descargárla, e instalarla en nuestra carpeta libs del proyecto (luego, en eclipse, refrescamos, 2º botón en el jar, build path->add to build path).

La clase Asynctask debe tener 3 parámetros, pero sólo necesitaremos el tercero, para saber si el login es correcto o incorrecto.

class usersJson extends AsyncTask<Void, Void, Boolean>

El método que ejecutará casi todo será el doInBackground y quedaría algo como así:

@Override
protected Boolean doInBackground(Void... arg0) {
	try {
		EditText userEdit = (EditText) findViewById(R.id.txtUsuario);
		EditText passEdit = (EditText) findViewById(R.id.txtPass);
		 /*
		* Creamos el objeto Gson al que le pasamos una URL
		*/
		Gson miGson = new Gson();
		URL url = new URL("http://internetria.com/prueba.json");
		BufferedReader reader = new BufferedReader(
				new InputStreamReader(url.openStream(),
						Charset.forName("UTF-8")));

		//Pasamos la info del json a un objeto para consultarlo
		Usuarios data = miGson.fromJson(reader, Usuarios.class);
		List<Usuario> users = data.getUsers();

		for (int i = 0; i < users.size(); i++) {

			if (userEdit.getText().toString()
					.equals(users.get(i).getName().toString())
					&& passEdit.getText().toString()
							.equals(users.get(i).getPass().toString())) {
				return true;
			} else
				return false;
		}

	} catch (Exception e) {
		Log.i("valores", "Error al leer el json de internetria");
		e.printStackTrace();
	}

	return false;
}

Al comienzo del método, cogemos los valores de los EditText para comparárlos posteriormente, luego instanciamos las clases necesarias para la conexión, como Gson, al que le pasaremos un objeto BufferedReader que tenga una URL con la dirección del jSon.

Posteriormente volcaremos el contenido a una clase previamente creada de usuarios, y necesitaremos otra para cada elemento. Recorremos los usuarios y comprobamos si existe

public class Usuarios {
	private List<Usuario> users;

	public List<Usuario> getUsers() {
		return users;
	}

	public void setUsers(List<Usuario> users) {
		this.users = users;
	}
}
public class Usuario {
	private String name;
	private String email;
	private String pass;
	private List<Usuarios> friends;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getEmail() {
		return email;
	}

	public void setEmail(String email) {
		this.email = email;
	}

	public List<Usuarios> getFriends() {
		return friends;
	}

	public void setFriends(List<Usuarios> friends) {
		this.friends = friends;
	}

	public String getPass() {
		return pass;
	}

	public void setPass(String pass) {
		this.pass = pass;
	}
}

Al final de doInBackground, si el usuario existe devolvemos true o false en caso contrario, ese booleano va directo al método onPostExecute, en el que si es true lanzamos un intent a una actividad con un ‘Bienvenido!’, por el contrario si es false, se imprimirá en la pantalla de login un ‘login incorrecto’, el método quedaría así:

protected void onPostExecute(Boolean result) {

	if (result) {
		pasar = new Intent(getApplicationContext(), Pagina_admin.class);
		startActivity(pasar);
	} else {
		InputMethodManager imm = (InputMethodManager) getSystemService(Activity.INPUT_METHOD_SERVICE);
		imm.toggleSoftInput(InputMethodManager.HIDE_IMPLICIT_ONLY, 0);
		TextView error = (TextView) findViewById(R.id.textError);
		error.setText("Login incorrecto");
	}
}

El objeto InputMethodManager lo usaremos para ocultar el teclado.

No se nos debe olvidar crear la  actividad a la que irá el login correcto y tocar el android_manifest para incluir permisos de internet y añadir las actividades.

Puedes DESCARGAR El CÓDIGO

¿Cuál es el origen de las bases de datos NoSQL?

Lo primero, decir que aunque el término NoSql surgió hace pocos años el concepto de bases de datos no relacionales es muy antiguo pues existía antes de que surgieran las bases de datos relacionales, las cuales se llevan usando desde hace mucho tiempo.

El lenguaje SQL tan utilizado se puede usar con diferentes motores de bases de datos y sus transacciones cumplen las propiedades del acrónimo ACID para ser confiables:

Atomicity - Atomicidad => una transacción se ejecuta completa o no se ejecuta.
Consistency - Consistencia => sólo se guardan datos válidos.
Isolation - Aislamiento => las transacciones no se afectan entre sí.
Durability - Durabilidad => una vez realizado un cambio éste perdura en el tiempo.

Pero cuando se tienen millones de transacciones contra una base de datos, como es el caso de aplicaciones como Facebook o Twitter, se presenta un problema de escalabilidad.

Hay dos tipos de escalabilidad:

- Escalabilidad vertical => ampliación de las capacidades del servidor (memoria, procesamiento, discos). La escalabilidad vertical es limitada, se puede dar el caso de tener un problema tan grande que por mucho que  se mejore el servidor no sea suficiente.

- Escalabilidad horizontal => ampliación del número de nodos. En lugar de 1 máquina se tienen varias, esto es, un sistema distribuido.

Dado el auge en el que actualmente se encuentra la informática en la Nube surge la necesidad de bases de datos altamente escalables, por lo que se tiene que optar por sistemas distribuidos. Y puesto que las bases de datos relacionales son complicadas de escalar horizontalmente, se pasa a usar en estos casos bases de datos NoSQL.

Un poco de teoría para entender esto mejor:

Según el Teorema de Brewer (CAP) en un sistema de datos distribuidos se pueden garantizar sólo 2 de estas propiedades a la vez:

Consistency – Consistencia => todos los nodos ven los mismos datos al mismo tiempo.
Avalability – Disponibilidad => todas las peticiones reciben una respuesta.
Partition tolerante  – Tolerancia a la partición => a menos que todos los nodos fallen el sistema puede seguir funcionando.

Como se refleja en la imagen, las bases de datos relacionales cumplen las 2 primeras propiedades del teorema de Brewer, consistencia y disponibilidad, pero generalmente no son tolerantes a la partición. Sin embargo las bases de datos NoSQL sí son tolerantes a la partición, pero hay algunas que no son consistentes y otras que no cumplen las propiedad de disponibilidad.

Por lo que se deduce que la alta escalabilidad buscada se obtiene a expensas de otras funcionalidades. De hecho a partir de este teorema surge el acrónimo BASE, como opuesto del ya explicado ACID (analogía a la relación entre los ácidos/bases en química), para describir las propiedades de ciertas bases de datos, como son las NoSQL, donde prima la disponibilidad frente a la consistencia.

Basically Available
Soft state
Eventually consistent

Ésto describe sistemas básicamente disponibles que utilizan transacciones que se conforman con que eventualmente nos encontremos en un estado consistente y con ofrecernos respuestas aproximadas.

¿Cuáles son sus características principales?

Ausencia de esquema

Las bases de datos NoSQL no imponen una estructura de datos en forma de tablas y relaciones entre ellas, sino que es más flexible y permite usar otros formatos como clave-valor, Mapeo de Columnas, Documentos o Grafos, donde la definición de los atributos no es fija, es decir, la estructura de lo equivalente a lo que conocemos como registros (filas de las tablas) no tiene por qué ser la misma para todos los elementos, pudiendo así almacenar sólo los atributos que interesen en cada uno de ellos, facilitando el polimorfismo de datos bajo una misma colección de información.

Velocidad

Además de la carencia de un esquema predeterminado, la principal característica de las bases de datos NoSQL es que están pensadas para manipular enormes cantidades de información de manera muy rápida. Para ello suelen almacenar toda la información que pueden en memoria (utilizando el disco como una mera herramienta de persistencia).

Escalabilidad horizontal sencilla

Como ya hemos comentado, estas bases de datos tienen una fácil escalabilidad horizontal. Permiten aumentar el rendimiento del sistema simplemente añadiendo más nodos, sin necesidad en muchos casos de realizar ninguna otra operación más que indicar al sistema cuáles son los nodos disponibles. Muchos sistemas NoSQL permiten utilizar consultas del tipo Map-Reduce, las cuales pueden ejecutarse en todos los nodos a la vez (cada uno operando sobre una porción de los datos) y reunir luego los resultados antes de devolverlos al cliente. La gran mayoría permiten también indicar otras cosas como el número de réplicas en que se hará una operación de escritura, para garantizar la disponibilidad. Y gracias al sharding y a no tener que replicar todos los datos en cada uno de los nodos, la información que se mueve entre las distintas instancias del motor de base de datos no tiene por qué ser demasiado intensiva.

Existen diferentes bases de datos NoSQL, cuyas características y formatos de almacenamiento varían, haciendo que el modelado para cada una de ellas tenga que ser distinto. A la hora de elegir un sistema NoSQL frente a uno SQL habrá que plantearse previamente si realmente se necesita, después elegir uno en concreto en base a nuestras necesidades, olvidarnos de las formas normales y guardar los datos de distinta manera en función de cómo va a ser el acceso a éstos.

Podemos concluir que los sistemas NoSQL no remplazan a las bases de datos SQL que llevamos usando desde hace años, sino que son un complemento para casos particulares, de forma que su existencia nos permite no usar sólo las ya conocidas SQL.

Además de acompañar al banco en la gestión de sus redes sociales, dimos cobertura al que se considera uno de los eventos deportivos más importantes del año en la ciudad, así como uno de los acontecimientos sociales de mayor resonancia. Nuestro equipo entrevistó a personajes como Vicente del Bosque, Juan Mónaco, Tomas Berdych, Tommy Robredo o Toni Nadal.

Por otra parte, la presencia del banco en las instalaciones del Barcelona Open se potenció un año más,  gracias a las Social Media Walls, que mostraban gran parte de la conversación en redes sociales en torno al torneo de tenis. De esta forma, Banc Sabadell consigue capitalizar la actividad del torneo en twitter, facebook, youtube y flickr.

Pinterst sirve para compartir imágenes de tal manera que todos los usuarios se conecten a través de cosas que les resulten interesantes. Se pueden crear tableros temáticos con todo lo que quiera el usuario. Se suben imágenes o pines, se clasifican en los diferentes “pinboards” o tableros y se puede seguir a otros usuarios con los mismos gustos e intereses.

Pinterest = Pin + Interest
Enganchar tus intereses

El usuario crea su cuenta, sus tableros y sube sus imágenes, de tal forma que otros usuarios pueden repinear sus pins, es decir, pueden publicar dicha imagen en su propio tablero. Pinterest ha demostrado con creces su valor como red social no tanto para relacionar amigos ni seguidores sino para relacionar intereses. Se trata de descubrir y no tanto de buscar. Se ha demostrado que tiene un gran éxito entre el público femenino.

Además de su fácil manejo es importante destacar su función como un escaparate visual para las empresas. Todas aquellas marcas que quieran potenciar sus productos no sólo a través de sus web sino también de las redes sociales, Pinterest puede ser el lugar ideal para mostrar de una manera rápida y muy visual todo su potencial. Así lo hemos hecho desde Internetría con uno de nuestros clientes, Arabel Lebrusan. Para esta firma de joyas, Pinterest es la red social perfecta para mostrar sus diseños y que los usuarios puedan compartirlos y darles mayor alcance.

Damos 5 claves por las que cualquier opinión en internet debería ser relativizada:

- Para empezar, la implantación de internet no representa ni en España ni en ningún país a la totalidad de la población. Se calcula que en torno al 70% de los hogares españoles tienen acceso a internet. Una gran cifra, sí, pero que ningún demógrafo interpretaría como el total.

- Si bien podríamos dividir las opiniones en positivas, negativas o neutras; está claro que en internet se necesita un motivo de peso para expresar tu opinión. Y por la propia naturaleza de las redes sociales que a menudo se acercan a la clásica atención al cliente, es más probable que un usuario exprese un gran enfado que una alegría. De hecho existe un nuevo tipo de ciberbulling que consiste en amenazar a los establecimientos con publicar opiniones negativos en webs como TripAdvisor a cambio de un trato preferente. (Lee artículo relacionado)

- Además, internet sigue siendo anónimo, lo que produce una dósis de valentía similar al anonimato de un graffitti, o de ese cartel pegado en el portal de la comunidad de vecinos con el objetivo de poner colorada a la vecina del sexto.  Y aunque en internet firmemos con nuestro propio nombre y foto, contamos con la deshinibición que nos aporta el no dar la cara personalmente.

- Algunas redes sociales suponen en sí mismas un medio de comunicación. Según un estudio de HBS sobre Twitter analizaba la actividad de 300.000 usuarios de Twitter y destacaba que el 75% de los usuarios habían realizado menos de cuatro tweets en su vida. Es decir, que un número muy reducido de usuarios son los que capitalizan el contenido que se genera y del que los demás se hacen eco.

- La opinión de los usuarios en redes sociales está muy influenciada por sus propias cualidades. Si la radiografía del usuario responde a unos parámetros concretos de edad, sexo e intereses, está claro que cualquier tendencia que refleje esa plataforma será la de esos mismos usuarios.  O dicho de otra forma; cada vez que un término es Trending Topic, ¿cómo medimos el impacto de esa misma tendencia entre los No-Twitteros? Sin ir más lejos, algunos estudios mantienen que la opinión en Twitter es  más “liberal” que la opinión pública, posíblemente a raíz de la naturaleza crítica y reivindicativa de los usuarios.

Vamos a desarrollar una app fácil, sencilla y para toda la familia en la que usaremos diversas tecnologías y funciones específicas de Android, así como librerías externas.

Necesitaremos una librería de Apache (descargar) que incluye API’s y métodos para intercambiar información mediante el protocolo http, así como enviar datos y ficheros como un formulario Html común para recogerlo en un servidor, en nuestro caso PHP.

Vayamos al grano, primero crearemos un proyecto Android, en este caso adaptado a una versión mínima de Android-8 y máxima 17. Una vez creado el proyecto crearemos una carpeta llamada “libs” en la que extraemos el Jar “httpmime-4.2.4.jar” ubicado en la carpeta libs del zip descargado anteriormente. Para agregarlo al proyecto en las propiedades del proyecto->Librerias->Añadir Jar, desplegamos nuestro proyecto y la carpeta libs, ahí encontraremos nuestro deseado Jar.

Antes de empezar con el código es aconsejable configurar en Android-manifest.xml y añadirle permisos de internet, puede darnos muchos dolores de cabeza más adelante a la hora de depurar.

<uses-permission android:name="android.permission.INTERNET"/>

La pantalla principal constará de un botón que ejecute la cámara y una imagen que será la foto que realicemos. El xml del layout quedaría así

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    tools:context=".MainActivity" >

    <TextView
        android:id="@+id/textView1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentTop="true"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="20dp"
        android:text="@string/hello_world" />

    <Button
        android:id="@+id/button1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_below="@+id/textView1"
        android:layout_centerHorizontal="true"
        android:layout_marginTop="21dp"
        android:text="Camara" />

    <ImageView
        android:id="@+id/imageView1"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_centerHorizontal="true"
        android:layout_centerVertical="true"
        />

</RelativeLayout>

Bueno pues ya tenemos la vista de la aplicación, ahora démoslo funcionalidad. Vayamos a MainActivity o java inicial de la aplicación.

El flujo de la app sería el siguiente:

• Clicamos el botón y lanzamos un intent para ejecutar la cámara
• Realizamos una foto y posteriormente la guardamos mediante la clase MediaScannerConnectionClient, la mostramos en la imageView del layout
• Lanzamos un proceso en segundo plano para subir la foto mientras que mostramos un dialog de carga
• Una vez terminada la subida al servidor, mostramos un alert “Foto subida”

En el método onCreate de la clase principal creamos la ruta y nombre donde guardaremos la foto

aleatorio = new Double(Math.random() * 100).intValue();
foto = Environment.getExternalStorageDirectory() + "/imagen"+ aleatorio +".jpg";

Le damos vida al botón creando una variable de tipo Button y la vincularemos al botón creado en el layout, posteriormente le creamos el evento onClick()

btnCamara = (Button) findViewById(R.id.button1);
btnCamara.setOnClickListener(new OnClickListener() {
	@Override
	public void onClick(View v) {
		Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
		Uri output = Uri.fromFile(new File(foto));
		intent.putExtra(MediaStore.EXTRA_OUTPUT, output);
		startActivityForResult(intent, TAKE_PICTURE);
	}
});

Analicemos el contenido del onClick(). Crearemos un Intent para acceder a la cámara y una dirección donde guardaremos la foto en caso de realizarse, con el putExtra le asignamos la salida a la dirección dada. Lanzamos el intent, TAKE_PICTURE es una constante que he definido con el valor de ’1′, de esta manera lanzamos la intención de tomar una foto, con un 2 tendríamos la intención de recoger la foto de una biblioteca. El startActivity lo hemos cambiado por startActivityForResult porque lanzaremos el intent para que vuelva con resultados, en este caso una imagen.

Ahora declaramos el onActivityResult para obtener el resultado de la camara y gestionar el uso como queramos, veamos el código

@Override
	protected void onActivityResult(int requestCode, int resultCode, Intent data) {

		ImageView iv = (ImageView) findViewById(R.id.imageView1);
		iv.setImageBitmap(BitmapFactory.decodeFile(foto));

		File file = new File(foto);
		if (file.exists()) {
			UploaderFoto nuevaTarea = new UploaderFoto();
			nuevaTarea.execute(foto);
		}
		else
			Toast.makeText(getApplicationContext(), "No se ha realizado la foto", Toast.LENGTH_SHORT).show();

	}

Como vemos, instanciamos un objeto de imagen para asignarle la foto que realicemos con la cámara mediante el método setImageBitmap al que le tenemos que pasar una imagen codificada en mapa de bits, usaremos para esto BitmapFactory.decodeFile(rutaFoto);

Posteriormente creamos un objeto de tipo foto para saber si se ha guardado y existe esa foto, haremos unas cosas u otras en función de esa sentencia. En el caso de no haber foto (porque el usuario ha dado en el botón ‘atrás’) lanzamos un mensaje de que no se ha realizado la foto, por el contrario, si se ha realizado, procederemos a subir la imagen a un servidor que nos está esperando.

Para este procedimiento he recurrido a los procesos, ejecutaremos en segundo plano la subida del fichero mientras decimos al usuario que espere un momento.

Decidí usar la clase AsyncTask en vez de los threads y handlers porque me parece mucho más organizado y claro, pero cada uno que use lo que más acostumbrado esté. La clase AsyncTask de Android precisa de 3 parámetros

class UploaderFoto extends AsyncTask{...}

• Params:  Datos que pasaremos al comenzar la tarea
• Progress: Parámetros que necesitaremos para actualizar la UI.
• Result: Dato que devolveremos una vez terminada la tarea.

Además es necesario implementar el método doInBackground, y opcionalmente los métodos onPreExecute y onPostExecute, su ejecución es obvia

Veamos como nos quedaría la clase y la analizamos:

class UploaderFoto extends AsyncTask{

		ProgressDialog pDialog;
		String miFoto = "";

		@Override
		protected Void doInBackground(String... params) {
			miFoto = params[0];
			try {
				HttpClient httpclient = new DefaultHttpClient();
				httpclient.getParams().setParameter(CoreProtocolPNames.PROTOCOL_VERSION, HttpVersion.HTTP_1_1);
				HttpPost httppost = new HttpPost("http://tuservidor.com/upload.php");
				File file = new File(miFoto);
				MultipartEntity mpEntity = new MultipartEntity();
				ContentBody foto = new FileBody(file, "image/jpeg");
				mpEntity.addPart("fotoUp", foto);
				httppost.setEntity(mpEntity);
				httpclient.execute(httppost);
				httpclient.getConnectionManager().shutdown();
			} catch (Exception e) {
				e.printStackTrace();
			}
			return null;
		}

		protected void onPreExecute() {
			super.onPreExecute();
			pDialog = new ProgressDialog(MainActivity.this);
	        pDialog.setMessage("Subiendo la imagen, espere." );
	        pDialog.setProgressStyle(ProgressDialog.STYLE_SPINNER);
	        pDialog.setCancelable(true);
	        pDialog.show();
		}
		protected void onPostExecute(Void result) {
			super.onPostExecute(result);
			pDialog.dismiss();
		}
}

Que no cunda el pánico, vayamos por partes, usaremos 2 constantes una de tipo Dialog para el dialogo de progreso de subida de la foto y otra que guarda la ruta absoluta de la foto. La clase no devuelve nada pero sí recibe parámetros de String, solamente le recibirá la ruta absoluta de la foto que llegará recien horneada del método execute de una instancia de esta clase.

El método doInBackground hace casi todo, con HttpClient tenemos una clase para realizar comunicaciones HTTP, con HttpPost, podemos enviar información de tipo POST y con MultipartEntity, podemos enviar información y archivos. Básicamente el flujo de este apartado es, creo un cliente de comunicación en el que enviaré información por post a una URL y encapsularé datos y ficheros para ser enviados desde ese cliente. Todo esto debe estar dentro de una transacción try-catch.

Pero antes de que se ejecute doInBackground, se ejecuta onPreExecute y despues de doInBackground se ejecuta onPostExecute. Es muy importante saber este flujo al igual que con el método doInBackground NO podemos tocar la interfaz de usuario (UI principal), pero sí con el resto de eventos, por lo tanto en el onPreExecute lanzamos el dialog y con el onPostExecute lo quitamos.

En el servidor PHP recojemos la imagén de la siguiente manera

$ruta = "fotos/" . basename( $_FILES['fotoUp']['name']);
if(move_uploaded_file($_FILES['fotoUp']['tmp_name'], $ruta))
       chmod ("uploads/".basename( $_FILES['fotoUp']['name']), 0644);

Ahora a probar suerte y depurar.

El código completo:

public class MainActivity extends Activity {

	Button btnCamara;
	private String foto;
	private static int TAKE_PICTURE = 1;
	double aleatorio = 0;

	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		setContentView(R.layout.activity_main);

		//Para crear un nombre diferente para la foto
		aleatorio = new Double(Math.random() * 100).intValue();
		foto = Environment.getExternalStorageDirectory() + "/imagen"+ aleatorio +".jpg";

		btnCamara = (Button) findViewById(R.id.button1);
		btnCamara.setOnClickListener(new OnClickListener() {

			@Override
			public void onClick(View v) {
				Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
				Uri output = Uri.fromFile(new File(foto));
				intent.putExtra(MediaStore.EXTRA_OUTPUT, output);
				startActivityForResult(intent, TAKE_PICTURE); // 1 para la camara, 2 para la galeria
			}
		});
	}

	@Override
	protected void onActivityResult(int requestCode, int resultCode, Intent data) {

		ImageView iv = (ImageView) findViewById(R.id.imageView1);
		iv.setImageBitmap(BitmapFactory.decodeFile(foto));

		File file = new File(foto);
		if (file.exists()) {
			UploaderFoto nuevaTarea = new UploaderFoto();
			nuevaTarea.execute(foto);
		}
		else
			Toast.makeText(getApplicationContext(), "No se ha realizado la foto", Toast.LENGTH_SHORT).show();

	}

	class UploaderFoto extends AsyncTask{

		ProgressDialog pDialog;
		String miFoto = "";

		@Override
		protected Void doInBackground(String... params) {
			miFoto = params[0];
			try {
				HttpClient httpclient = new DefaultHttpClient();
				httpclient.getParams().setParameter(CoreProtocolPNames.PROTOCOL_VERSION, HttpVersion.HTTP_1_1);
				HttpPost httppost = new HttpPost("http://servidor.com/up.php");
				File file = new File(miFoto);
				MultipartEntity mpEntity = new MultipartEntity();
				ContentBody foto = new FileBody(file, "image/jpeg");
				mpEntity.addPart("fotoUp", foto);
				httppost.setEntity(mpEntity);
				httpclient.execute(httppost);
				httpclient.getConnectionManager().shutdown();
			} catch (Exception e) {
				e.printStackTrace();
			}
			return null;
		}

		protected void onPreExecute() {
			super.onPreExecute();
			pDialog = new ProgressDialog(MainActivity.this);
	        pDialog.setMessage("Subiendo la imagen, espere." );
	        pDialog.setProgressStyle(ProgressDialog.STYLE_SPINNER);
	        pDialog.setCancelable(true);
	        pDialog.show();
		}
		protected void onPostExecute(Void result) {
			super.onPostExecute(result);
			pDialog.dismiss();
		}
	}

	@Override
	public boolean onCreateOptionsMenu(Menu menu) {
		getMenuInflater().inflate(R.menu.main, menu);
		return true;
	}

}

Vamos a introducir algunos conceptos fundamentales para entender la lógica y comportamiento de este componente.

La Table View presenta datos en una tabla de una sola columna y varias filas, en realidad es más una lista que una tabla. Se muestra un elemento por fila (row).

Es una instancia de la clase UITableView y puede ser de 2 tipos:
- Plain: todos los elementos se disponen en la lista de manera seguida
- Grouped: los elementos se dividen en diferentes secciones

En la siguiente imagen  se pueden ver los 2 tipos de estilo que puede tener, el primero es “plain” y el segundo “grouped”.

La vista de cada elemento dentro de la tabla consiste en una celda, “cell”, instancia de la clase UITableViewCell, que muestra los datos de una fila determinada en un  momento determinado. Una misma celda se puede reutilizar para mostrar información de otras filas.

En Objective-C se usa la herencia para dotar a las apps de un comportamiento específico. Esto consiste en crear una subclase de otra clase ya existente que también amplía o modifica los atributos y comportamiento de la superclase. También se usan otras técnicas basadas en patrones de diseño.

Antes de continuar hablando sobre la Table View vamos a introducir los 3 patrones de diseño más importantes en la programación iOs:

1.-  Modelo Vista Controlador (model view controller)

 Este patrón se abrevia como MVC e implica que todos los objetos de la aplicación se dividan en 3 grupos:

- Objetos del modelo: contienen los datos y las operaciones que se realizan con ellos.
- Objetos de la vista: constituyen la parte visual de la app (imágenes, botones, etc.)
- Objetos del controlador: conectan el modelo con las vistas.

2.-  Delegación (delegation)

La delegación, como su propio nombre indica, consiste en delegar en un objeto la capacidad de responder ante eventos ocurridos en otro objeto. El proceso de delegación se hace a través de la propiedad “delegate”. Se asigna a la propiedad “delegate” de un objeto la clase que se quiere que sea la encargada de manipular los eventos de ese objeto.

3.- Protocolo (protocol)

Un protocolo consiste en la declaración de un conjunto de métodos sin implementar. No podemos hacer instancias de ellos ni crear variables de instancia dentro de ellos. Sus métodos son implementados en las clases que “son conformes” a ese protocolo.

Los protocolos son lo equivalente a las interfaces en otros lenguajes de programación. Permiten la comunicación entre objetos no relacionados por herencia,  por lo que igual que la delegación son una alternativa a la utilización de subclases y son a menudo parte  de una implementación de delegación. Un protocolo delegado es aquel usado para la delegación.

Volviendo a la Table View, ésta debe tener asociado un controlador que siguiendo el MVC conecte los datos del modelo con la tabla. De hecho, en el Xcode (entorno de desarrollo integrado de Apple) podemos utilizar para la interfaz de usuario un objeto denominado Table View Controller que incluye el controlador (UITableViewController) y la vista (UITableView).

A la Table View no le importa quién es la fuente de los datos (data source) ni qué tipo de datos se están tratando.  Detecta cuándo se ha presionado una fila y pide un dato cuando lo necesita pero la responsabilidad de manejar los datos o lo que se hace en respuesta a los eventos asociados a la Table View no es suya sino de sus delegados.

Normalmente los componentes sólo tienen un delegado (delegate) pero la Table View delega sus deberes en 2 ayudantes diferentes:

UITableViewDataSource: se encarga de poner las filas, es decir, los datos, en la tabla.

UITableViewDelegate: maneja el evento de selección de filas además de otras tareas.

Normalmente el View Controller hace el papel de data source e implementa los siguientes  métodos:

- Método que se invoca cuando la Table View necesita saber cuántas filas de datos hay

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
   return 1;
}

- Método que se invoca cuando la Table View necesita mostrar los datos de una determinada fila. El objeto devuelto es de la clase UITableViewCell porque, como hemos dicho antes, los datos se visualizan en una celda (Cell)

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"ChecklistItem"];

   return cell;
}

En la siguiente imagen se representa la comunicación entre el View Controller como fuente de datos (data source) y la Table View.

Como hemos explicado antes la Table View también delega en el denominado Delegate, que se encarga de personalizar su apariencia y comportamiento.

El siguiente método delegado gestiona los toques en las filas de datos. Implementa qué se hace después (por eso el prefijo “did”) de seleccionar una fila.

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    [tableView deselectRowAtIndexPath:indexPath animated:YES];
}

El siguiente método también gestiona los toques en las filas de datos. Implementa qué se hace antes (por eso el prefijo “will”) de seleccionar una fila.

- (NSIndexPath *)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    return nil;
}

Para que quede más claro podemos decir que cuando el usuario selecciona una fila de la tabla ésta envía al delegate un mensaje “willSelectRowAtIndexPath” que dice “hola delegado, voy a seleccionar esta fila”, el método delegado al devolver “nil” está diciendo “lo siento pero no estás autorizado para hacerlo”.

La siguiente imagen intenta plasmar de manera visual un resumen de lo explicado.

Arabel es una joven diseñadora española afincada en Londres que ha viajado por todo el mundo descubriendo técnicas para trabajar la joyería. Su talento y su esfuerzo le han servido para hacerse un hueco en la moda y conseguir que la Princesa de Asturias o las hermanas Sienna y Savannah Miller luzcan algunas de sus joyas en diversos actos públicos.

Con motivo de la presentación en España de su nueva colección, se celebró un evento en Las Mascareñas, un acogedor espacio en el que la moda, el arte y la artesanía conviven a la perfección. La madrina de excepción fue la artista Chenoa que estaba radiante con las joyas de Arabel Lebrusan. La convocatoria fue todo un éxito, consiguiendo gran repercusión tanto en televisión como prensa y revistas digitales.

A partir de ahora se nos plantea el reto de afianzar la imagen de la firma en España, aumentando sus seguidores y su interacción en las redes sociales.

No hablan de lo mucho que saben de “reach”, de “KPI’s” o de “Los 10 errores de las empresas en redes sociales” sino que sencillamente nos divierten, o informan, y cada día ven crecer su comunidad con una viralidad que ya querría para sí cualquier marca.

Un buen ejemplo de ello es “Postureo” que con frescura e ironía parodian todas aquellas situaciones que hacemos “de cara a la galería”. Lo que empezó como una página de Facebook es hoy todo un fenómeno online. Cualquier estado publicado consigue a los pocos minutos miles de comentarios, han conseguido varios TT en twitter, e incluso han traspasado la frontera offline apareciendo en medios la revista GQ y sobre todo; en el vocabulario de muchas personas.

Hoy en Internetría sometemos a sus administradores a nuestro cuestionario:

I: ¿PC o Mac?
P: Pues depende a quien le preguntes o el uso que le quieras dar a tu ordenador. Ambos tienen cosas geniales y han evolucionado diferente el tiempo. ¿Puede que hay gente que se compre un Mac sólo por moda? Por supuesto,  es una marca que ha creado el concepto del ordenador como diseño no sólo como un armatoste de cables. Pero no hay que ser injusto con el PC, no te sabría decir.

I: ¿Cuál es vuestro homepage o la página que visitais a diario?
P: Tenemos miles de homepage y muy variadas. Pero aunque os parezca extraño las que más visitamos es la prensa nacional. ¿Qué poco chic no?

I: ¿Sin qué app no podéis vivir?
P: Hay una app para la que dentro de poco no podremos parar de vivir, es únicamente para iPad y es el magazine Unbreak. Se lanzará en abril y tiene una pinta increible.

I: Un personaje al que seguir en internet:
P: Podéis ver nuestros following, son gente de la radio, la televisión, la prensa o la música. Especialmente interesante nos parecen los tweets del cineasta Rodrigo Cortés siempre afilados e inteligentes. Pero si quereis carnaza, que imagino que sí, Carlos Valladolid, es el twitero mas irónico que conozco.

I: ¿Qué es lo último que comprasteis online?
P: La verdad que fue un regalo de la tienda Mr. Wonderful.

I: ¿Sois más de Facebook o más de Twitter?
P: Son redes diferentes para usos diferentes, el facebook es el postureo por antonomasia y el twitter es una página tremendamente viral de una información vibrante cada segundo. Somos muy de las dos.

I: ¿Os ha jugado alguna mala pasada internet?
P: No, no somos tan relevantes y si lo somos no nos damos cuenta. Nuestra página se basa fundamentalmente en el respeto. Detestábamos todas esas páginas anónimas en twitter que criticaban aquello cuanto veian de manera desproporcionada. Nosotros estamos ocultos, sí, pero no insultamos a nadie, ni usamos malas formas, ¿Qué necesidad hay de hacerlo? Si alguna vez nos hemos equivocado la gente entiende que no es una nuestra intención y nos respeta bastante.

I: ¿Quién hay detrás de @Postureo?¿Alguno os dedicáis al márketing o la comunicación? ¿Os ha surgido alguna oportunidad a raíz del éxito de vuestras cuentas en Twitter o Facebook…?
P: Detrás de @Postureo_ hay varias personas pero no vamos a desvelar nada, es mas divertido así. En realidad se pueden unir los puntos muy fácilmente.
Oportunidades nos han surgidos muchas,  muchísimas. La gente intenta pegarse a nosotros por nuestro éxito y lo entendemos. Nos han hecho muchas entrevistas, nos han nombrado en medios como en la Gala de los Oscar de Canal +, en la Ser, en los 40 principales, en revistas como la GQ, Vice, medios como MTV… es una lista tan larga que nos abruma.

I: Para la revista GQ definisteis en “postureo” como “una actitud con la que la gente juega a ser lo que no es o al menos a hacer cosas que esperan un reconocimiento”, entonces ¿el postureo está en todas los grupos sociales? ¿Cómo creéis que entiende el público mainstream los chistes sobre Miranda Makarof u otros personajes o elementos de determinadas subculturas?
P: El postureo por supuesto que está en todos los grupos sociales, yo pienso en todas esas madres a la salida del colegio esperando a recoger a sus niños y como se pavonean y presumen del último viaje que han hecho, o el coche que tiene su marido. Son tantos los ejemplos de postureo que podríamos pasarnos todo el día citandolos. De ahí el éxito de la página. El publico mainstream como vosotros decís en absoluto entiende chistes sobre Miranda o Gala Gonzalez, nosotros intentamos, sin dejarlo de lado, hablar de cosas más genéricas.

I: Que a los pocos segundos de publicar un estado, éste ya tenga miles de Me Gusta es algo que (por experiencia) solo hemos visto en estrellas internacionales como Rafa Nadal. Cuando a nosotros nos preguntan los clientes cómo se consigue un fenómeno viral en internet decimos que no hay una fórmula mágica, ¿Qué opináis? ¿Cuál es la clave del éxito de @Postureo_?
P: No existe una fórmula mágica. La clave del éxito es el respeto. Estamos convencido de ello. A la gente le gusta que nos riamos con ellos y no de ellos, con cosas que todos hacemos. Pequeñas idionsicrasias

I: El fenómeno de las “Señoras Que…” acabó en un programa de televisión, ¿Cuál es el futuro de @Postureo_? os pediríamos que por favor no acabéis poniendo links a “Cuánto Daño” u otro blog de chistes con gatitos.
P: Nunca nos convertiremos en una página así, podéis estar tranquilos, haremos las cosas mejor o peor, pero siempre vamos a mantener el mismo estilo que nos ha hecho alcanzar más de 120.000 seguidores. El futuro no lo sabemos pero hay postureo para rato.

I: ¡Muchas gracias por vuestro tiempo!
P: Muchas gracias a ti Ángel por reirte con nosotros y seguirnos. ¡Sé que fuiste unos de los primeros!