WifiSMS
WifiSMS copied to clipboard
Feature Improvement: Compose Contact Number Type, Bug: SMS Notification
On my second day of using WifiSMS and still, it is exactly what I have been looking for (donation coming soon). I have it pinned as an "App" in firefox which is awesome. Even shows up as notification in the App tab (glows)
I have a request and a possible bug report.
Request: I think that it's great that the app shows the list of active conversations on the right, and it has the ability to compose new SMSs based on a phone number, and even autosuggest for contacts. This is 90% there. I think that it would be exceptionally awesome if it could somehow show what each of the phone numbers is associated with (iPhone, Home, Work, etc). Right now it just shows a number, which is less than helpful.
Bug: When pinned as an "App" in firefox, I notice that when I am on another tab and I get an SMS, the tab usually glows after a few seconds. Great! What I noticed though is this glow/notification only happens if I left WifiSMS on ANOTHER contact than the one that just sent an SMS. If I was talking to someone and left the screen on that contact, moved to another tab, an they send me a text, it does not nofity. If, on the other hand, I leave the WifiSMS window on a contact, but a DIFFERENT contact sends me a message, I get the notification. Actually, it seems if I leave it on the same contact, and don't get a notification, check the tab to see the new SMS, click on another contact, click on another tab in FF, then immediately I get both the App Tab notification AND the little red number next to the contact who sent me the SMS. So it seems like there are two things going on here.
Thanks! Best app for my iPhone!
-Brian
One other thing. The "Digging the app so far?" bar at the bottom covers up the message character counter.
-Brian
The way that your Firefox is glowing is the way that it should happen. Programatically, I don't think we are able to determine whether you are actively on the page or not. If you were to send notifications always to the current SMS conversation, that would be more of an annoyance when you are actually on the page.
I am a web developer. Could you please explain to me how you are notifying the browser of an "Alert" in WifiSMS? Any specific JavaScript that you are using?
-Brian
QuerySMS() checks for SMS, then calls shownotify() in this file:
https://github.com/treason/WifiSMS/blob/master/wifiSMS/Web/func.js
I did some research and it looks like the way that FF knows when a notification happens (when to highlight the App tab) is when the title changes. If you currently have the App tab open, nothing happens as the title changes. If you move to another tab and the title changes then FF notifies you (by highlighting the tab). So, all that WifiSMS needs to do is change the title to something new at every SMS. Right now the problem is that if the SMS window is currently selected for the user SENDING the sms, you don't change the title.
Now your issue is that it doesn't make sense to you to change the title to "1 new message" if the user currently has that SMS user's window open since technically the received message was just "Read". So the problem is that FF don't get the changed title to make a notification.
I've solved this problem for you. I've written a small JS test case which changes the title to "1 new message" and then changes it back quickly. This has the advantage of notifying FF. See bellow:
Run this in FF with WifiSMS set as an App tab. Click the button and wait 3 seconds. While the tab is open, the title will change to "1 new message" then change back to "Original Title" and FF will NOT notify the user. Good. Now click the button again and change to another FF tab. In 3 seconds the WifiSMS tab will highlight, but if you return to that tab, you will see the title has been returned to "Original Title", which makes sense since technically I would have had that SMS user's window open so I just "read" that incoming SMS.
Basically all I am asking here is that you STILL change the title on EVERY incoming message, even if the user has the sender's SMS window open (in which case simply change the title back after a short delay). Your original point was that you don't want to bug the user, which you won't because you are only changing the title, not going through the entire notification process like you would if the user didn't have that SMS sender's window open.
All that you need to do to make this work beautifully is edit the "updateTitle()" method, and do what I suggested. Modify the code so that instead of doing nothing when the user get's a message for which the window is already open, simply flash the title briefly.
Thoughts?
-Brian
Grr. Here is my message again, with pastebin:
I did some research and it looks like the way that FF knows when a notification happens (when to highlight the App tab) is when the title changes. If you currently have the App tab open, nothing happens as the title changes. If you move to another tab and the title changes then FF notifies you (by highlighting the tab). So, all that WifiSMS needs to do is change the title to something new at every SMS. Right now the problem is that if the SMS window is currently selected for the user SENDING the sms, you don't change the title.
Now your issue is that it doesn't make sense to you to change the title to "1 new message" if the user currently has that SMS user's window open since technically the received message was just "Read". So the problem is that FF don't get the changed title to make a notification.
I've solved this problem for you. I've written a small JS test case which changes the title to "1 new message" and then changes it back quickly. This has the advantage of notifying FF. See bellow:
http://pastebin.com/Bi65tAsw
Run this in FF with WifiSMS set as an App tab. Click the button and wait 3 seconds. While the tab is open, the title will change to "1 new message" then change back to "Original Title" and FF will NOT notify the user. Good. Now click the button again and change to another FF tab. In 3 seconds the WifiSMS tab will highlight, but if you return to that tab, you will see the title has been returned to "Original Title", which makes sense since technically I would have had that SMS user's window open so I just "read" that incoming SMS.
Basically all I am asking here is that you STILL change the title on EVERY incoming message, even if the user has the sender's SMS window open (in which case simply change the title back after a short delay). Your original point was that you don't want to bug the user, which you won't because you are only changing the title, not going through the entire notification process like you would if the user didn't have that SMS sender's window open.
All that you need to do to make this work beautifully is edit the "updateTitle()" method, and do what I suggested. Modify the code so that instead of doing nothing when the user get's a message for which the window is already open, simply flash the title briefly.
Thoughts?
-Brian
I wonder if you can instantaneously change it from 1 to another and it will still flash the tab:
Have a try on this file for me?
https://gist.github.com/1169794
Hey JRC. I actually tried that initially (with no timer) by just calling two consecutive document.title="", and FF did not recognize the change. I then tried with a 1ms flash timer and it worked fine, so the user wouldn't really see the new title, but it would get the FF notification.
Also I realized there was a loop condition in my last example, so I corrected and reposted to the pastebin:
http://pastebin.com/YgCBRQnD
This example shows the 1ms flash which works fine for me in FF. Also, I have no idea how to get that new file onto my iPhone (don't have SSH setup at the moment) so I can't get that directly for you without doing a cydia update.
Let me know if I can help in any other way.
-Brian
If you are on a PC you can run iFunBox (no install necessary) if you really wanted to try it out. It allows full disk access of your iPhone. Just save it as func.js to your desktop, and then transfer it over to:
/private/var/mobile/Library/WifiSMS/Web
and overwrite the current file that exists there.
Edit: sorry I failed to mention that I updated the file to incorporate the new 1ms wait time:
https://gist.github.com/1169794
Nice tool! I just updated func.js on my device and I will let you know! Thanks for the quick turnaround! It's a shame that this app can't be sold on the AppStore. I was considering building something exactly the same as this.
FYI: Two issues that I previously posted didn't get any discussion, the "Dig This App" bar covering the char count, and the ability to see the service (iPhone, Mobile, Work) next to each auto-correct contact when composing a new message. That's basically all I see missing in the app!
Cheers.
-Brian
Yep, definitely agree with both those issues.
Hmm.
- I added the new func.js (didn't restart the phone, doubt it is necessary) and did a test and I did NOT see a notification.
- I am not sure how to perform a DIFF using github so I can't see what you changed. I tried searching for setTimeout but only found two, neither had a 1ms timeout. Can I ask where you made this change? I try to fix it up for you get send you a working version.
- Thanks. Yep just small issues, though the auto-correct label would be helpful.
-Brian
Nevermind I found it. I'll see what I can do.
-Brian
I added a sleep() function instead, just seemed easier. Want to try to increment the sleep(1) to something else? (1 = 1ms)
Not sure why sleep() didn't work (even at 2s timeout). I changed the logic to use the setTimeout() at 1ms, and it works fine for me.
https://gist.github.com/1169868
[Edit: I forked the file. I don't know if that was what I was supposed to do since I don't use much SVN : ) ]
-Brian
Yeah it's fine, @treason will have to implement it into the real Github version.
One minor change (and removed the unneeded sleep() function): https://gist.github.com/1169880/cf5c44a467c2063d54ec5f6f6c853b91edea73aa
Thanks : ) Glad I could help. WifiSMS as an App tab in Firefox is wicked. Once Treason adds to the trunk, does that mean a Cydia update will contain it immediately or will he also have to do a cydia release separately?
-Brian
Cydia release is separate. He will have to compile it and then submit to Bigboss, though he will most likely wait till next weekend for that to happen.
Ok cool.
Also, question. This App is build on top of a web server of some sort. The JS makes ajax calls to it, but I see no server side scripts. My guess is that he compiles the web server with the server side logic embedded within it. What server is he using for this app? I build Web Applications in Coldfusion as a self-employed developer and I am trying to figure out how you guys deploy web-apps directly on the device.
Thanks!
-Brian
I have absolutely no part in the writing of his server, not sure if it was a premade software or not. But anways, there exists a file called HTTPServer.m that obviously accepts the requests to the server. Inside the classes folder exists MyHTTPConnection.m which does all the handling of the responses from the Sqlite databases.
I can't go much more in depth then that, but feel free to poke around: https://github.com/treason/WifiSMS/tree/master/wifiSMS
Where the on-device server code is stored.
I'll try to chime in where I can here. To get rid of the "digging the app" thing, just click donate. You don't have to really donate just click it and it won't show up anymore.
I didn't write the webserver. Google Cocoa http server. It's an open source webserver software
The notiication thing should be easy. The JS just needs to be altered to always set the doc.title to one new message, but maybe only clear it when the user hasfocus on the input box or just add a setTimeout function to update the doc title after 2 seconds
I agree on the home work mobile thing, I'll try to add it over the weekend
Hey Treason. Thanks for the info.
FYI, jrc and I have already added the necessary title logic here: https://gist.github.com/1169880/cf5c44a467c2063d54ec5f6f6c853b91edea73aa
Thanks for the info about the bar as well. I'll donate something over the next couple of days.
-Brian