Tuesday, June 30, 2009

Nokia 6650 Certificate error.

One of the guys on the team was doing some work on the Nokia 6650 for AT&T and we kept getting a certificate error when we would try to load the build onto the device. It would say:

Certificate error. Contact the application supplier.


We had signed it with the Certificate required by AT&T, we examined the root certificates on the device, we even swapped out the device and tried another, but the problem still remained. We started pulling out MIDlet-Permissions, nothing.

Finally I made a test application that did nothing and had basically no jad attributes. I signed that app, loaded it, and it worked. I started moving in changes from the real app into the test app, and quickly found that the error was in a place I would never expect. It was in the "MIDlet-Info-URL". If you include this simple jad attribute, it will not load onto the device.

I checked all of the documentation on Nokia's developer site, and I found full documentation for the MIDlet-Info-URL jad attribute, and it seemed like it should be fully supported, but it will result in that certificate error :-/

I thought it was worth a post since it wasted hours of my life, and still doesn't seem to be documented on the internet.

Good Luck!

Friday, May 30, 2008

Building Projects and Solutions without Visual Studio

In the 2.0 version of the .net framework, Microsoft included a little gem called MSBuild.exe. MSBuild provides a command line interface for compiling entire projects and solutions.

Normally we would maintain NANT build scripts for our projects, and then we would run them on a build server, using CruiseControl .net, as our source control changed. However with this cool tool we can now build the solution directly from the sln file; removing our need to maintain build files.

I did run into a few snags:

J# support

J# is not entirely supported in the 2.0 framework, until you install the j# redistributable (3.7 mb) http://www.microsoft.com/downloads/details.aspx?FamilyId=E9D87F37-2ADC-4C32-95B3-B5E3A21BAB2C&displaylang=en

Web Applications

Web Applications aren't supported in the 2.0 framework. They came as an addition after the initial release of Visual Studio 2005. All of the information about them came with Microsoft® Visual Studio® 2005 Team Suite Service Pack 1. There was really no change required to the framework for these types of projects, it's really only affected Visual Studio, so there is no service pack for the framework.

I tried to download and install the service pack, but it's huge (431 mb) and it won't install:



So when all else fails, start over :)

The error message was:
error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
so I just copied the \WebApplication\ folder from a PC with Visual studio installed, and added it into to the directory where it was expecting to find it (which I had to create)

Now everything works great, and life is easier than it was before. Every time I commit a change it is auto deployed to the our dev site and life is good.

Wednesday, July 18, 2007

Bluetooth GPS Getting Smaller

Check this out! It's a bluetooth GPS receiver (nothing new there) but its so much smaller than I've seen them before. It's roughly the size of a thumb drive, and it alleges to have 8 hours of battery life, which is very impressive indeed.



I did notice that the initial aquisition time seemed a little slower than it's older bigger brothers'. But I suppose that is to be expected. The quality of the GPS output did not seem any worse to the naked eye.

In general, I would probably prefer the bigger one, just because it really doesn't need to be this small, and the bigger ones do seem to get the initial fix faster, which is the most important fix, but I'll continue to play with it and let you know if I change my mind.

Friday, June 15, 2007

Challenges of Street Maps

So I was talking to my brother Al today, who is one of the smarter people I have met, and he clearly thought I was too harsh on openstreetmap.org.

I really had no intention to sound too negative. I think that they are one the forefront of inovation. They are applying wiki ideas to geospacial data... that is huge. My point was only that the data they collect is very sensitive, and its very important that it all be right, not only geographically, but also in every minuet detail. If a contributer forgets to mention that a street is one way, or that it doesn't have a sidewalk, etc, a program would not be able to properly use the data, and it would get a bum rep.

I think that the consumer of trail data will initially just be humans. And humans are really flexible in their interpretation of the data they are given. Also, trail data is not as complex, nor is it as important to have 100% accurate. If it's a little off, it won't make a big deal.

Thanks for your input Al, the more I have to think about the idea, and the more we talk about it, the more likely I will be to follow through with it.

alwold: so i started looking at open street map
alwold: and i think it's really cool
doctor wold: yeah... it's real cool
doctor wold: did you read the nerd blog I posted?
alwold: yeah
doctor wold: ahh
alwold: you were talking shit about it
doctor wold: cool
alwold: so thats why i looked at it
doctor wold: nah, not shit
doctor wold: it's just that routable data is so hard
doctor wold: like having people contribute it correctly would be incredibly difficult
doctor wold: and trail data isn't so complex
alwold: right thats why wikipedia is so inaccurate
alwold: cause everyone is too dumb
doctor wold: no
doctor wold: words are easy
doctor wold: people know the right information
doctor wold: but its easy to put it in words
doctor wold: it's harder to turn knowledge of roads into data that is accurate enough to actually use in a program
doctor wold: I think that for prited maps, open street map is great
doctor wold: and could be used very soon
doctor wold: but for routable data, it's very sensitive
alwold: so like you're saying that this would be easy to write
alwold: http://en.wikipedia.org/wiki/Antibody
doctor wold: if you know the information then yes
doctor wold: and the information is being used by humans, which are very flexible
doctor wold: with map data it is being consumed by programs
doctor wold: which are not so smart, and flexible with input
doctor wold: anyway... you're opinion is good
doctor wold: and I think that it will be useful at somepoint soon
doctor wold: if they would have started with the tiger data, it would have maybe been useful from the start too
doctor wold: idk

Thursday, June 14, 2007

&nbsp; in HTML

The world is a funny place, full of funny people, who do funny things.

I remember at one point in my programming career, I used to worry more about how to get a task done, given what I knew at that point. Now I worry more about knowing the correct way to complete a task.

Here is a funny example of someone trying to get a task done given what they currently know, instead of figuring out the right way to do it:
samsonasu:
<td valign="top">&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;</td>
samsonasu: thats such shitty code
Though one "&nbsp;" is often good in HTML, using them to achieve your desired spacing is HORRIBLY GHETTO :-p. If you do this, and want to know a better alternative, try either using a spacer image (a 1x1 transparent gif), with a width and height, or better yet using the padding-left or margin-left css attributes.

Thanks for this one Samson :-p And Happy HTML'n to the rest of you.

Wednesday, June 13, 2007

OpenTrailMap.org

In one of my more recent impulses, I purchased a domain, opentrailmap.org/com, with the intent to start a project where people can contribute GIS data, and try to produce a map of the trails around the world.

I'm hoping that I will be able to leverage off of the technologies used by openstreetmap.org, and that it will mostly be a matter of figuring out what to leverage off of, and not so much how to implement it myself.

My theory is that openstreetmap.org, though very cool, is years away from being useful, and even farther away from being better than the data that people pay for. You may ask, "If you think it's so far out, why do the same thing for trails"? There are many compelling reasons:
  • No Good Alternative. There is no good alternative for trail maps. Topo maps are from the 80's and trails are always shifting because of fires/floods/development/etc.
  • Passion. Outdoor enthusiasts have passion. They care about the trails, and they are very into it.
  • Hikers have GPS. Hikers are already equipped with the GPS necessary to collect and store the trail data need, and they are already accustom to using it, in case they get lost.
  • Looser Requirements. Unlike street maps, there isn't going to be a turn by turn direction application that is trying to find you the best route based off this data. This allows the data to be more sparse, and less detailed (no one way steets, no HOV lane, etc)
These factors make this a project that can start off useful. From day 1 it would be better than what exists today right from. There is no need to collect all the data for it to work either. The idea would be to start local, and spread out. Work with local groups that need the data, and see if it takes off.

In addition to the collection of data, the site would have to have a way to view and print the maps, and I would probably want to partner with a Topo map printer, and allow users to print the trails they want over a high quality topo map too.

As far as the data is concerned, I would not want to hoard this data. I'd be interested in providing it to anyone who wanted it, at least for their own use. I'm not sure yet how I would fund this concept, but one initial idea is to find funding through people like the city of phoenix parks. I know that they make maps, and I wonder how much work it is. Having online maps and having users keeping those maps up to date may be very appealing to them, or may not be :).

As I come up with more on this idea, I will continue to post under the label : opentrailmap.org. Comment if you have any ideas/input.

m500 Crashes Loading Large Images

the Samsung m500 throws a java.lang.IllegalArgumentException when you try to load a large image using the Image.createImage method.

In the program I'm using, it tries to download an Image that is twice the width, and twice the height of screen. It downloads it through a socket, and tries to load it via a byte array. If you reduce the size to like 1.5 x the width and height, it loads... This issue is killing me because this exception just doesn't make any sense :)

Has anyone else seen this issue?

Friday, October 06, 2006

Image.createImage throws an IOException on Sprint CDMA Phones

Carrier: Sprint
Network: CDMA
Manufacturer: Sanyo
Programming Language: J2ME


I ran into an issue trying to download jpg data to a J2ME application recently, and I figured it warranted a blog post. 

The data the comes over the air is a bunch of meta data about the image, followed by all the bytes that are the contents of the image.  When the request comes in I find where the Image starts and try to load it into an Image object.  The Image object has a method:

Image.createImage(byte[] buffer, int start, int length)

which is perfect.  I figured I could just pass in the whole response with the right start index and length, and it would work perfect.  When I tested it, it worked great on IDEN phones, and some sprint phones, but on a number of them, Sanyo phones in particular, it would only work a small fraction of the time.  Most of the time it would return a IOException with a null message. 

After debugging this for a few hours, I found that the data being sent from the server was being received right by the phone, and that the phone was using the correct start index and length.  Then I found that if the same contents were sent to two different phones, one would work and one would fail.  I couldn't figure out why it would fail, and it really didn't make any sense.

Fortunately I was able to come up with a workaround that I haven't seen on the Internet yet, hence this blog...

Instead of passing in the whole buffer, with start and length values, I just the image bytes into a new array and pass in 0 for start and the length of the array for the length.

This solved the problem, but blew my mind.  :) 

Original Code that crashed:

                     Image img = null;
                     try {
                        img = Image.createImage(output, imageStartIdx, length)
                     } catch(Exception e) {
                        throw new Exception("The map returned was not valid.");
                     }

After The Fix:

                     byte[] imageBytes = new byte[length];
                     System.arraycopy(output, imageStartIdx, imageBytes, 0, length);
                    
                     Image img = null;
                     try {
                        img = Image.createImage(imageBytes, 0, imageBytes.length);
                        // img = Image.createImage(output, imageStartIdx, length)
                     } catch(Exception e) {
                        throw new Exception("The map returned was not valid.");
                     }

This is nothing too impressive, but I figured someone might not figure it out on their own, so there it is...

Happy Coding!