Logged in as Guest   Fri, Mar. 12th, 5:09 AM.      
Visitor Map
Recent Entries:
My Dev Setup Lately
Three Ways To Randomize on the iPhone
How to Remove .svn Directories On a Mac
How To Detect The iPhone Simulator
iPhoneMom Likes Doodle Games!
Updates To the Doodle Games Line
Three Jacks Now Tweets
Second iPhone App Submitted For Approval!
Pinch Media Analytics for iPhone
New iPhone Game Coming Soon!

Archive:
January - 2010
November - 2009
October - 2009
September - 2009
August - 2009
July - 2009
June - 2009
April - 2009
March - 2009
January - 2009
May - 2008
April - 2008
March - 2008
October - 2007
August - 2007
July - 2007
June - 2007
May - 2007
April - 2007
December - 2006
November - 2006
September - 2006
August - 2006
July - 2006
March - 2006
February - 2006
January - 2006
December - 2005
November - 2005
October - 2005
September - 2005
August - 2005
July - 2005
June - 2005
May - 2005
April - 2005
February - 2005
January - 2005
December - 2004
November - 2004
October - 2004
September - 2004
August - 2004
July - 2004
June - 2004
May - 2004
April - 2004
March - 2004

Ubuntu Rules, Fedora Drools
Hopefully, nobody really noticed, but Jonah and I finally moved our aging Red Hat server to the very friendly Ubuntu Linux distribution. Previously, Luggle had been hosted on Fedora Core, and unfortunately, it was really starting to show its age.
If you haven't heard of Ubuntu, you really should take a peak at what
Mark Shuttleworth and company have put together. In a nutshell, Ubuntu is built around Debian with a focus on being user-friendly. (If you're unfamiliar with Debian, it is Linux with a focus on easy upgrades.)
I have many opinions about using Linux as a desktop installation, and while I still think that the whole experience isn't quite ready for the 'average joe', I do believe that Ubuntu has advanced the cause considerably. I even went so far as to try my litmus test, which you can read about here.
Well, that's about it for tonight. Cheers!

-Jon
Submitted by bosshogg on Sunday the 24th of July 2005, at 09:45 pm


Follow On Article About Retrieving Assigned IP Addresses
In a previous post about inspecting network connection settings on the PalmOS, I presented one piece of very incorrect/misleading information of particular interest to developers working on networked applications. I presented a code snippet to retrieve the assigned IP address when connecting via DHCP to a server. (Giving credit where credit is due, my error was very kindly pointed out to me by Henk Jonas.)
In my previous article, the snippet showed that you could retrieve the assigned IP address simply by querying the netIFSettingActualIPAddr using NetLibSettingGet(). In fact, the problem is slightly more complicated. The method that Henk pointed me to is implemented by looping through the NetLib interfaces after a connection has been established. While looping through the interfaces, you must look for the ones that are up and that are not the loopback interface. Once you have found an interface that is up, only then can you query netIFSettingActualIPAddr using NetLibIFSettingGet().
Here is one way to implement this:
UInt16 index = 0;
Err err = errNone;
while (err == errNone)
{
    UInt16 idx;
    UInt32 creatorID;
    UInt16 instance;
	
    //Retrieve the creator ID and instance of the indexed Interface
    err = NetLibIFGet(netLibRefNum, index, &creatorID, &instance);
    if (err == errNone)
    {
        //Check to see if the interface is up
        UInt8 isUp = false;
        UInt16 size = sizeof(isUp);
        NetLibIFSettingGet(netLibRefNum, 
                           creatorID, 
                           instance, 
                           netIFSettingUp,
                           &isUp,
                           &size);
			
        //Make sure the interface is up and is not the 
        //loopback interface
        if (isUp && creatorID != 'loop')
        {
            //Once we get here, it's simply a matter of 
            //grabbing the IP address
            UInt32 address;
            size = sizeof(address);
            NetLibIFSettingGet(netLibRefNum, 
                               creatorID, 
                               instance,
                               netIFSettingActualIPAddr, 
                               &address, 
                               &size);

            //Once you get here, you have to do something 
            //with the IP address.  Do you just get the 
            //first one and stop, or do you want all the
            //assigned IP addresses of Up Interfaces?  
            //That determines whether or not you want to 
            //break out of this loop.  I leave that as an
            //exercise for the reader.  -Jon
        }
     
        //Go on to the next Interface
        index++;
    }
} 

As always, I hope this helps you in your endeavors, and if you feel like it, I'd love to hear about it!

-Jon
Submitted by bosshogg on Saturday the 09th of July 2005, at 07:21 pm


WiFi-Where Now Supports the Lifedrive and Gets a User Review
As a more practical follow up to my previous posting, I have updated WiFi-Where to support the Lifedrive. On a related note, WiFi-Where is now available for purchase on Palmgear as well as Handango. I hope to write up my experiences dabbling in the world of shareware authors soon. (Suffice it to say, I won't be quitting my day job anytime soon.) However, I did get my first review on Handango and they gave me 5 stars!!!

"This is one of the best appz that I have on my TC, it easily beat´s Netchaser. With this program I have ploted the open wifi-points in my homecity and shared them with my friend. He has done the same in the city he life in for easy wifi access...."

Nice!

-Jon
Submitted by bosshogg on Thursday the 07th of July 2005, at 12:09 am


The Lifedrive and the NetServices Library
The NetServices library is used on both the Tungsten C and the WiFi SD card from palmOne to control the 802.11 radio. The new Lifedrive from palmOne also sports an 802.11 radio and when I finally got my hands on one the other day, I was pleased to see that it also supports the NetServices API. However, as I played with it, I discovered a few differences that I will share here.

The first difference is that the NetServicesProfile structure (used to retrieve and store specific settings related to establishing a connection) is now larger than the one that is currently documented. The structure is documented/defined in PalmNetServices.h, however, the size of the structure that is written to by the NetServicesProfileRead function is larger. To illustrate this, the following code doesn't work on the Lifedrive because it corrupts the stack:

Example 1:
    NetServicesProfile profile;
    NetServicesProfileRead(netServicesLib, 0, &profile);
The proper way to use the NetServicesProfile structure is to query its size using NetServicesProfileGetInfo() which will fill a NetServicesProfileInfo structure with general information about profiles on a device. The NetServicesProfileInfo structure then contains the size of the NetServicesProfile structure in the profileEntrySize member. As I write that, I realize it probably is a little unclear, so here is a little sample code to illustrate the proper way to do this:

Example 2:
    NetServicesProfile* profile;
    NetServicesProfileInfo profileInfo;

    NetServicesProfileGetInfo(netServicesLib, &profileInfo);
    profile=(NetServicesProfile*)MemPtrNew(profileInfo.profileEntrySize);
    NetServicesProfileRead(netServicesLib, 0, profile);

    //Use profile here...

    MemPtrFree(profile);
In retrospect, this is the way that I should have been using NetServicesProfileRead all along, however, I must say that the very sparse documentation on the NetServices API didn't help my cause. If you know what the new definition of the NetServicesProfile structure is, I'd love to know!

The second major difference that I found relates to the RSSI (receiver signal strength indicator) values that are returned from a WiFi scan. Previously, the RSSI values ranged from 0 to -100 where 0 is the theoretically best RSSI value. On the Lifedrive, however, the returned values ranged from between 250 and 350. Now, these values aren't documented anywhere that I could find and are values that I discovered only through experimentation so your results may vary. Because of these differences, I had to change my WiFi-Where code to normalize the returned RSSI values. For reference, here's my implementation:

Example 3:

    Int32 NormalizeRSSI(NetBssInfoType* info)
    {
        Int32 rssi;
        BssInfoRssi(info, &rssi);
 		
        UInt32 deviceID =  0xFFFFFFFF;
        if (errNone != FtrGet(sysFtrCreator,            
                              sysFtrNumOEMDeviceID, 
                              &deviceID))
        {
            deviceID = 0xFFFFFFFF;
        }
    
        if (deviceID == 'TunX')
        {
            //LifeDrive = 250-350  normalized to 10% - 70%	
            rssi -= 150;
            rssi *= 70;
            rssi /= 100;
        }
        else 
        {
            //Put value into the positive range...
            rssi += 100;
        }

        return rssi;
    }

So far, these are the only major differences that I could find. I'm sure that there are others that I simply haven't stumbled upon yet. I will update as I discover more. If you have found other differences in the NetServices implementation, or can fill in the backstory behind these differences, I'd love to hear about it!

-Jon
Submitted by bosshogg on Monday the 04th of July 2005, at 11:42 pm