ZONNY - Projet arrêté

Salut ! Je viens vous présenter aujourd’hui le projet ZONNY.

Qu’est-ce que c’est ?

ZONNY est une application (Android et iOS) permettant de créer des événements spontanés éphémères avec ses amis. Euh… concrètement ?

Voilà :

L’idée générale est de pouvoir facilement et rapidement organiser des petits évènements avec ses amis genre une p’tite bière, un foot ou encore une expo (ouais expo on verra hein )

On connait tous (enfin du moins je crois !) le fait de devoir envoyer des messages à tous ses amis pour demander qui est libre dans l’après-midi, de demander qui est là quand on rentre de vacances ou encore de pas savoir quoi faire avec ses amis.

Aussi, contrairement à la majorité des autres applications, nous proposons à l’utilisateur de sortir (dans la vie réelle) et non pas de rester chez soi sur son écran.

Screens

Image en HD

Image en HD

Image en HD

Image en HD

Image en HD

Image en HD

Image en HD

Image en HD

Maquettes

Image en plus grand

Image en plus grand

Image en plus grand

Image en plus grand

Image en plus grand

Image en plus grand

Image en plus grand

Image en plus grand

Image en plus grand

Fonctionnalités

• Carte affichant la position de vos amis de façon approximative, vos évènements, ceux auxquels vous êtes invités, ceux publics crées par vos amis. Il y a également des suggestions d’événements.

• Demander à un ou plusieurs ami(s) s’ils sont libre(s) sans créer d’événement bien défini.

• Créer soi-même un événement éphémère.

• Chercher un évènement spontané à proximité.

• Choix aléatoire d’un événement spontanés à proximité.

• Chat avec uniquement les participants à l’événement. Non présente dans l’Alpha

• Génération d’un point de rencontre équidistant de chaque participant (pour les événements n’ayant pas d’adresse/activité bien définie)

• Disparaître de la carte

• Créer un événement éphémère visible par tous les amis à proximité de l’utilisateur. Non présente dans l’Alpha

• Système permettant de demander à être invité à un évènement public crée par un de ses amis.

D’autres fonctionnalités sont à l’étude, mais dans un soucis de temps et surtout de ne pas perdre l’utilisateur dans l’utilisation de l’application elles ne seront pas présentes dans les premières version de l’application.

Travail réalisé

Cela fait depuis quelques mois (certains plus productifs que d’autres) que nous travaillons sur ce projet. Dès le début, nous sommes partis trop rapidement. Nous avons donc en Septembre 2017 repris depuis zéro. Et depuis, le projet a sacrément avancé !

• API Restful. Documentation Swagger incluse. https://zonny.me/docs. Pour les non initiés, il s’agit de la partie serveur qui est chargée de centraliser les données entre les différents utilisateurs. C’est le cerveau du projet en quelque sorte. Le Github est ici : https://github.com/baudev/ZONNY_API/

• L’application Android est au stade d’alpha. Disponible ici !. Le Github est accessible ici : https://github.com/baudev/ZONNY_ANDROID

• Landing Page pour la présentation de l’application. Disponible à l’adresse https://zonny.me

• Obligations légales comme les Mentions Légales, la Politique de confidentialité, les Conditions Générales d’Utilisation ou encore les Crédits.

Choix des technologies

• API - Php avec Slim https://www.slimframework.com/ et Doctrine

• App Android - Java

• App iOS - Swift

Les repositories Github

• API (en PHP) https://github.com/baudev/ZONNY_API/

• Application Android https://github.com/baudev/ZONNY_ANDROID

• Application iOS https://github.com/baudev/ZONNY_IOS

• Site Web https://github.com/baudev/ZONNY_WEBSITE

Intéressé ?

Ne sois pas timide et viens nous retrouver sur notre Discord !

Pourquoi je présente ce projet ici ?

La réponse est simple : pour avoir vos commentaires et vous montrer l’évolution de ce projet

J’ai beaucoup de questions à vous poser, je viens apprendre de votre expérience dans le développement d’un projet : « utilise tel Framework il est dingue », « mauvaise idée ce bouton » ou encore « idée de projet nulle parce que … ».

Voilà, merci de m’avoir lu !

Merci, en effet on voit pas grand chose! Une des solutions serait (je pense) de changer le couleur de "Liste" :

Après, nous pensons enlever finalement cet affichage par liste. En effet, cela rajoute du travail pour quelque chose de pas forcément très utile. (surtout qu’après il faut se demander comment on affiche les événements,les amis…)

Je viens d’apprendre un mot ! On va donc prendre événement. Pourquoi se compliquer quand on peut faire simple ?

Salut,

Bien que je ne sois pas la cible de votre projet, je trouve que c’est une très bonne idée. Le design est réussi et travaillé. Globalement il est difficile de faire des retours aujourd’hui parce que on se rend pas très bien compte de la difficulté d’utilisation avant de l’avoir sur son téléphone.

Par contre je sais pas, mais j’ai l’impression que c’est le genre de fonctionnalité qui pourrait être ajouter à Snapchat. Déjà parce que le public de base est nombreux, et qu’après leur mode carte ça me semble être une suite assez logique. Je me verrais pas ajouter une nouvelle application pour ça.. Mais c’est mon avis.

Bonne journée !

Merci ! Je comprends mieux le silence sur ce topic du coup

En effet, cette fonctionnalité pourrait très bien être ajoutée à SnapChat. Mais heureusement ils ne m’ont pas encore piqué mon idée ! Non, sérieusement c’est pour cela que l’utilisation de l’application se fera avec son compte Facebook. Aucune autorisation particulière ne sera demandée par contre (ni la liste des amis, ni le mail etc). C’est très dur, comme tu le dis, de créer un "public de base" et c’est pour cela que la connexion par Facebook est nécessaire. Après, par rapport à SnapChat, la carte de ZONNY sera un peu différente : les localisations seront moins précises pour les amis qui ne seront pas à proximité de l’utilisateur. Quand la localisation est trop précise, c’est trop intrusif pour l’utilisateur et cela peut le pousser à désactiver la localisation voire même supprimer l’application.

Aujourd’hui, c’était modélisation de la base de donnéees. Si vous avez des questions ou remarques, n’hésitez pas

Comme vous l’avez peut-être remarqué, hier quelques corrections ont été apportés au schéma de la base de données: une table était inutile et une autre n’était pas complète. Maintenant, cela devrait-être bon

J’ai finalement changé de Framework pour la réalisation de l’API. Il s’agit maintenant de Slim https://www.slimframework.com/. Il est très simple et rapide à prendre en main. Le codage de l’API a donc commencé !

J’ai également commencé une landing page pour ce projet. Je déteste faire plusieurs choses à la fois mais ça me détend quand le codage de l’API commence à me saouler

Un petit aperçu : Il y a encore beaucoup de boulot sur cette page, ne vous fatiguez pas à faire des remarques sur ce screen!

Petite question : Comment tu comptes questionner la BDD avec des positions géographiques ? Par exemple, comment tu comptes récupérer la liste des IDs des évènements à proximité des coordonées 46°46’24.9"N 6°04’11.7"E ?

Merci c’est une bonne question! Je n’y avais pas réfléchi concrètement… Ta question me pousse à revoir ma base de données (je préfère ça maintenant que dans deux semaines ). Je viens de la modifier #post161899 de telle sorte à ce que chaque position soit décomposée en deux valeurs : latitude et longitude. (J’en ai d’ailleurs profité pour ajouter une table stockant les IP des personnes malintentionnés)

Chaque latitude et longitude étant en coordonnées décimales (ex: 45.975 ; 2.324) l’algorithme est plus simple :

1
2
3
4

/* latitude et longitude de l'utilisateur */
$latitude = 46.22;
$longitude = 2.21;
$rayon = 20; // exprimé en km

Sachant que chaque degré de latitude et longitude correspond à 111 km ( par approximation )

1
2
3
4
5
6
7

$rayon_deg = $rayon / 111;
$latitude_mini = $latitude - $rayon_deg;
$latitude_max = $latitude + $rayon_deg;
$longitude_mini = $longitude - $rayon_deg;
$longitude_max = $longitude + $rayon_deg;

$request = "SELECT * FROM events WHERE latitude BETWEEN $latitude_mini AND $latitude_max AND longitude BETWEEN $longitude_mini AND $longitude_max"

Cette solution me semble la plus simple (pas forcément la plus juste après…). Si vous avez des idées/corrections, je vous écoute

Merci pour vos retours !

Fais attention à suivre un nommage cohérent entre les colones de ta BDD. Je pense qu’il vaut mieux que tu mettes ip en minuscules dans ta table hack_attempt. Je pense que ça serait égalementplus logique mettre le nom de cette table au pluriel : hack_attempt.

motet-a

Corrigé, merci

Sachant que chaque degré de latitude et longitude correspond à 111 km

Nan . Un degré c’est un angle. Ça ne correspond pas à une distance. Enfin, tu peux dire qu’à un endroit donné de la terre, un degré de latitude ou de longitude vaut telle distance en kilomètres. Mais ça ne sera pas vrai partout.

motet-a

En effet, cette approximation est fausse mais elle me semblait nécessaire . Alors que pas du tout en fait !

Dans cette présentation : https://fr.scribd.com/presentation/2569355/Geo-Distance-Search-with-MySQL il y a une diapo qui m’a particulièrement fait peur. Elle montre le temps d’exécution de la requête suivante :

1	SELECT *, 3956 * 2 * ASIN(SQRT( POWER(SIN((@orig_lat - abs( dest.lat)) * pi()/180 / 2),2) + COS(@orig_lat * pi()/180 ) * COS( abs (dest.lat) * pi()/180) * POWER(SIN((@orig_lon – dest.lon) * pi()/180 / 2), 2) )) as distanceFROM hotels desthaving distance < @distORDER BY distance limit 10;

C’est énorme 4 secondes . Après je n’ai pas vérifié par moi même… C’est pour cela que j’ai pensé à tort qu’il fallait une autre solution rapide mais approximative.

Je ne connaissais pas ces solutions et franchement elles sont tops ! Malheureusement j’ai regardé pour MySQL et je n’ai pas trouvé d’équivalent. Dommage .

Sinon la solution envisagée en MySQL serait celle proposée par Google https://developers.google.com/maps/articles/phpsqlsearch_v3#creating-the-map :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

SELECT 
id, 
(
   3959 *
   acos(cos(radians(37)) * 
   cos(radians(lat)) * 
   cos(radians(lng) - 
   radians(-122)) + 
   sin(radians(37)) * 
   sin(radians(lat )))
) AS distance 
FROM markers 
HAVING distance < 25 
ORDER BY distance LIMIT 0, 20;

J’hésite presque à passer sur Postgre pour cette fonctionnalité (même si j’ai déjà beaucoup de lecture : Slim pour l’API, NodeJS pour le chat…). Est-ce que cela vaut le coup ?

Postgres, MySQL, MariaDB et SQLite sont toutes basées sur du SQL. Il y a pas mal de choses qui changent entre ces BDD mais la syntaxe reste globalement la même. Tant que tu ne fait pas des choses assez avancées, tu ne devrais pas avoir d’énormes problèmes à passer de l’une à l’autre.

En revanche, je pense que mélanger PHP et Node.js pour le backend va compliquer un peu les choses : C’est deux langages bien différents, deux écosystèmes également bien différents et ça ne tourne pas du tout pareil en production (pas de *CGI pour Node.js). Tu as pensé à tout faire avec Node.js ou même avec PHP (en utilisant éventuellement un service externe pour le temps réel genre SNS/GCM/Pusher, même si ça peut compliquer un peu) ?

Je vais y réfléchir, à commencer par regarder à quel point c’est différent pour mon utilisation!

C’est ici que les choses se compliquent en effet ! En fait, je ne souhaite pas créer de système de chat dans cette application. Pleins d’applications sont déjà extraordinaires pour cela. La connexion se faisant en plus par Facebook, pourquoi se priver de Messenger ?

Le scénario :

• l’utilisateur a crée l’événement et clique sur "Messenger".
• si l’évent comprend seulement un ami alors on ouvre simplement la conversation Messenger avec cet ami.
• si l’évent comprend plusieurs amis alors ça se complique. Le bot de ZONNY crée une conversation Messenger de groupe avec ceux ayant déjà répondu oui à l’évent. Parmi tout ceux qui n’ont pas encore répondu, ceux qui répondront oui par la suite seront automatiquement ajouté à la conversation de groupe.

C’est une fonctionnalité très pratique en soit ! Mais la réaliser est plus compliquée. J’ai regardé dans la doc Facebook, pas moyen de faire cela . Du coup la seule solution envisageable est la création d’un bot en NodeJS https://github.com/Schmavery/facebook-chat-api. Le problème reste quand même qu’il ne s’agit pas d’une solution officielle et il y a donc un risque de ban du bot. La question est maintenant de savoir si ce risque est très élevé et s’il ne faudra pas malheureusement seulement créer un chat dans l’application.

Il existe pas un truc ressemblant à mailto:// ou magnet:// ou encore web+mastodon:// mais pour messenger ? (sms:// ou messenger:// ?)

Pas exactement. Par contre Facebook serait presque prêt à payer pour que les gens intègrent messenger dans leurs apps, évidemment ! Ils fournissent des SDK généralement bien conçus et bien documentés. Je désapprouve mais bon, j’utiliserai pas l’app de l’OP de toute façon.

Non malheureusement. Il en existe quand-même quelques intéressantes comme par exemple fb://messaging/groupthreadfbid/ pour afficher un groupe. (liste complète : https://stackoverflow.com/a/30231726/8219923 )

Je veux bien comprendre pourquoi tu désapprouves. Mais un chat dans l’application ne pourra être que plus nul que ceux déjà existants. En soit créer un bon système de conversation, c’est créer une application à part entière ! Entre un bon système de conversation "maison" et Messenger je choisirai aussi la solution indépendante

Ce soir, c’était décomposition des différentes opérations possibles dans l’API. C’est pas très documenté mais si vous voulez voir :

S’il en manque, qu’il y a des erreurs ou autre, n’hésitez pas

Je veux bien comprendre pourquoi tu désapprouves.

Parce que je vais pas créer un compte Facebook juste pour ton application.

Tu surestimes pas mal la difficulté que ça représente.

Ma remarque "Je veux bien comprendre pourquoi tu désapprouves" était une affirmation Je ne me permettrai pas de te parler comme ça ! Mais tu soulèves un point intéressant : ceux qui n’ont pas Facebook. Ils sont nombreux. J’ai pensé à l’intégration d’une connexion par SMS mais un problème majeur me gêne :

Il faut dire que je n’y connais pas grand chose dans ce "domaine". J’ai fais cet après-midi quelques recherches… Je suis prêt à abandonner mon idée d’intégration de Messenger si j’arrive à créer moi-même un système stable et complet! Je souhaite par contre rester sur du PHP si possible. Si tu as des conseils, je suis preneur . Je vais faire un tour sur les différentes solutions SNS/GCM/Pusher ce soir.

Merci pour tes corrections et d’avoir tout lu ! En effet, la différence entre POST et PUT était un peu floue pour moi. Je corrige ça dans la minute.