Although text messaging (SMS) is currently the most popular and profitable means of mobile communication, it rather unfortunately seems that the technology is far from perfect. Despite the fact that the technology targeted at end-users has been embraced and improved upon for over a decade, many users are still experiencing frustrations stemming from the often ignored 160-character limit.
Once smartphones became popular, if not the leading type of phone used for text messaging, the majority of mobile customers were able to effectively forget about the 160-character limit due to both clever improvements in client-side programming and the adoption of the threaded conversation-view inbox. As a result, users with smartphones should never see character limit warnings or receive out-of-sync multi-part messages.
Still, every SMS message that exceeds 160 is treated in the same manner by carriers as originally devised. When a long text message is received, the SMS gateway divides the message into parts and then delivers the parts to the recipient. If the intended recipient has a smartphone, the parts are reassembled as one single message and appears as a new message in the user’s inbox. If the recipient does not have a smartphone, the messages are labeled (½), (2/2), (1/3),(2/3), etc., depending on the number of chunks it was divided into on the server.
Other issues arise for those with slightly more intelligent dumbphones. These phone attempt to take the load off of the SMS gateway by dividing long SMS messages into shorter chunks via client-side software. When messages exceed 380 characters (2 SMS messages) new problems come into play. Typically, these phones only split messages into two chunks. and if one is shorter than 160 characters (usually the final message part) it is delivered directly, while the larger part is processed in the gateway into another two chunks, each labeled (½),(2/2). This results in severely scrambled messages and makes for confusing conversation.
The multi-part messaging scheme sometimes causes more frustration for a small user base. Wireless customers have reported that when they sent a 160+ character message, the recipient may be shown the first chunk of the intended message concatenated with a second chunk of an old or deleted message, sometimes from a different contact.
Consider this story that happened to me this past Christmas. I sent my girlfriend a message at 5:30 in the morning detailing the dull events of the night before. The message she received was missing the final punctuation of my message, yet included additional text that discussed recent activity at a popular nightclub. She interpreted this as an implication that I had intended the text to be sent to another woman. My phone retained the original unaltered message that I had actually composed in the outbox, while hers displayed the incorrectly concatenated message that almost ended our relationship.
After we resolved our differences, I continued to research the issue and found dozens of similar reports from users. Every single one appeared to be unresolved, and the bug appeared to be platform independent. Wireless customers were posing questions in forums for SonyEriccson, Blackberry, Android, HP, Apple, AT&T, Verizon, Google, and various development sites. In each case, the sender retained the intended message while the recipient had received something with an old or deleted message part concatenated to the first. More often than not, the issue was posted by a frantic boyfriend with an enraged or jealous girlfriend. The errors were not dependent on a single carrier or cellular technology; customers of both HSPA- and CDMA-based networks were reporting the same issues, sometimes across the same carriers, other times occurring during cross-carrier conversations. The only common factor seemed to be that the recipient was using a smartphone.
While no user reported any concrete solution offered by a cellular provider, hardware manufacturer or mobile operating system development team, some mobile technology gurus have offered some convincing explanations. The belief that I subscribe to involves the erroneous reconstruction of concatenated messages in conjunction with two or more corrupt contact entries in the recipients address book as hypothesized here.
I have serious doubts that this issue will get resolved, since it appears to be software-based and present in multiple operating systems. However, I have been upgraded to the iPhone this past holiday season and threw my LG ENV3 into the junk drawer. Apple’s new iMessages infrastructure seeks to circumvent carrier SMS gateways altogether whenever possible, although such privilege is limited to communications between devices running iOS 5 and above. RIM took a similar approach with the BBM network for Blackberry phones. The removal of the 160-character limit and the lift of SMS message tiered bundle pricing kept Research In Motion on top of the smartphone industry for years.
We can only hope that once dumbphones make their inevitable departure from the mobile marketplace they will take the aging SMS technology with them. In its wake we would ideally be presented with a unified cross-platform web-based messaging service tied to our cell phone numbers for the unbeatable price of free.
Yesterday, I was at an AT&T store, playing with the iPhone 4S. They had a few apps already installed, but I wanted to see how other apps ran in comparison to my iPhone 4. Unfortunately for me, they had restrictions in place to prevent installing apps from the App Store (as well as to prevent certificates from being installed) for somewhat obvious reasons. Unfortunately for them, I don’t believe in dead ends.
After much tinkering and pretending to be comparing device speeds, I determined that the usage logs and certificates (or provisioning profiles) options were useless to me. However, I realized I could log into the App Store on the iPhone 4S with my own iTunes credentials.
Once logged in, I quickly found that the “Buy” and “Install” buttons were missing from the App Store app’s interface. Then I had a brainstorm.
I went into the Store section of the Settings app and turned on Automatic Downloads for apps (a cool feature that arrived with the iCloud beta). Then on my own iPhone 4, I downloaded a new app.
On the iPhone 4S, I opened the App Store, made sure I was still logged in, and closed it. The SpringBoard pages slid left and revealed the app I had just purchased on my iPhone 4 was now installing on the iPhone 4S. This was occurring regardless of the App Store installation restrictions present on the iPhone 4S.
To me, this seems like a big security flaw. Let’s say someone wants to grab information with an app, such as a UDID finder, from a store demo iPhone. Any restrictions in place are all of a sudden gone.
Of course, this leaves a trail behind. I’m sure that ny iTunes credentials are stored in the receipts of the app I downloaded, and perhaps embedded in the history of the iPhone 4S, if not present on the AT&T proxy servers.
Still, if any malicious code sneaks into the App Store as @1c0nic has demonstrated, then store demo units could be compromised in a matter of minutes.
So my question is, is this a known flaw? Is it even a security flaw at all?
In my latest attempt to add native Send2Mac support to iPad apps, I discovered how to create Modules for iCab Mobile. If you don't know, Modules are little pieces of code, pretty much JavaScript and Userscripts as far as I can tell, that execute via a GUI button and can contain private user data via a preference pane. iCab does not currently allow you to use third party modules, so the legality of this is quite ambiguous.
The modules are stored in the directory "/Applications/iCab Mobile/Documents/.iCabMobileFiles.private/Modules/". Obviously, this is not the real path, since it does not take into consideration the GUID of the iPad application. I accessed this with iFile and poked around.
To create a module, you need to create three files:
com.company.identifier.code
com.company.identifier.icon
com.company.identifier.prefs
Your main JavaScript code goes inside the .code file. To keep things pretty, I copied and renamed a pre-existing icon, though I may change it later. The prefs file contains your module preferences and is really just a renamed plist file. If you want to be able to enter any user data, such as logins or passwords, the prefs file is the place to store it. A prefs file is required, as it contains the option to confirm on execution (do you want to do this?).
Since I was porting a bookmarklet, I found I needed to decode the URI, or convert the escape characters back to regular JavaScript. This page really helped me out: http://goo.gl/vAf0
The best scripts to look at for examples are de.icab.InstaReadLater and de.icab.goodreader. If you plan on using remotely hosted scripts or CSS overrides, you should look at de.icab.readability.
The last step to getting the module to be recognized by iCab is to modify the Modules.plist file in the Modules folder and add an entry for your new module. This part is the easiest, since you can just copy and paste from to .
One interesting thing I noticed was that everything had a German translation or alternate text. I don't speak German, so I left most of what I borrowed as is. But I imagine that if you don't include the German translations, things could possibly go awry for shared Modules.
The beauty and simplicity of this tweak makes me wonder what else these developers could do with the interface. I see a possible new skin for SBSettings toggles, or possibly an app launcher of some kind.
I think the developers could easily use the framework they've created to sell alternative products that appear the same way, or addons that add functionality to this interface. I would certainly shell out a few bucks to try it out.
First of all, I modified a javascript bookmarklet made by Read It Later. I am a paid Pro user, so I have access to the scripts behind it. Basically, it creates a session inside your current browser that, by default, sends the next link you click to Read It Later. However, with a little modification, I made it instead send the next clicked link to Send2Mac.
The benefits of this should be self-explanatory. Let's say, for example, that you are on a page with download links for files that you want to download to your Mac. You could use Send2Mac to send that whole page to your Mac, and then VNC into your home computer to click each link manually and download the files. But with this modified Read It Later bookmarklet, I can instead tap individual download links to be sent to my home computer. My Google Chrome browser will automatically recognize those links as downloadable files and immediately download them or initiate a download session with Speed Downloader.
This trick works for torrent files, zip files, DMG installers, and the like. My home system is set to install certain installable packages so that with only a few clicks I can start using software.
What I really want to be able to do though is modify the Send2Mac desktop client so that instead of opening the link in my default browser, it copies it to the system pasteboard. Then I could easily integrate it with any of my download managers that support Clipboard Monitoring, i.e. JDownloader. The real benefit of this lies in the way that the download managers store login credentials for file hosting sites. Chrome needs me to login in to the hosting sites every day, sometimes every few hours. But JDownloader always remembers my premium member login details, making the remote downloads a quick and seamless process.
With a little tinkering and trial-and-error, I've figured out that Send2Mac's client is an AppleScript that loops, while checking the Send2Mac link tied to my API key. If the link returns "File Not Found" then it does nothing, and keeps trying. If the link returns a text value for a HTTP link, then it opens it in a browser.
So all I would need to do is recreate the AppleScript client to check for my user link and if it returns a value that I can work with, makes sure JDownloader is running and then copies the link to the clipboard. JDownloader will almost instantly recognize the link, add it to the queue, and away we go.
I have also been toying with other ideas to make this more useful.
Some stuff that I would like to see, try, or implement:
For many Mac App Store users there is a very annoying "bug" that affects your experience in updating apps. When you click the Updates section, there will be an update available for the Twitter app. No matter how many times you seemingly successfully update the app, the same update will keep appearing. Even if you delete the Twitter app, the update will remain.
This inconvenience actually has little to do with the Twitter app or the Mac App Store. It's actually a side affect of Mac App Store app piracy. In early January 2011, a few blogs posted that they had discovered a method of using pirated Mac App Store apps by simply copying and pasting the MAS receipt from a free app (such as Twitter) into the Contents folder of a paid app.
This issue is not only limited to Mac App Store piracy. Myself and others have tried unsuccessfully to get legitimately purchased Apple products such as iWork and iLife (obtained via CD or bundled with a computer purchase) to be recognized and updated by the App Store. To do this, we followed the same method implicated above, i.e., copying the Twitter MAS receipts into the app bundle contents folder. This however does not work, and instead causes infinite Twitter updates.
Since this issue is a direct indicator of illegal activity, there appear to be no clear solutions listed in the Apple Community support forums on how to fix it, other than deleting the pirated app. However, unless you remember which app you did this to, there is no obvious way to find and remove the app.
I have found a few ways to do this successfully. I posted these steps in the support forums, but within 24 hours, my posts were removed due to a violation of Apple's TOS.
The first method is to look in your Applications folders (/Applications or ~/Applications) for apps modified around January 6, 2011. Then you can right click on the apps, select Show Package Contents, and see if there is a _MASReceipt file in there. Delete it, relaunch the Mac App Store, and see if the Twitter update is gone.
If that doesn't work, you'll need to do some advanced snooping.
Just download EasyFind, available free in the Mac App Store. Then, perform a search of Files & Folders in /Applications for "_MAS" making sure that "Package Contents" under the Include section is checked. Sort the results by modification date, and keep an eye out for early Janurary 2011 dates.
From here, you should be able to quickly jog your memory, but you can also just compare the apps that appear with the apps that are listed under the Purchased tab of the Mac App Store. Then, double-click the culprit in EasyFind and the Finder window with the offender will pop up on your screen. Drag the MAS receipts to the trash, empty the Trash, and then relaunch the Mac App Store. If you did things right, you won't see any more Twitter updates.
Click here to Download EasyFind for free from the Mac App Store
I'm an English major with an extreme love for tinkering and tweaking. I have a strong interest in iOS, web development, Mac, and everything Apple. I like to develop creative solutions using apps and devices to enable unique workflow processes. I intend to use this space to elaborate on some of my creative, if not out-of-the-box, personal projects and solicit input for completing them.
Find me on Google+