Mejor lenguaje para una RS?

MrBigel

¡Hola Gente!

Seré breve, quiero empezar a programar aplicaciones para android(más tarde iOS), lo que más me mola del ámbito de las apps son las RRSS. Así que quiero enfocarme a ellas.
Tengo conocimientos básicos de Java, medios de js y empezando en python.

Tengo idea 0 del flujo de trabajo en android.

Así que tenía unas dudas básicas que espero que podáis resolverme y lo agradecería mucho:

· ¿Cuál es el mejor lenguaje para programar en android enfocado a las RRSS?
· ¿Qué IDE creéis que es más cómodo para programar en este ámbito?

Con eso es suficiente.

Muchas gracias.

PD: Entiendo que en google puedo encontrar todo esto, pero se que por aquí hay bastante entendido y me gustaría saber su opinión personal.

cabron

Lo dices como si hubiese mucho donde elegir, el único lenguaje soportado oficialmente para programar en Android es Java, así que en principio Java es tu única opción independientemente de lo que quieras hacer.

Fuera de eso, tienes frameworks que básicamente te empaquetan un navegador dentro de una aplicación y te permiten programar en javascript, con la ventaja de que la aplicación te vale para ios y Android.

Y sobre el ide, el único soportado oficialmente es Android Studio. Android necesita de varias herramientas para desarrollar, si decides no tirar por Android Studio donde viene ya todo más o menos montado, probablemente pierdas un montón de tiempo intentando montar un entorno de desarrollo con otra cosa que no sea Android Studio.

1 1 respuesta
Amazon

Móntate una API de la RRSS en GraphQL, usando Django quizás. Luego hazte un proyectito en React Native que cuelgue de esa API, así no tiras sólo para Android.

Es lo último en RRSS según tengo entendido.

3
r2d2rigo

Yo creo que el mejor lenguaje es el ingles, porque es el que habla mas gente.

8
sonyer

Otra opción es Xamarin con Visual Studio y C#.

s4suk3

#2 no es el único
https://kotlinlang.org/

respecto a #1 android studio + java

La pregunta que da para hablar es el backend, en que lenguaje?
Mi opinión personal es que para novatos y grupos pequeños, hacer una red social de 0 es una locura, así que te ayudará un sass tipo firebase, que ya tienes bastante cómo para ponerte a gestionar servidores xDD

1 respuesta
Zerokkk
  1. Olvídate de las nativas, están muertas por mucho que algunos fanáticos se empeñen en defenderlas (link1, link2). Puedes usar JS en React Native o Ionic 2, o C# en Xamarin, y harás la app multiplataforma sin prácticamente perder rendimiento. Si aún por encima te montas una PWA, ya de putísima madre (es la mejor opción a día de hoy sin que haya mucho que discutir). Esto es facilico con Ionic ya que el código para web y para móvil es literalmente el mismo, con como único cambio, tirar de paquetes del JS SDK en lugar de paquetes nativos en caso de que los estés usando.

  2. El backend va a tu elección. Yo últimamente tiro mucho por Nodejs + Express + Parse Server para facilitar las cosas, pero perfectamente te lo puedes montar con Django (Python), JavaEE, Golang, PHP...

  3. Dado que las RRSS usan esquemas relacionales complicados, te recomiendo usar Parse Server o Firebase para gestionar pushes y las operaciones CRUD.

  4. Para la base de datos, yo creo que a día de hoy no hay demasiadas razones para no escoger una BBDD NoSQL como MongoDB, pero si te sientes cómodo con SQL, ya sabes que tienes montones de opciones donde elegir. Alguna gente incluso las mezcla.

  5. Para autenticación de users, OAuth 2.0 o similares, o incluso lo que ya viene built-in en Parse.

  6. Sobre IDEs: Visual Studio Code personalmente me gusta bastante.

Saludetis.

2 respuestas
B

Estan muertas dice haha

5 1 respuesta
cabron

#6

Java es el único, vuelvo a repetir: soportado oficialmente

En todo caso si quisieras decir otro sería C++ ya que hay un SDK nativo, pero ese es otro tema.

1
Zerokkk

#8 Entiéndase el "están muertas" por "nadie con dos dedos de frente va a contratar un equipo a día de hoy para un proyecto nuevo en Android/Swift, y que esto dibujará una tendencia a la baja según crece la demanda de RN/Ionic2/X".

1 respuesta
r2d2rigo

#7

Apps nativas muertas, la fuente para corroborar son 2 posts de Medium
RRSS usa esquema relacional "complicado", recomienda NoSQL

Lastima que en este foro no haya funcion de ignore porque tus contribuciones son para enmarcar.

3 1 respuesta
B

#10 cualquier empresa con dinero tira de nativo. Yo no se en que mundo laboral vivis, alomejor soy yo que me he acostumbrado a empresas donde solo se desarrolla en nativo y no tengo ni idea de lo que sucede fuera de grandes empresas

5 3 respuestas
s4suk3

#7 la verdad es que te has lucido, con el primer punto ya no me leo más, pero bueno, que lo normal es utilizar nativo y algunas partes webview
#12 igualmente, en mi empresa sólo nativo, alguna vez probamos con angular 1 + ionic y nunca mais

1 respuesta
Zerokkk

#11

#11r2d2rigo:

Lastima que en este foro no haya funcion de ignore porque tus contribuciones son para enmarcar.

Y a mí me hacen mucha gracia las tuyas, que parecen de alguien que se quedó estancado en desarrollos de hace años y no está al tanto de las nuevas opciones saludables para el mercado que van saliendo.

Ya directamente, el suponer que la relación entre los datasets debe ir del lado de la BBDD, me parece un approach tan 2000's que en fin xd. A día de hoy con una NoSQL tienes un montón de soluciones para relacionar los datos de formas más eficientes que tirando de una SQL.

#13 #12 Os respondo exactamente lo mismo que a #11. Que no os culpo, una cosa es lo que "se hace" y otra muy diferente "lo que se puede hacer". Quien busca eficiencia tanto a nivel de perfomance como en costes, NO hace apps nativas a día de hoy. Y sí, las empresas grandes también empiezan a seguir la tendencia.

Otra cosa es su viabilidad sea algo relativamente nuevo y todavía no haya generado un gran impacto en el mercado.

1 2 respuestas
r2d2rigo

#12 ahora mismo estoy currando en una app para una empresa de sanidad privada tocha y adivina a quien le toca migrar de webapp movil a Xamarin porque lo que hay ahora no va ni pa dios a nivel de rendimiento ni en un iPhone 7.

#14 lee el parrafo de arriba, mi impresion es que tienes 0 experiencia en el mundo laboral serio y te riges por el ultimo cool framework que puedes programar desde tu Macbook en un Starbucks. Ya van 3 proyectos que tengo que migrar de Ionic/mobile webapp a nativo porque el cool kid de turno quiso hacerlo todo guay y a la hora de shippear el resultado no era ni 1/10 de nativo.

1 1 respuesta
varuk

Una pregunta, las aplicaciones NO-nativas ¿se permiten subir al Google Play y a la Apple Store?

2 respuestas
B

#14 por dios xD. Eficiencia, empresas grandes siguiendo tendencia, relativamente nuevo. Tus posts son para enmarcar haha

1 respuesta
Zerokkk

#15 Te equivocas y patinas de nuevo. Claro que he hecho cosas y claro que he podido crear productos con buen rendimiento, y sí que he trabajado tanto con nativo como con híbrido.

La cosa es, en el ejemplo que has puesto, ¿qué versión de Ionic usábais? ¿En qué consistía la app? ¿Bajo qué móvil ha corrido? ¿Usábais Crosswalk? ¿Estaba activado el modo de producción? En caso de ser ionic 2, ¿habéis optimizado la carga de módulos? ¿Usado webworkers?

No es tan sencillo xd.

#16 Claro.

#17 Si al menos argumentases un poco, se podría tener un debate interesante, pero sigo leyendo cosas de gente que no ha hecho más que toquetear estas nuevas herramientas sin meterse siquiera a entenderlas.

Es muy sencillo, ¿crees que una empresa, pudiendo destinar 1/3 parte del dinero perdiendo a lo sumo un 10% de rendimiento a lo sumo, iba a hacer otra cosa?

2 respuestas
cabron

#16

No existen aplicaciones 'no-nativas', todas son aplicaciones 'nativas' de una forma u otra.

Lo que cambia es que en las 'no-nativas' utilizas una capa que se ha inventado alguien que pasa por un compilador/generador lo que sea, y al final el resultado es una aplicación nativa.

Por ejemplo cordova, ionic y todo eso, al final lo que hacen es que generan una aplicación nativa que tiene una ui con un navegador metido (un webview) y tu 'aplicación no-nativa' es código que se ejecuta dentro de ese navegador.

1 2 respuestas
Zerokkk

#19 En el caso de React Native, el rendimiento es exactamente el mismo porque llama a componentes nativos y no requiere de webview, pero sí, es eso.

Añadiría que en caso de móviles viejos con webviews desastrosos, la opción buena es usar Crosswalk, que básicamente es un webview on steroids que ayuda a que las híbridas basadas en cordova tiren bien en móviles viejunos.

1 respuesta
B

#18 nosotros llevamos años produciendo aplicaciones ide uso interno chorra(enter time, mail, conferencias internas...) con ionic. A ningun tech fellow o mobile architect con 2 dedos de frente se le ocurriria tirar de algo que no sea nativo para nuestros consumers para uso externo. Suficiente odio hay del rendimiento que tienen nuestras aplicaciones internas.

No hay punto de comparacion, a no ser que hables de productos sencillos con complejidad 0.

1 1 respuesta
varuk

#19 Gracias por la explicacíón

r2d2rigo

#18 ¯_(ツ)_/¯ solo se que el presupuesto anterior fueron 2M y eso da para MUCHO. Ahora toca rehacerla en nativo con 250k, asi que no me vengas con los costes.

#20 por mucho que te empeñes el rendimiento de React no es el mismo, los components son nativos pero la logica sigue siendo JS interpretado. Como tu app sea pesada en logica estas tirando recursos.

1 respuesta
Zerokkk

#21 En ionic 1 me imagino, porque el 2 tiene un rendimiento que te cagas sin que tampoco te mates demasiado, ¿eh?

No sé si le habréis echado un ojo. Cabe destacar que hay que tener un poco de kilometraje con Angular 2 para no cargarte buena parte del rendimiento, pero la diferencia con una nativa es de risa. Ya si te pasas a RN ni te cuento.

#23 Tener una app pesada en lógica no implica que interpretar el código te vaya a costar la vida. A ningún móvil actual le va a costar interpretar una cantidad de código no extremadamente grande, a menos que diseñes como el culo y metas una vista con tropecientos components cada uno con 100 líneas de código xD.

Hay que tener en cuenta el panorama tecnológico actual para estas cosas. A menos que estés desarrollando algo que tire una animalada de recursos (véase un juego o un programa de cálculo avanzado), ¿qué problemática real estás produciendo? Ninguna. Y ojo, te estás ahorrando otra cantidad importante de tiempo que te llevaría producir la app para otra plataforma.

2 respuestas
B

#24 solo ahorras tiempo si no tienes recursos o dinero. Que muchisimas empresas tienen equipos de iOS y equipos de Android, y no es solo 2 equipos por empresa precisamente. Si pudiera te pasaba solo el codigo de uno de los frameworks desarrollados por nuestra empresa que su utilizan en nuestra app para iOS. Basandome en tus posts te puedo garantizar que no has trabajado en una aplicacion grande.

Creo que te basas en un panorama donde tienes una empresa con un par de devs que se tienen que buscar la vida, y ahi no te culpo, des de luego que tiraria de react native.

1 respuesta
Zerokkk

#25 Es que estás usando un argumento cíclico como una casa xD.

Claro que sé que hay empresas que tienen recursos de la ostia, y en seguida encargan el mismo proyecto a los de Android, iOS, y WP (en caso de haberlo). Sucede que esto es un gasto de pasta que flipas, además de que generalmente, es más lento hacer algo en Android/Swift, que hacerlo en JS sobre React o Angular 2, que quieras que no, son frameworks de desarrollo muy rápido.

La misma empresa podría, con sólo uno de los equipos, ahorrarse el coste de los otros, y centrarse en esa codebase.

Además de que una app de estas puede colgarse en una web y ser una PWA, como están haciendo cada vez más empresas.

Quieras que no, son todo ventajas, a cambio de... ¿qué, una pérdida mínima de rendimiento? Para el empresario, la pasta que tiene que soltar es significativamente menor, mientras que la calidad del producto permanece casi intacta.

Claramente, no veremos a grandes corporaciones pasarse a las hybrid hasta que cambien mucho las cosas, pero el cambio ya ha comenzado, y con el tiempo, desaparecerá esa tendencia de tener un equipo de desarrollo para cada plataforma, y pasarán a tener uno único de desarrollo móvil híbrido. En términos de costes, la diferencia es abrumadora.

aerotoad

Menudo lío habéis montado aquí.
#1 solo había preguntado por donde empezar, no empezar la tercera guerra mundial.

A ver, creo que lo de adoptar posturas irreconciliables no es la solución y mucho menos en un mundo como el nuestro en que precisamente nos dedicamos a solucionar problemas.

¿Todas las aplicaciones son nativas?
Si y no.
Comparten la base sobre la que funcionan, en el caso de las escritas en cordova, estas poseen una capa de abstracción escrita en el lenguaje nativo de cada plataforma para la que son compiladas, mientras que la lógica e interfaz de la app corre sobre un navegador, que normalmente no va incluído en el paquete de la app, si no que se tira del propio navegador del sistema operativo, con sus pros y sus contras.

Por el otro lado tenemos las totalmente nativas, cuya lógica e interfaz está escrita por completo en el lenguaje soportado por su plataforma y el código no es reutilizable en el caso de querer portarla a otra.

Dicho esto ¿Qué usar?. Como buen gallego respondo: Depende

Las aplicaciones híbridas han mejorado exponencialmente en los últimos años y su progreso se acelera, no obstante, sigue habiendo ligeras diferencias de rendimiento con respecto a las aplicaciones totalmente nativas.

La decisión sobre que usar y que no recae en si estás dispuesto a sacrificar una porción de tu rendimiento a cambio de tener un código que funciona en cualquier cacharro con un navegador web (Por el amor de dios, se podrían hacer funcionar las apps ionic hasta en las nuevas neveras de Samsung).

En caso de que el rendimiento sea un factor clave, necesario para tu app y no sacrificable, tira por el desarrollo nativo.
Si tienes poco o ningún presupuesto, desarrollas en solitario o puedes permitirte sacrificar un poco de tu rendimiento, usa híbrido.

Señores, creo que enfrentar puntos de vista minusvalorando las aportaciones de los demás, descalificando y tachando de cuasi ineptos a los que tienen puntos de vista y experiencias distintas a la nuestra nos hace un flaco favor, no solo como usuarios, también como personas.

Una vez respondido al tema general del hilo diré que yo me dedico a desarrollar aplicaciones para una empresa que no flaquea en presupuesto, con un buen equipo de multimedia y desde el primer día, casi cada línea de código que he tirado, ha sido para desarrollar apps híbridas.

Tal y como he comentado antes si, las apps nativas tienen un rendimiento ligeramente menor, pero cuentan con algunas desventajas en ciertos aspectos y con la gran ventaja de ser multiplataforma.

Alguno ha comentado por ahí que ha trabajado con Ionic y Angular1, y otro que el "cool kid" de turno la lió con el desarrollo híbrido.
Ionic1 y Angular1 son otro mundo con respecto a Ionic y Angular2, en rendimiento, arquitectura, mejoras... se han reconstruido de 0 y su rendimiento es impresionante cuando son bien usados

Como apuntaba Zerokk por ahí, y aquí ya vamos con el tema "cool kid": Son aplicaciones, no juguetes. Si te están pagando por ello, es tu responsabilidad como desarrollador tomarte en serio el proyecto, implicarte con tu cliente y entregar el mejor producto posible. Y para ello debes emplear más tiempo en optimizar, tener en cuenta las diferencias que existen entre los navegadores de las distintas plataformas, usar los recursos con los que te provee el framework y las herramientas que usas y reflexionar sobre si tu enfoque para un determinado problema es el correcto desde el punto de vista del rendimiento.

¿Eso amplia el tiempo de desarrollo? Si
¿Requiere de un mayor presupuesto? Si

Y aun así, seguirá saliendo mucho más barato y flexible que un desarrollo puramente nativo.

6
BLZKZ

#24 con RN debes tener especial cuidado porque puedes petar facilmente el thread js sobre el que ejecutas las animaciones o lógica cualquier cosa. Y no, ese "cuidado" en nativo no se exige. He visto apps rascar de la manera mas tonta en RN en un google pixel, y gastar tiempo en optimizar que con nativo no te preocuparian, sobre todo por la manera en la que se ejecuta js.

Y esto lo digo gustandome RN y habiendo estado meses pasandolo genial en el curro en un proyecto, pero no, no es lo mismo.

MTX_Anubis

Yo creo que habría que poner una norma nueva en MV, antes de recomendar cualquier cosa poner nuestro CV o proyectos en los que hemos trabajado y con qué tecnologías.

2
HeXaN

Sabía yo que en este hilo iba a soltar unas cuantas manitas.

Usuarios habituales