Server für Android App, womit schreiben/welches system?
-
Hio
ich brauch für eine Android app einen Server der nachrichten der app verwalten kann bzw. per GCM push benachrichtigungen an die app senden kann.
Diese nachrichten sollen verschlüsselt werden, dann auf dem server verarbeitet (können unterschiedlicher art sein. Aka chatnachrichten, registrierungen, verwaltungsoptionen usw)) und je nach typ in ner MySQL DB gespeichert werden.
Mir wurde da jetzt websockets als system empfohlen, und was ich da so finde eignen sich perl und ruby da gut für server.
Habt ihr noch weitere empfehlungen, wie ich da vorgehen kann? Hab mir server/webapplikationen quasi keinerlei erfahrung und auch mein php und js sind quasi nicht vorhanden, muss alles jetzt passend zu diesem projekt angelernt werden.
-
Die billigste Variante ist ein PHP Webservice mit Symfony bzw. Silex. Dazu reicht ein billiger Webhoster.
Alternativ ist natürlich auch Ruby on Rails oder Node.js beliebt für sowas.
Perl würde ich dir auf keinen Fall anraten.Die interessante Frage ist natürlich, was für Power brauchst du. uU ist Google App Engine einen Blick wert.
Wenn es dir prinzipiell aber nur um Push Notifications geht, dann häng dich am besten in das System rein dass du verwenden willst, für Android zB Google Cloud Messaging oder bei iOS eben Apple Push Notification Service. Es gibt auch Services die da ein unified Interface anbieten.
-
Server ist von der Uni zur verfügung gestellt. Weiß nicht was da genau alles drauf läuft außer php, ruby und perl, mehr hab ich nich gecheckt.
Geht auch nichtnur um push notifications, der server soll auch dtaenbankverwaltung übernehmen, daher brauch ich zusätzlich was eigenes. (unterschiedliche nachrichten müssen in unterschiedliche dbs usw)
Power wird, zumindest zur entwicklunsgzeit nicht viel gebraucht, danach kommts halt drauf an wie viele user die app bekommt^^ Beim testen werdens höchstens 2-3 stringnachrichten pro sekunde sein.
Rest werd ich mir angucken, aber darf ich fragen warum Perl nicht? Ich brauch zwar jetzt kein webhosting, aber bei billigen ist, soweit ich das gesehen habe, oft z.B. nur Perl dabei (außer natürlich php).
Was unterscheidet denn Ruby on rails von Ruby? Bei dem websockets tutorial was ich gefunden habe wurde zumindest, laut aussage des textes, normales ruby genutzt.
Node.js ist quasi lokales js?
e: okay, nevermind node.js, ist nicht installiert wenn ich das richtig sehe...
e2: und ror auch nicht
vlt muss doch n eigenes hosting her... Oder ich muss mir die php frameworks mal angucken. Wobei die sicherlich ebenfalls nicht installiert sind.
-
Ja wenn du nur einen simplen Stack zur verfügung hast ist oft PHP die beste Wahl - weil es die wenigsten Anforderungen an den Server hat.
Symfony2 ist ein gutes Framework bzw. Silex als Microframework basierend auf Symfony.
Ich würde dir dennoch empfehlen die Google App Engine anzusehen.
-
Es gibt neben AppEngine auch noch andere PaaS Anbieter, die oftmals etwas flexibler sind. Heroku und OpenShift bieten z.B. wahlweise Java, PHP, Pyhton, Node.js und Ruby (on Rails) an und haben ebenfalls kostenlose Angebote, die während der Entwicklung durchaus reichen können.
Wenn du eh kein direktes Vorwissen in einer der Sprachen oder Frameworks mitbringst, ist es vielleicht gar nicht so schlecht einfach mal in ein paar reinzuschnüffeln. Python, Ruby und Node.js haben im Web Bereich alle ein ziemlich großes Ökosystem drumherum.
Von Websockets würde ich dir aber im mobile Bereich abraten, außer du benötigst Echtzeitkommunikation. Bei Websockets brauchst du eine konstante Verbindung, was bei mobile eher nicht gegeben ist. Stattdessen könnte sich ein REST Service anbieten.
-
Möchte eigentlich möglichst unabhängig von externen services bleiben (auch wenn man die für push benachrichtigungen ja wohl braucht) udn das ganze lieber auf nem eigenen server/hosting laufen haben. Grade weil die backend entwicklung der mit abstand größte teil meiner thesis in diesem projekt ist möchte/muss ich da wohl von grund auf arbeiten. Aber ich kann das demnächst nochmal ansprechen, wenn wir uns das nächste mal zur vorbesprechung treffen.
Vielleicht seh ich da auch nur den großen vorteil nicht, aber das sind doch (vereinfacht gesagt) auch nur hostings, die dann (vlt) aus der app heraus bequemer anzusprechen sind als was selbstgehostetes udn vielleicht zur entwicklung n paar bequeme tools zur verfügung stellen?
Zum rest:
Ich werd mal mit dem admin in der uni sprechen, ob er vlt auf dem server node.js installieren kann, wurde mir jetzt auchnoch von anderen kommilitonen empfohlen.
zum letzten: Nja, auch das wurde mit empfohlen^^ Ich brauch insofern ne verbindung, weil n chat enthalten sein soll, aber REST guck ich mir auch mal an. Hab ne Thesis von ner reinen chatanwendung vorliegen, die ich bisher nur überfliegen konnte, die sieht so aus, als ob sie REST genutzt hat.
Ne verbindung zum server braucht meine app nur, wenn sie aktiv genutzt wird (und dann wohl zwingend), push benachrichtigungen möchte ich mit gcm realisieren, weil das wohl auch funktioniert, wenn die app nicht gestartet ist.
Aber ich werd mir das auf jeden fall auch mal angucken.
e: zumindest mal wegen der google app engine:
Authentifizierung
Basierend auf Google Accounts, d. h. User mit Google-Konto können sich bei Anwendungen anmelden.
(von wikipedia)
Das is n no go, auch unser dozent is der meinung, dass wir eigene accounts umsetzten sollen und keine fremdauthentifizierung nutzen wollen/sollen.
-
Ja, auch Chats per REST oder ähnlichem machen. WebSockets sind für sowas mobile Geräte ungeeignet und auch aus kostengründen ungut.
Wenn du alles selber machen willst, dann such dir einen Software Stack aus:
Python, Ruby, PHP, Node.js
und ein passendes Framework dazu und mache es selber.Im Prinzip nimmt es sich da nicht viel was du davon nimmst, solange du dich für ein vernünftiges Framework entscheidest.
-
Okay, danke.
REST sollte sich ja auch von ner PHP Seite aus umsetzten lassen, das soll ebenfalls ein Bestandteil werden.
Was ich davon nutze mal sehn. Wie gesagt, mir wurde jetzt auch von anderen seiten her node.js empfohlen, also werd ich mir das wohl als erstes angucken.