12-21-2008 10:46 AM
You cannot send an SMS on Verizon using MessageConnection - you'll need to implement DatagramConnection for this network.
See this thread:
12-21-2008 01:16 PM - edited 12-21-2008 01:17 PM
MessageConnection is problematic - only one application can create a MessageConnection. This means that the first program to grab the connection succeeds, all others fail.
If you use DatagramConnection on "sms://" you do not have this restriction.
So, if you have absolute control over the client then MessageConneciton is OK, but if not you'll be fighting every other 3rd party application that tries to listen for SMS traffic (and there are a bunch of them!)
12-22-2008 06:21 PM
I got my keys today, but can't seem to quickly find out which packages require RRT so that I can include something from it to get the code signing tool to sign with RRT. Any help would be appreciated.
12-22-2008 06:25 PM
Just to let you know that the GPS code listed previously worked perfectly on the Verizon Storm!
BTW...my GPS code was correct from the beginning, what was wrong was the SMS code that's different under Verizon
I discovered this through this post though, so great work guys!
12-22-2008 07:19 PM
I got it working now also. I finally stumbled onto doing a RuntimeStore.getRuntimeStore(); to get the signing key to sign wtih RRT.
Thanks for all the help. Now we just need to tell Google what to do so they can fix Google Maps!
03-22-2009 05:46 PM
I've updated my blog with my experience with these issues. Setting up GPS on the BB Storm is VERY convoluted, difficult, poorly documented, and frustrating.
Contains WORKING BB Storm + Verizon + GPS/Data plan code.
03-25-2009 03:25 PM
Ok guys, this is what I'm using, and it is currently working fine on a Storm on Verizon:
lp = LocationProvider.getInstance( criteria );
lp.setLocationListener(new LocationListenerImpl(), 2, -1, -1 );
From previous playing around with CDMA providers (Sprint and Verizon), it can be very tricky getting the right combination. Even the interval, timeout and maxage in the setLocationListener call is difficult to get right, because often values you think would work don't. For example, in theory to keep the GPS hot you should be able to use any interval less than 10, but in our experimenting, anything more than 2 was returning very inconsistent results. I've never tried using longer intervals, since we need to keep the chip active for our application.
This works beautifully. Thank you. VZ BB Storm.
11-08-2009 05:33 PM
How exactly does this work?
ER_USAGE_MEDIUM); criteria.setPreferredResponseTime(16); criteria.setHorizontalAccuracy(100); lp = LocationProvider.getInstance( criteria ); lp.setLocationListener(new LocationListenerImpl(), 2, -1, -1 );
Are people actually cutting and pasting in code that they're using, or just typing it in (and potentially making translation errors)?
The API docs say that preferred response time is in milliseconds. How can setting response time to 16 yield a result, especially in autonomous mode? Is the implementation ignoring that value?