Hello Z, This is an very interesting idea!
I would be happy to help with the creation of an experimental smslib v4 build supporting this. It would be easier (although not theoretically better) to pull sms from the phone instead of pushing to smslib, but as you propably already know, smslib v4 is already running an embedded http server. My goal is to "modularize" that in order to be easy to add "listeners". So, I need to quickly finish up this task in order to easily add your listeners. I personally like this idea. I don't have an android phone - what kind/class of phone would you need to run this application? You should point me to some cheap models - I may buy one for dev purposes :) On 24 April 2014 04:28, zeeman via SMSLib Discussion Group < smslib+noreply-apn2wqelb8yosywvp8ola5xw-yttrqoilgoqu4zvd7xubs...@googlegroups.com > wrote: > Hi! > > My application is purely consuming SMS from a mobile. Given the audience > of the application, the time of GSM-enabled mobiles is gone. > True, there are (cheap) GSM-USB-Modems available. Nevertheless I though of > some kind of proxy application to be installed on a smartphone (focusing on > android first as I do not own a iPhone) which proxies incomming SMS and > send them (via network) to a PC/smslib to be processed as "normal" within > SMSlib. > > Being on vacation, I spend some hours to hack together a prototype which > works on a high detail depicted below: > > 1. Android application intercepts all incomming SMS (and forwards them > to the inbox as usual after processing on the phone) > 2. Intercepted SMS is repackaged as JSON-String > 3. Android application sends this JSON-String to a small HTTP endpoint > via regular TCP/IP > 1. though the Android phone and the PC have to be in the same network > (wifi) or they might be paried in a PAN > 2. At first I thought about bluetooth but the situation seems as > ugly as Java's RComm mutli-platform support (see JSR-82) > 4. The HTTP endpoint itself is also a regular SMSlib driver and the > handlers/listeners can be used as with the modem driver > > > All in all I'm quite happy with the approach so far. The list of required > permissions for the android app is quite short (READ_SMS and > ACCESS_INTERNET) and the code is quite short - way shorter as I expected ;-) > > As this is still a pure hack and my first mobile app (so this was more of > an idea to get the feet wet with android programming) I'd like to get some > feedback before putting this all together and making it a real contribution > to the project: > > - Is there any desire to include such a functionality as described > above into SMSlib v4? > - The smslib-part (including the HTTP server) comes with a short list > of new dependencies (in fact only jersey-server and jersey-json) - But it > might be worth having this as a dedicated smslib module, nor? > - The android app is quite small and I think there is little benefit > putting it on the app store. Installing via "untrusted sources" works quite > well and anyone using SMSlib should be on a level a) estimating the risk of > this installation and b) performing it. > - Therefore the APK file should be bundled/distributed with SMSlib > (somehow) and incorporated in (an optional?) build > > > What do you think? > As I'm quite at the beginning of my journey I'm happy for any feedback. > > -- > You received this message because you are subscribed to the Google Groups > "SMSLib Discussion Group" group. > To view this discussion on the web visit > https://groups.google.com/d/msgid/smslib/ffbcfe20-c55b-4649-a6a4-8994efae560c%40googlegroups.com<https://groups.google.com/d/msgid/smslib/ffbcfe20-c55b-4649-a6a4-8994efae560c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "SMSLib Discussion Group" group. To view this discussion on the web visit https://groups.google.com/d/msgid/smslib/CABkOnhMZn-fXNUuzwbLgSfa27qV6w5QcJxMGjbwqcDFRdzPcJg%40mail.gmail.com.
