Cześć,

mam takie nietypowe pytanie. Czy ktoś może mnie uświadomić jak wykonać własonoręcznie api pod sms-y dla aplikacji php? zasada działania;

1 w aplikacji wybieram do kogo leci wiadomość oraz oczywiście treść ()
2 request z tymi informacjami leci np na jakąś stronę która sprawdza czy doszło są jakieś nowe informacje do wysłania
3 aplikacja android wywołuję tę strone, sprawdza żądanie, jeżeli coś jest to pobiera cały request (numer tel, wiadomosć), i rozsyła sms-y? (Uprzednio sprawdzając czy taki numer jest w telefonie oczywiście)

Tak, wiem, że jest to imo bez sensu, bo są płatne sms-api itd, ale chciałbym coś takiego wykonać na potrzeby pracy inż. Ciekawi mnie na ile jest to wykonalne i czy model który podałem wyżej faktycznie by działał?

Opisałeś kluczowe etapy procesu. Będzie działało, pytanie czy satysfakcjonuje Cię to rozwiązanie bo wystarczy blokada dostępu do SMS dla aplikacji i leżysz.

Satysfakcjonuje na poziomie pracy inż i swojego rozwiązania. Nie będzie to wdrożone komercyjnie, zbyt ryzykowane tak jak piszesz. Profesjonalnie wykupiłbym jakieś api sms, podłączył i by hulało, ale nie o to chodzi.


Wracam jeszcze. Problem staje się nawiązanie połączenia. Telefon musiałby być cały czas podpięty pod sieć to raz a dwa mieć otwartą stronę www z której będzie ściągał te dane.

Da się może jakoś wysłać requesta bezpośrednio do androida?

Tak, https://developers.google.com/cloud-messaging/

Możesz podpiąć telefon do serwera po USB i korzystać z niego jako modemu. Wtedy albo aplikacja do wysyłania SMS albo komendy AT.

Druga opcja - jeśli już musi być przez WWW to WebSockets - push od strony serwera do telefonu.

Vokiel, AT? co masz na myśli? Jak to mogło by wyglądać w takim stanie? wysyłam z aplikacji sms i dalej?
nie nie musi być strona.
I czemu websocet? chyba się zgubiłem gdzieś zgubiłem. Mógłbyś przedstawić schemat requesta od początku, czyli z aplikacji do androida?

Opcja 1.
Jeśli masz własny serwer, albo nawet jakieś Raspberry Pi czy stary laptop - możesz do niego podłączyć telefon i korzystając albo z komend AT albo z aplikacji GAMMU, Wammu czy innych podobnych.
AT - czyli https://en.wikipedia.org/wiki/Motorola_phone_AT_commands (przykład 1, przykład 2

Opcja 2.
WebSockets - to rozwinięcie Twojego pomysłu. Czyli:

1.w aplikacji wybieram do kogo leci wiadomość oraz oczywiście treść ()
2 request z tymi informacjami leci do serwera (kolejka do wysłania)
3 android wywołuję tę stronę (ma ją cały czas otwartą), WebSocket push z serwera wysyła info, że są nowe wiadomości do wysłania, pobiera i wysyła.

Korzystając z WebSockets nie masz opóźnienia, a przy tym nie musisz na androidzie sprawdzać co jakiś interwał czy są nowe wiadomości. Oszczędza to transfer i niweluje opóźnienia.

W zasadzie, to może być nawet jedna aplikacja webowa (z różnymi poziomami dostępu).

Dobra, czy dobrze rozumuję

https://gyazo.com/4f3a1edd338fd43da8a05cb9eb0c8c53

Z websocetami może być ciezko bo nie znam ich po protu na tyle by nimi operować.

Jeśli nie znasz i nie chcesz/nie masz czasu an naukę websockets to możesz pozostać przy periodycznym odpytywaniu serwera.
Tak będzie również ok, tym bardziej, że będziesz miał tylko jednego klienta do tego odpytywania (z WS zyskuje się tym więcej, im więcej klientów korzystających z zasobu).



W skrócie:
1. Po wysłaniu formularza dodajesz SMS do kolejki (może to być najzwyklejsza baza danych).
2. Android w interwałach pobiera oczekujące wiadomości i je wysyła. Może też zmieniać ich statusy (wysłany, odebrany).

Zastanawia mnie tylko jeszcze jedna rzecz po stronie androida.. jeżeli już są nowe wiadomości to gdzie one trafiają dokładnie ? przecież to musiała by być jakaś aplikacja chyba napisana która pobiera ten request i rozsyła smsy. Aplikacja ta też musi też przecież odpytywać stronę o nowe dane. Dobrze myślę?

edit
czym więcej czytam tym większy mam mętlik..
reasumujac życie requesta

1 zostaje wysłany na adres np /smsApi
2 zapisuje się w bazie, pliku
3 android wysyła na adres /smsApi reqesta ajaxowego po te dane do bazy