Android: Arkitekturspoergsmaal, udvikling af service
Jeg staar foran at skulle udvikle en Android app og er i den forbindelse ved at faa klarlagt arkitekturen. Jeg har lavet et par simple apps, men jeg er stadig ny til Android udvikling.
I store traek skal min app kunne sende notifications til brugeren. Disse notifications skal affoedes af andres brug af app'en. Jeg forestiller mig, at arkitekturen kommer til at ligne den som Facebook bruger, naar man modtager en notification om, at der er en som har sendt en besked/kommenteret paa ens profil.
Jeg har kigget paa "Service" klassen i Android, og det ser ud som om, at det er saadan noget, jeg skal have fat i. Jeg forestiller mig:
1. At beskeder fra andre apps bliver gemt i en remote MSSQL database gennem nogle posts til nogle php/ASP.NET sider. Er det maaden at goere det paa i Android?
2. At udvikle en service, der pool'er databasen med queries hvert 10. minut for at checke, om der skal sendes en notification til brugeren af app'en (hvis der fx er sendt en besked til brugeren eller sket andet, som kraever en notification).
Er det maaden at goere det paa? Jeg forestiller mig, at det godt kan laegge en hel del pres paa SQL serveren? (afhaengigt af hvor populaer appen bliver selvfoelgelig).
Jeg har laest mig til, at det at poole databasen hvert 10. minut kan vaere dyrt for batteriet.
Alternativet er en persistent TCP/IP forbindelse. Det er dog ogsaa batterikraevende og der er stoerre risiko for at Android draeber servicen. Saa ud over at den ogsaa har ulemper, er den mere omfattende at kode (og lige nu leder jeg efter den mest simple - det kan vaere det laves om paa et senere tidspunkt)...
Selvfoelgelig ville man med en TCP/IP forbindelse faa real-time notifications hvilket ikke ville vaere tilfaeldet med den foerste loesning. Det er dog ikke saa vigtigt, hvis den bare bliver poolet hvert 10. min.
Jeg vil klart anbefale dig at kigge på C2DM der er en af de teknologier der eksistere for at gøre dette muligt, det tager dog lidt tid at sætte sig ind i.
Du skal have en loesning for: - client side - protokol - server side
Client side kode er ret nem at kode uanset hvilken comm det drejer sig om.
Protokol maessigt skal du vaelge mellem: - simulere push via poll - lave true push
Batteri tid er helt klart et kriterie. Jeg vil dog ikke udelukke at du kan leve med poll hver 10. minut - det er ikke saa tit.
True push paa Android er C2DM.
Det vil vaere meget normalt at bruge en database til at gemme messages i.
Medmindre du skal have rigtigt mange brugere, saa vil jeg ikke vaere bekymret for den del.
En hel almindelig PC database server boer nemt kunne serve 50000 queries/minut og med en query hver 10. minut kan det understoette 500000 brugere. Og det er uden caching i app. Med caching i app saa vil du kunne understoette meget mere.
Med poll skal du have en web services f.eks. JSON/HTTP i app layer.
Med true push skal opdateringer triggere et outbound web service kald.
Tak for input! Jeg har nu faaet en C2DM prototype til at koere. Dokumentation er dog begraenset saa har lige et spoergsmaal mere.
Naar jeg laver den indledende REGISTER til C2DM serveren for at registrere det paagaeldende device, saa boer jeg vel gemme mit registration id i en database paa min App Server sammen med evt. brugernavn, saa jeg ikke registrerer hver gang jeg aabner appen.
Jeg forestiller mig en loesning med en splash screen foerste gang man aabner app'en, hvor man klikker "OK". Idet man klikker OK, laver APP'en en REGISTER, hvorefter registration id bliver gemt paa baade telefonen og min APP Server.
Paa den maade kan jeg sende notifications fra APP Serveren. I tilfaelde af at brugeren skifter device eller laver en hard reset, vil selve devicets registration id vaere null, og saa vil de blive moedt af min splash screen igen, hvorefter jeg kan opdatere brugeren med det nye registration id paa min APP Server.
Lyder det ikke meget fornuftigt?
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
